Team-Based Git Workflow

Team-Based Git Workflow

Using Local Feature Branching and Rebase for small-team git workflows

E88c3a272a15086332786cda54bacacc?s=128

matt swanson

March 15, 2012
Tweet

Transcript

  1. Team-Based Git Workflow that doesn’t suck! Matt Swanson swanson @_swanson

    Thursday, March 15, 12
  2. git-flow • “elegant mental model” • “easy to comprehend” •

    “allows team members to develop a shared understanding of the branching and releasing processes” http://nvie.com/posts/a-successful-git-branching-model/ Thursday, March 15, 12
  3. http://nvie.com/posts/a-successful-git-branching-model/ Thursday, March 15, 12

  4. WAT Thursday, March 15, 12

  5. TLDR: Local feature branch + rebase Thursday, March 15, 12

  6. Guidelines • Don’t push known broken code to master •

    ALL work on local feature branches • Limit remote branches • Rebase as often as you would ‘Get Latest’ • Only fast-forward merge to master Thursday, March 15, 12
  7. Intrigued? As a developer, I want to work on feature

    XYZ >> git pull >> git checkout -b XYZ I do some work... >> git add/commit It’s been a while since I started... >> git checkout master >> git pull >> git checkout XYZ >> git rebase master Thursday, March 15, 12
  8. Oh snap, there’s a merge conflict! Stay calm!! >> git

    mergetool //use p4merge >> git rebase --continue (git rebase --abort => “Oh S#!%” button) All is well, finish my feature and merge to master >> git add/commit >> git checkout master >> git merge XYZ >> git push Thursday, March 15, 12
  9. Why is this good? • Uses branches effectively • No

    super-advanced git-fu • Great for milestone releases • Resilient and grok-able in a day Thursday, March 15, 12
  10. Why is this bad? • Not good for continuous deployment

    • Hard to share code between devs • Rebasing => merge conflicts => scary No cool kids are telling you to do it Thursday, March 15, 12
  11. Now you ask questions and I tell you answers Thursday,

    March 15, 12