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
   

   View Slide

2. Git Workflows That Work
   Prizes to give away!
   

   View Slide

3. View Slide

4. In the year 2010...
   

   View Slide

5. Gitflow
   

   View Slide

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

   View Slide

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

   View Slide

8. TIMTOWTDI
   

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

13. Git Workflow Examples...
    

    View Slide

14. GitHub Flow
    

    View Slide

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
    

    View Slide

16. Skullcandy’s workflow
    

    View Slide

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
    

    View Slide

18. Master only workflow
    

    View Slide

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
    

    View Slide

20. Gitflow
    

    View Slide

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
    

    View Slide

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

    View Slide

23. Backcountry workflow
    

    View Slide

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
    

    View Slide

25. Guidelines
    

    View Slide

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!
    

    View Slide

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.
    

    View Slide

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).
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

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.
    

    View Slide

33. Software Development Processes
    Development
    Deployment
    Maintenance
    

    View Slide

34. Software Development Processes
    Planning
    Prioritizing
    Development
    Acceptance
    Deployment
    Evaluation
    Maintenance
    

    View Slide

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
    

    View Slide

36. Prizes!
    

    View Slide

37. Git Workflows That Work
    Spencer Christensen
    OpenWest Conference
    May 2014
    

    View Slide