Git Workflows That Work Spencer Christensen OpenWest Conference May 2014 

Git Workflows That Work Prizes to give away! 

No content

In the year 2010... 

Gitflow 

Gitflow ● Filled a void - something that wasn’t there before ● Offered a “successful” workflow ● Rapid adoption ● “The” way to do it 

Git Workflows That Work I’m not going to present “the” way to do it. 

TIMTOWTDI 

What’s the purpose? What is the purpose of a software development workflow using git? 

What’s the purpose? What is the purpose of software? 

What’s the purpose? “The purpose of software is to help people.” - Max Kanat-Alexander, Code Simplicity 

Git Workflows Should Help People ● Business owners ● Project managers ● Operations team ● Developers 

Git Workflow Examples... 

GitHub Flow 

GitHub Flow ● Anything in master is deployable ● Everything branches off master ● Commit branch locally and on origin ● Send pull request to peers for code review ● After approval, merge branch into master ● Once origin master is updated, deploy 

Skullcandy’s workflow 

Skullcandy’s workflow ● Scrum, sprints, deliverables ● Each userstory/defect = branch ● Anything in master is deployable ● Everything branches off master ● Commit branch locally and on origin ● Send pull request to peers for code review ● After peer review, merge and deploy to QA ● After business approval and ticket updated- auto merge and deploy ● QA branch is just another branch 

Master only workflow 

Master only workflow ● Dev environment is similar to production ● Business owner access to dev environment for testing ● Changes are committed locally ● Peer review by shared access to dev environment, or by pushing local branch to origin ● After approval, merge branch into master ● Once origin master is updated, deploy 

Gitflow 

Gitflow ● At least three long running branches- develop, release, and master ● All work is done in a branch ● Features are branched off develop, hot fixes are branched off master ● Develop is merged into a release branch ● Hot fixes are merged into master, and to release, and to develop 

Gitflow cont’d ● Releases are tagged with a release version number ● Gitflow helper script to make it easier to use. 

Backcountry workflow 

Backcountry workflow ● Different branch names, similar flow ○ master, release, production ● Hotfixes and features branch off master ● Weekly regular release, but emergency release for hot fixes ● Often used ‘cherry-pick’ for just the commits approved to release 

Guidelines 

Guidelines ● Use branches for single releasable units. ○ A single user story or bug fix. ○ Something that can be approved by the business that contains everything needed for that single request to be released- and nothing more! 

Guidelines ● Avoid long running branches. ○ The longer a feature branch lives without getting merged in for a release, the greater risk for merge conflicts and challenges for deployment. ○ Short lived branches merge and deploy cleaner. 

Guidelines ● Business owner involvement in your workflow is essential. ○ Don’t merge, don’t deploy, don’t work without their input. Otherwise pain and tears will ensue (or worse). 

Guidelines ● Avoid reverts. ○ Test, test, test your branch before a merge. When merging use git merge --no-ff, which will ease merge reverts if really needed. 

Guidelines ● Your workflow should fit how you release. ○ Do you release continually, multiple times a day? ○ Do you have 2 week sprints, thus a regular schedule? ○ Do you have a business Change Control Board? ○ Does someone else run your releases? ○ Your branching and merging strategy needs to make releasing easier. 

Guidelines ● Make your workflow simple. ○ Complicated workflows drive people crazy. ○ Ask how you can simplify it. ○ Actively making things more simple will make them easier to understand and work with as well as easier for others to adopt and maintain. 

Guidelines Summary ● Use branches for single releasable units. ● Avoid long running branches. ● Business owner involvement in your workflow is essential. ● Avoid reverts. ● Your workflow should fit how you release. ● Make your workflow simple. 

Software Development Processes Development Deployment Maintenance 

Software Development Processes Planning Prioritizing Development Acceptance Deployment Evaluation Maintenance 

Further Reading ● http://www.codesimplicity.com/post/the-purpose-of-software/ ● http://nvie.com/posts/a-successful-git-branching-model/ ● http://www.kdgregory.com/index.php?page=scm.git ● https://sandofsky.com/blog/git-workflow.html ● http://stackoverflow.com/questions/2428722/git-branch-strategy- for-small-dev-team ● http://git-scm.com/book/en/Git-Branching-Branching-Workflows ● https://www.atlassian.com/git/workflows 

Prizes! 

Git Workflows That Work Spencer Christensen OpenWest Conference May 2014