Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Sane git Workflow

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).

Elliott Wood

March 21, 2012
Tweet

More Decks by Elliott Wood

Other Decks in Programming

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)
  3. None
  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!

  11. None
  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
  67. None
  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