Team-Based Git Workflow

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

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