$30 off During Our Annual Pro Sale. View Details »

Release Management Git Workflow

Release Management Git Workflow

How the Oracle Social Cloud team uses GitHub

Elliott Wood

October 05, 2012
Tweet

More Decks by Elliott Wood

Other Decks in Programming

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
  64. None
  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