Release Management Git Workflow

How the Oracle Social Cloud team uses GitHub

Transcript

1. a git workflow
2. a git workflow release management ^ (for when you can’t quite do continuous deployment)
3. with thanks to Zach Holman... http://zachholman.com/talk/how-github-uses-github-to-build-github
4. master What We Really Want
5. master ew/add-new-shiny What We Really Want
6. master ew/add-new-shiny
7. master ew/add-new-shiny PULL REQUEST!
8. WHAT WE NEED simple prevent merge errors & regressions consistency keep everyone working on the latest code as often as possible
9. LET’S TALK ABOUT basic plan feature branches release branches rebasing bad habits staging releasing
10. START A BASIC PLAN*
11. START BRANCH A BASIC PLAN*
12. START PULL REQUEST BRANCH A BASIC PLAN*
13. START PULL REQUEST BRANCH A BASIC PLAN*
14. START PULL REQUEST BRANCH A BASIC PLAN*
15. CURRENT release branch A BASIC PLAN* pull request THE NEXT release branch pull request
16. USE:feature branches
17. 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
18. develop Simple Example: One shiny new feature
19. develop ew/new-shiny git checkout -b ew/new-shiny
20. develop ew/new-shiny git commit ...
21. develop ew/new-shiny
22. develop ew/new-shiny
23. NO!release branches
24. 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
25. develop ew/new-shiny Still Easy: Two independent new features jwl/moar
26. develop jwl/moar ew/new-shiny
27. develop jwl/moar ew/new-shiny
28. develop jwl/moar ew/new-shiny
29. develop jwl/moar ew/new-shiny
30. interlude on pull requests: after the pull request, the branch is done no more commits!
31. develop jwl/moar ew/new-shiny
32. develop jwl/moar ew/new-shiny
33. develop jwl/moar ew/new-shiny
34. develop jwl/moar ew/new-shiny doesn’t have the changes from ew/new-shiny!
35. interlude on pull requests: after the pull request, the branch is done no more commits! avoid confusion delete the branch
36. develop jwl/moar-cont ew/new-shiny git branch -d jwl/moar git checkout -b jwl/moar-cont on branch develop:
37. 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
38. REBASE don’t fear the
39. REBASE stay on top of the latest changes incorporate others’ work into your own branch don’t fear the
40. develop jwl/moar ew/new-shiny Small Problem: @jwl needs @ew’s feature to finish
41. develop jwl/moar ew/new-shiny REBASE! git rebase origin/develop on branch jwl/moar:
42. develop jwl/moar ew/new-shiny REBASE! git rebase origin/develop on branch jwl/moar:
43. develop jwl/moar ew/new-shiny
44. develop jwl/moar ew/new-shiny
45. 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
46. develop Bigger Problem: Big new feature needs two developers
47. develop big-feature git checkout -b big-feature on branch develop:
48. 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:
49. develop big-feature jl/big-feature ew/big-feature
50. develop big-feature jl/big-feature ew/big-feature PULL REQUEST!
51. develop big-feature jl/big-feature ew/big-feature
52. develop big-feature jl/big-feature ew/big-feature
53. develop big-feature jl/big-feature ew/big-feature REBASE! git rebase origin/big-feature on branch ew/big-feature:
54. develop big-feature jl/big-feature ew/big-feature REBASE! git rebase origin/big-feature on branch ew/big-feature:
55. develop big-feature jl/big-feature ew/big-feature
56. develop big-feature jl/big-feature ew/big-feature
57. develop big-feature jl/big-feature ew/big-feature
58. develop big-feature jl/big-feature ew/big-feature
59. develop big-feature jl/big-feature ew/big-feature \o/ Feature is done!
60. 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
61. 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!!
62. STOP!with the bad habits
63. 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
65. STAGE all your code’s a
66. STAGE all your code’s a 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
67. develop jwl/moar ew/new-shiny git tag -f staging git push -f origin staging on branch jwl/moar: staging
68. develop jwl/moar ew/new-shiny REBASE! git rebase origin/develop on branch jwl/moar:
69. develop jwl/moar ew/new-shiny git tag -f staging git push -f origin staging on branch jwl/moar: staging
70. develop jwl/moar ew/new-shiny git tag -f staging on branch develop: staging
71. PUSH IT! release management
72. 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
73. develop, master v2.1.0
74. ew/hotfix develop master v2.1.1 v2.1.0
75. ew/hotfix jl/new master cs/hotness develop v2.1.1 v2.1.0
76. ew/hotfix develop master jl/new cs/hotness v2.1.1 v2.1.0
77. ew/hotfix develop master jl/new git rebase -p origin/master git tag -f staging on branch develop: staging cs/hotness v2.1.1 v2.1.0
78. ew/hotfix develop master jl/new git rebase -p origin/master git tag -f staging on branch develop: staging cs/hotness v2.1.1 v2.1.0
79. (preserve merges!) ew/hotfix develop master jl/new git rebase -p origin/master git tag -f staging on branch develop: staging cs/hotness v2.1.1 v2.1.0
80. ew/hotfix develop master jl/new cs/hotness v2.2.0 v2.1.1 v2.1.0
81. ew/hotfix master, develop jl/new git branch -d develop git checkout -b develop on branch master: cs/hotness v2.2.0 v2.1.1 v2.1.0
82. ew/hotfix master, develop jl/new cs/hotness v2.2.0 v2.1.1 v2.1.0
83. ew/hotfix master, develop jl/new git rebase origin/develop on branch cs/hotness: cs/hotness v2.2.0 v2.1.1 v2.1.0
84. 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