Git Workflows That Work

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.

5f5812aa81bff9a3e1e7a081e76c284c?s=128

Spencer Christensen

May 09, 2014
Tweet

Transcript

  1. 3.
  2. 5.
  3. 6.

    Gitflow • Filled a void - something that wasn’t there

    before • Offered a “successful” workflow • Rapid adoption • “The” way to do it
  4. 9.
  5. 11.

    What’s the purpose? “The purpose of software is to help

    people.” - Max Kanat-Alexander, Code Simplicity
  6. 12.

    Git Workflows Should Help People • Business owners • Project

    managers • Operations team • Developers
  7. 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
  8. 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
  9. 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
  10. 20.
  11. 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
  12. 22.

    Gitflow cont’d • Releases are tagged with a release version

    number • Gitflow helper script to make it easier to use.
  13. 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
  14. 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!
  15. 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.
  16. 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).
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. 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
  22. 36.