A Sane git Workflow

(for the fairly advanced git user who can’t quite 
use github’s awesome continuous deployment
 methodology because they still have to deal
 with versions and releases and other
 business / marketing nonsense)

This was the original concept for Vitrue's git workflow, and includes a few slides about getting rid of the old "git-flow". A newer version of this presentation is now the one I use for new teams here a Vitrue (or as we're now known, Oracle).

Transcript

1. a sane git workflow
2. a sane git workflow (for the fairly advanced git user who can’t quite use github’s awesome continuous deployment methodology because they still have to deal with versions and releases and other business / marketing nonsense)
4. PROCESS PROCESS PROCESS P OCESS PROCESS PROCESS PROC PROCESS PROCESS PROCESS PR
5. PROCESS PROCESS PROCESS P OCESS PROCESS PROCESS PROC PROCESS PROCESS PROCESS PR Do I need to merge twice? How do I resolve this conflict? Where do I merge?
6. PROCESS PROCESS PROCESS P OCESS PROCESS PROCESS PROC PROCESS PROCESS PROCESS PR WTF is going on? Do I need to merge twice? How do I resolve this conflict? Where do I merge?
7. develop What We Really Want
8. develop ew/add-new-shiny What We Really Want
9. develop ew/add-new-shiny
10. develop ew/add-new-shiny PULL REQUEST!
12. IT’S JUST NOT THIS HARD!
13. WHAT WE NEED simple prevent merge errors & regressions consistency keep everyone working on the latest code as often as possible
14. LET’S TALK ABOUT a fresh start feature branches release branches rebasing bad habits staging releasing
15. START PULL REQUEST BRANCH
16. START SANE, STAY SANE master == develop If it doesn’t, figure out why not! Unmerged features? Probably need to break these out. If all else fails, rename develop to something else and start clean
17. git fetch git checkout origin/develop git checkout -b old-develop git push origin old-develop git checkout develop git reset --hard origin/master git push -f origin develop
18. master, develop
19. USE:feature branches
20. USE:feature branches branch from develop when you start a new feature rebase onto develop often stay up to date with the latest and greatest pull request into develop when done
21. develop Simple Example: One shiny new feature
22. develop ew/new-shiny git checkout -b ew/new-shiny
23. develop ew/new-shiny git commit ...
24. develop ew/new-shiny
25. develop ew/new-shiny
26. NO!release branches
27. NO!release branches develop is your release branch nothing merges into develop until it is ready to release you can’t release until everything in develop is ready new features branch from, and merge back into, develop
28. develop ew/new-shiny Still Easy: Two independent new features kb/moar
29. develop kb/moar ew/new-shiny
30. develop kb/moar ew/new-shiny
31. develop kb/moar ew/new-shiny
32. develop kb/moar ew/new-shiny
33. interlude on pull requests: after the pull request, the branch is done no more commits!
34. develop kb/moar ew/new-shiny
35. develop kb/moar ew/new-shiny
36. develop kb/moar ew/new-shiny
37. develop kb/moar ew/new-shiny doesn’t have the changes from ew/new-shiny!
38. interlude on pull requests: after the pull request, the branch is done no more commits! avoid confusion delete the branch
39. develop kb/moar-cont ew/new-shiny git branch -d kb/moar git checkout -b kb/moar-cont on branch develop:
40. interlude on pull requests: after the pull request, the branch is done no more commits! avoid confusion delete the branch, or fast-forward to the merged branch
41. REBASE don’t fear the
42. REBASE stay on top of the latest changes incorporate others’ work into your own branch don’t fear the
43. develop kb/moar ew/new-shiny Small Problem: @kb needs @ew’s feature to finish
44. develop kb/moar ew/new-shiny REBASE! git rebase origin/develop on branch kb/moar:
45. develop kb/moar ew/new-shiny REBASE! git rebase origin/develop on branch kb/moar:
46. develop kb/moar ew/new-shiny
47. develop kb/moar ew/new-shiny
48. REBASE fear not the stay on top of the latest changes incorporate others’ work into your own branch two developers working on the same feature branch may depend on each other’s progress abstract one more level
49. develop Bigger Problem: Big new feature needs two developers
50. develop big-feature git checkout -b big-feature on branch develop:
51. develop big-feature jl/big-feature ew/big-feature git checkout -b jl/big-feature git checkout -b ew/big-feature on branch big-feature:
52. develop big-feature jl/big-feature ew/big-feature
53. develop big-feature jl/big-feature ew/big-feature PULL REQUEST!
54. develop big-feature jl/big-feature ew/big-feature
55. develop big-feature jl/big-feature ew/big-feature
56. develop big-feature jl/big-feature ew/big-feature REBASE! git rebase origin/big-feature on branch ew/big-feature:
57. develop big-feature jl/big-feature ew/big-feature REBASE! git rebase origin/big-feature on branch ew/big-feature:
58. develop big-feature jl/big-feature ew/big-feature
59. develop big-feature jl/big-feature ew/big-feature
60. develop big-feature jl/big-feature ew/big-feature
61. develop big-feature jl/big-feature ew/big-feature
62. develop big-feature jl/big-feature ew/big-feature \o/ Feature is done!
63. things to note: no shared branches rebase at will fewer pull/merge conflicts merge code when it won’t break others’ your branch back to feature branch feature branch back to develop all merging done by github code reviews! if github can’t merge, rebase! less likely to resolve conflicts incorrectly
64. things to note: • no shared branches • rebase at will • fewer pull/merge conflicts • merge code when it won’t break others’ • your branch back to feature branch • feature branch back to develop • all merging done by github • code reviews! • if github can’t merge, rebase! less likely to resolve conflicts incorrectly!!
65. STOP!with the bad habits
66. STOP!with the bad habits the straight line myth is dead you’ll have lots of branches merges are not evil use GUIs sparingly this is code, not a pretty picture git pull is evil git fetch, followed by git merge
68. NO!staging branch
69. NO!staging branch staging is a tag any developer can tag staging and deploy their code there final qa before release? merge features into develop and tag staging there
70. develop kb/moar ew/new-shiny git tag -f staging git push -f origin staging on branch kb/moar: staging
71. develop kb/moar ew/new-shiny REBASE! git rebase origin/develop on branch kb/moar:
72. develop kb/moar ew/new-shiny git tag -f staging git push -f origin staging on branch kb/moar: staging
73. develop kb/moar ew/new-shiny git tag -f staging on branch develop: staging
74. PUSH IT! release management
75. PUSH IT! release management hotfixes on master pull request from develop to master fast-forward develop to master (branches end after merge) tag your release v2.1.5
76. develop, master v2.1.0
77. ew/hotfix develop master v2.1.1 v2.1.0
78. ew/hotfix jl/new master kb/hotness develop v2.1.1 v2.1.0
79. ew/hotfix develop master jl/new kb/hotness v2.1.1 v2.1.0
80. ew/hotfix develop master jl/new git rebase origin/master git tag -f staging on branch develop: staging kb/hotness v2.1.1 v2.1.0
81. ew/hotfix develop master jl/new kb/hotness v2.2.0 v2.1.1 v2.1.0
82. ew/hotfix master, develop jl/new git branch -d develop git checkout -b develop on branch master: kb/hotness v2.2.0 v2.1.1 v2.1.0
83. ew/hotfix master, develop jl/new kb/hotness v2.2.0 v2.1.1 v2.1.0
84. ew/hotfix master, develop jl/new git rebase origin/develop on branch kb/hotness: kb/hotness v2.2.0 v2.1.1 v2.1.0
85. REVIEW master == develop feature branches from develop don’t share branches! pull request back to develop rebase to stay current hotfix branches from master pull request back to master branches end after merge