Git WorkflowsHow to Successfully Use Branching & Development Workflow Strategies

Nik GregoryPrincipal EngineerTwitter: @nikgregory

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

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

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.

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)

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

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

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

Git Branch-per-feature

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▪ …

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

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

Cont…→ Build your branch

Record resolutionsFix your stuff git-bpf will share your resolution

Rebuild your branch

Add more work and rebuild

Exclude branches

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

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

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

Questions?

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

Thank You