Git Flow

A suggested workflow by using Git at Oi Internet for all projects following the best practices like Feature Branch, Commit Messages, Pull Request & Code Review, Tag, etc.

Transcript

1. Git Workflow Keep it Simple. Please!
2. Who am I? @RafaellLycan
7. <agenda /> • Feature branch • Commit messages • Pull request • Code Review • Our own flow
8. Repository
9. remote! (origin) Froddo Luke Jill
10. Time to MERGE!
11. remote! (origin) Froddo Luke Jill
12. remote! (origin) Froddo Luke Jill
13. remote! (origin) Froddo Luke Jill
15. remote! (origin) Froddo Luke Jill
17. remote! (origin) Froddo Luke Jill
19. Trick Time: Did you know the rebase? git pull —rebase https://git-scm.com/book/en/v2/Git-Branching-Rebasing
20. Feature Branch
21. Branching! & Merging Strategy
22. master! and development
23. feature! release! hotfix
24. Branching! Parallel development, multiple releases
25. master cart-rules new-payment-gateway
26. Golden Rule: New branch must be created from master.
27. Golden Rule: Don’t merge the feature until is complete.
28. Golden Rule: When you finish your feature, delete the branch.
30. 38?! Really?
32. Master Rule: The master branch is the production branch.
33. Commit Messages Why commit messages care?
34. Commit Messages Must tell us a history about the code.
36. Commit Messages The message must make sense.
40. Commit Messages Don’t put the same message again.
42. Commit Messages The message must be clear.
45. WHAT ABOUT! CLEAN HISTORY?
46. Trick Time: Did you know the amend? git commit --amend –C HEAD https://git-scm.com/book/en/v2/Git-Basics-Undoing- Things
47. Golden Rule: Think that supposedly does this commit?
49. • Why is this change necessary? • How does it address the issue? • What side effects does this change have?
50. Tim Pope Rules: • Always start with a short title (50 chars); • Always write commit message in the imperative; • Add more detailed explanatory if you need; • Wrap it to about 72 characters or so; • Further paragraphs come after blank lines; • Bullet points are okay, too. http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
51. Redirect user to the requested page after login! ! https://trello.com/path/to/relevant/card! ! Users were being redirected to the home page after login, which is less! useful than redirecting to the page they had originally requested before! being redirected to the login form.! ! - Store requested path in a session variable! - Redirect to the stored location after successfully logging in the user https://confluence.oiinternet.corp/display/DEV/Pull+Request+Template
52. Pull Request & Code Review
53. Why PR?
56. IF THINGS! GO WRONG?
58. Golden Rule: Your PR should be like a good documentation.
59. Golden Rule: Each merged PR must have a tag.
60. Golden Rule: Other people should evaluate your PR.
61. Why Code Review?
63. Flow
64. Flow! release-oriented branching model
65. Flow! deploy-oriented branching model
66. Flow! The dev branch is not needed anymore.
67. KEEP IT! SIMPLE
68. –Scott Chacon (Github Co-founder) “Use the simplest possible system that will work for your team.”
69. master Change something https://confluence.oiinternet.corp/pages/viewpage.action?pageId=2525119
70. master branch Last change on the branch https://confluence.oiinternet.corp/pages/viewpage.action?pageId=2525119
71. master branch https://confluence.oiinternet.corp/pages/viewpage.action?pageId=2525119
72. master branch https://confluence.oiinternet.corp/pages/viewpage.action?pageId=2525119
73. master branch https://confluence.oiinternet.corp/pages/viewpage.action?pageId=2525119
74. MASTER PULL
 REQUEST FEATURE! BRANCH
75. DEPLOY REVIEW BUILD
76. Keep it Simple.! Without the dev branch we have less drama to worry about.
77. master branch 1.4.0
78. master branch 1.4.0
80. Hotfix.! A hotfix is a fix to be done under production.
81. master branch 1.4.0 1.4.1
82. No dev branch.! You'll make your release candidate (RC) as a new version.
83. RC Branchs: Tested; Implemented; Delete.
84. Thanks!