Git Workflows That Work

Presentation given at OpenWest conference May 2014.

You use git for version control, right? Great. How you use it- now that's a different question. There are lots of opinions out there about the "best" workflow. We'll talk about different workflows using git, the pros and cons of each, and ultimately how to choose the right workflow for you and your team.

Transcript

1. Git Workflows That Work Spencer Christensen OpenWest Conference May 2014
2. Git Workflows That Work Prizes to give away!
4. In the year 2010...
5. Gitflow
6. Gitflow • Filled a void - something that wasn’t there before • Offered a “successful” workflow • Rapid adoption • “The” way to do it
7. Git Workflows That Work I’m not going to present “the” way to do it.
8. TIMTOWTDI
9. What’s the purpose? What is the purpose of a software development workflow using git?
10. What’s the purpose? What is the purpose of software?
11. What’s the purpose? “The purpose of software is to help people.” - Max Kanat-Alexander, Code Simplicity
12. Git Workflows Should Help People • Business owners • Project managers • Operations team • Developers
13. Git Workflow Examples...
14. GitHub Flow
15. 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
16. Skullcandy’s workflow
17. 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
18. Master only workflow
19. 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
20. Gitflow
21. 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
22. Gitflow cont’d • Releases are tagged with a release version number • Gitflow helper script to make it easier to use.
23. Backcountry workflow
24. 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
25. Guidelines
26. 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!
27. 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.
28. 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).
29. 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.
30. 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.
31. 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.
32. 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.
33. Software Development Processes Development Deployment Maintenance
34. Software Development Processes Planning Prioritizing Development Acceptance Deployment Evaluation Maintenance
35. 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
36. Prizes!
37. Git Workflows That Work Spencer Christensen OpenWest Conference May 2014