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

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. WHAT WE NEED simple prevent merge errors & regressions consistency

    keep everyone working on the latest code as often as possible
  2. 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
  3. 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
  4. interlude on pull requests: after the pull request, the branch

    is done no more commits! avoid confusion delete the branch
  5. 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
  6. REBASE stay on top of the latest changes incorporate others’

    work into your own branch don’t fear the
  7. 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
  8. 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
  9. 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!!
  10. 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
  11. 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
  12. develop jwl/moar ew/new-shiny git tag -f staging git push -f

    origin staging on branch jwl/moar: staging
  13. develop jwl/moar ew/new-shiny git tag -f staging git push -f

    origin staging on branch jwl/moar: staging
  14. 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
  15. 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
  16. 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
  17. (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
  18. 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
  19. 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