Git Branching for Agile Teams

19,890 views

Published on

Moving to Git opens up a whole new level of agility for software teams. Freed from the clunky code freezes and monolithic mega-merges that plague centralized version control, developers can isolate work in progress and build in narrow vertical slices with ease. Branching is so painless with Git that many teams are making new branches for each user story or bug fix they implement. This model is quickly becoming the new gold standard for agile teams – and for good reason!

Published in: Technology
5 Comments
24 Likes
Statistics
Notes
  • @svenpeters As I didn't see the presentation (only read the slides), I may have understood something wrong ;)
    But thanks for the clarifications!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @JordanSilva3 I agree, a CI server is your safety net and your insurance that you don't have accidentally broken something. Of course every developer should make sure that the quality is good before the code hit the master branch.
    I don't know where you want to use auto branches for development? I never referred to it other than to the historic release branch example and to merge changes from master on CI-build success automatically to each individual feature branch to visualize integration problems early. I think in these two situations automatic merging is a time safer and doesn't violate the responsibility for each developer to write good quality code.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @svenpeters For hotfix usually only one developer working on it, but for development? Specially in small projects? Merge is part of the life unless you prefer to work with lock (or have the ownership of the code). And I think that it is developer's responsibility to ensure that her commit does not break the build (even when merging). In my point of view, a code change cannot be the last thing that a developer does before committing and delegate the responsibility of running Unit Test to some commit hook is a step back in a good development practice (beyond making process more complex as you said).
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @JordanSilva3 That's a really good point. I was talking about auto merges for release branches. There is normally only one developer working on a hotfix that get merges in all following release branches, so you won't have 2 developers changing code at the same time.
    But said that: I won't trust it just like that. You need always have a CI server looking at your branches and build on change. If the build fails you of course have to fix your changes. Also if you manually merge changes like this, you can miss that somebody deleted your variable... no guarantee here.
    You could also have a pre commit hook that triggers your build server that runs a build against your changes and stops the merge if the build fails.... which could work but could also make things more complicated.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I really don't trust automatic merge for coding. My first experience with auto-merge was with ClearCase and, as expected, terrible. And Git does not do better in that feature and the reason is simple: if, for example, a developer deletes a instance variable and another one creates a new method, at the end of the file, that uses this instance variable, Git will auto-merge and the final result will be a non-compilable code in master (or in the integration branch)! I have faced such problem many times :(
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
19,890
On SlideShare
0
From Embeds
0
Number of Embeds
779
Actions
Shares
0
Downloads
270
Comments
5
Likes
24
Embeds 0
No embeds

No notes for slide

Git Branching for Agile Teams

  1. Git Branching for Agile Teams Helping agile teams @svenpet moar be^awesome
  2. Guten Morgen Sven Peters ! Atlassian Ambassador & Geek @svenpet
  3. Housekeeping 1 Submit Qs for A! 2 Smile, we’re on camera. 3 Tweet to #code4acause
  4. Agenda 1 Git + agile = BFFs 2 Branching models for agile teams 3 Incorporating best practices 4 Trade-offs to consider
  5. Why Git + Agile?
  6. 1 Build in narrow vertical slices “big bang” launch MVP launch TESTING TESTING FRONT END FRONT END B AC K E N D D ATA BD ATA B A S E ASE Time B AC K E N D
  7. Build in narrow vertical slices potentially shippable, even without this piece I have a roof!
  8. Make releases a non-event just a few dependencies... 2
  9. Make releases a non-event
  10. Chaos! I do my thing, too I do my thing look Ma, a goat!
  11. Hoarding
  12. Isn‘t it ironic?
  13. A Few Words About Git
  14. everybody stops work until merge is done In Subversion Branching & merging is hell afraid that the build will fail waiting until implementation is done
  15. In Git Branching & merging is a breeze
  16. Branch-per-Issue Workflow
  17. Keep the main line clean dev branch = isolation chamber
  18. Clarity & traceability
  19. Branch-per-Issue Workflow for SaaS teams
  20. A branch for every issue fortunately, no goats here master sgd-IRKD-30 sgd-IRKD-45
  21. A branch for every issue master sgd-IRKD-30 sgd-IRKD-30 God-like admin rights optional
  22. A branch for every issue master sgd-IRKD-30
  23. A branch for every issue master sgd-IRKD-30
  24. A branch for every issue master sgd-IRKD-30 gatekeeper
  25. A branch for every issue still no goats!
  26. Using an Integration Branch
  27. Surprise! master sgd-IRKD-30 sgd-IRKD-45
  28. Using an integration branch master integration sgd-IRKD-30 sgd-IRKD-45
  29. Using an integration branch master integration sgd-IRKD-30 sgd-IRKD-45
  30. Branch-per-Issue Workflow for installed app teams
  31. Multiple-version support v 1.1 v 1.2 master sgd-IRKD-30
  32. Multiple-version support v 1.1 v 1.2 sgd-IRKD-31 master sgd-IRKD-30
  33. Multiple-version support bugfixv 1.1 IRKD-32 v 1.2 master sgd-IRKD-30
  34. Multiple-version support bugfix-IRKD-32 v 1.1 v 1.2 master
  35. T Atla he ssia Way n Multiple-version support manually automatically v 1.1 v 1.2 master https:/ /bitbucket.org/durdn/automatic-merge-hook
  36. Continuous Integration & Peer Review
  37. Running CI on dev branches all active branches are under test
  38. Running CI on dev branches bitbucket.org/tpettersen/git-ci-hooks 1 Clone master’s CI configs 2 Jenkins plugin or Git hook 3
  39. Running CI on dev branches
  40. Running CI on dev branches v 1.2 master sgd-IRKD-30
  41. Peer code review 1 Create request via UI or git 2 Review, revise, rinse & repeat 3 Approve & merge request-pull
  42. Peer code review
  43. Additional Considerations
  44. It’s not “pure CI” beware of goats
  45. Dark features
  46. Q&A
  47. More info at... 1 2 http://atlassian.com/git @Atlassian
  48. #code4acause
  49. THANKS Sven Peters ! Atlassian Ambassador & Geek @svenpet

×