As your software project expands, you might be worried about how to deal with multiple project contributors working on many stories all while still being able to deploy code with confidence. Lucky for you, git and the branch-per-feature strategy make it easy to do this. In this webinar, Nik Gregory, Principal Engineer at Acquia, will cover how software development teams can use branch-per-feature to build release candidates that can be easily pushed into production or rebuilt as necessary, all while keeping your deployed code clean. Register for this webinar as we discuss how to successfully use branches in your development workflow. Attendees will walk away from this webinar with a deeper understanding of: - The popular git branching and workflow methods - A deeper dive into the branch-per-feature workflow - The potential pitfalls while using branch-per-feature, and how to avoid them

1. Git Workflows
How to Successfully Use Branching &
Development Workflow Strategies
Nik Gregory
Principal Engineer
Twitter: @nikgregory

2. Syllabus
→ Popular git branching and workflow methods
→ Dive into git branch-per-feature
→ Pitfalls of git branch-per-feature and avoiding them
→ Questions

3. About Me
→ Acquia Engineer since 2009
→ Initial QA/Test hire at Acquia
→ Worked with Acquia hosting, Site Factory…

4. Caveat Inspectoris
→ I am not a git ninja
▪ I know enough about git to get the job done and
google the rest
→ Git development workflows == emacs vs vi
▪ Pick what works for you and your team.

5. Long Running Branches
▪ Master is dev
▪ Releases are a branch
▪ Hotfixes get merged into master
▪ Not very different than CVS or SVN (release branches
are easier to handle)

6. Git fork
→ Maintainer controls merges into official repo
→ Often master is known good
→ Forkers pull from master as master moves
→ Often used in Open Source development
→ Useful in restricting access to the official repo

7. Branch per feature
→ Modified version of git-flow
→ Master is known good production code
→ Each story gets a new branch
→ Mitigates risk when pulling in lots of stories
→ QA and RC branches are built regularly
▪ Master + feature branches
→ Integration is used to catch merge conflicts
→ Shared rereres are your friend

8. Standing on the Shoulders of Giants
→ Based on the work of Adam Dymitruk
→ Refined by Katherine Bailey and myself

9. Git Branch-per-feature

10. Details
→ Create a branch from master for your stories
▪ git checkout master && git pull origin master && git checkout –b JIRA-1
▪ git checkout master && git pull origin master && git checkout –b JIRA-2
▪ …
→ Code like no one is watching, commit, push to origin
→ Merge your work into the integration/QA/RC branch
▪ git checkout <(integration|QA|RC)branch> && git pull …
▪ git pull –no-rebase –no-ff [--no-edit] origin JIRA-1
▪ …

11. Merge Conflicts
→ Use your integration branch as the conflict detector
→ Use git rerere to record your conflict resolutions.
→ Share your rereres with the git-bpf gem
→ Rebuild your QA/RC branches as needed
→ Recreate Integration from master as master moves

12. Quick and dirty examples
→ Install (gem install git_bpf) and initialize git-bpf

13. Cont…
→ Build your branch

14. Record resolutions
Fix your stuff git-bpf will share your resolution

15. Rebuild your branch

16. Add more work and rebuild

17. Exclude branches

18. Advantages
→ Usually trivial to pull out stories (see the Q&D earlier)
→ Story branches always start from the tip of master
→ Rebase is no longer scary
→ Rebuild your QA/RC branches as needed

19. Advantages, even more
→ You do not need to release broken code!
→ Run through tests and things go sideways
▪ Rebuild a new RC
▪ Validate
→ No panic feature flags!
→ Master is still known good best code.
→ To reiterate: the most important advantage is being able to
NOT release stories

20. Pitfalls
→ Overhead to deal with many branches and merging
→ Common code changes are needed among several branches
▪ Are your stories nice independent releasable units?
▪ Can you use a parent /child branch to share?
→ Incorrect Resolution is recorded.
▪ Minor brain surgery on .git/rr-cache
→ Pulling out branches sometimes requires new rereres
▪ Are you all working in the same section of code?
→ If master moves rebase your branches to HEAD of master

21. Questions?

22. Resources
→ Kat Bailey’s writeup: https://dev.acquia.com/blog/pragmatic-guide-branch-
feature-git-branching-strategy
→ Our jumping off point http://dymitruk.com/blog/2012/02/05/branch-per-
feature/
→ git-bpf gem
→ Git-flow http://nvie.com/posts/a-successful-git-branching-model/
→ Git command visualizations http://onlywei.github.io/explain-git-with-d3

23. Thank You