Comparing Git Workflows

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

We have some fun with our names, get ahead of ourselves during Survey Says, and vet Michael’s tip on-air as we take a deep dive into comparing some popular Git workflows and when should we use which.

Reading these show notes via your podcast player? View this episode’s full show notes and participate in the discussion at https://www.codingblocks.net/episode90.

Survey Says

News

Thank you to everyone that left us a review!
- iTunes: Paul Kettley, Rick_foil, CullCull
- Stitcher: FresidentDumazy, Guilderm

Why talk about Git workflows?

Git it a toolkit: designed as a set of programs that you can chain together to manage your code.
Git is not opinionated, but lots of people have opinions about how you should do it (branches, tags, rebase, merges, dependencies, commit hooks, pull requests, forking vs cloning).
Check out the source code (GitHub)! There’s a commit.c and a bisect.c and a …
- There are also Python files, UI, Bash, Perl….
Git is really complicated (see list of controversial topics above).
Your source control workflow is a big part of your workflow, so it has a big impact on your day to day quality of life.
Ideally your Git workflow is going to align well with your business processes, so it’s good to take a look at the most common strategies rather than blindly pick what you think is the most popular.

Git Workflows and When to Use Them

Centralized

How it works

*All* changes are committed directly to master.
No other branches are necessary for this workflow.
The central repo is *the* official project and should be treated as sacred and immutable (i.e. no rewriting history).

Example

Clone the repo (i.e. git clone).
Make, stage, and commit changes. (i.e. git add, git commit).
Merge in the latest from the central repo (i.e. git pull similar to svn update).
- Use git pull –rebase to move all of your commits to the tip of the history.
- This will allow you to handle any conflicts on a case by case basis.
Push changes (i.e. git push similar to svn commit).

Pros

Easy to understand workflow for those transitioning from Subversion (SVN).
Great for small teams or projects (i.e. few contributors).

Cons

Resolving conflicts can be a burden as the team scales up.
Doesn’t leverage Git’s distributed nature.

When should the seasoned Git guru use it?

Small projects that don’t change often are good candidates
- No sense in creating extra process when it’s not necessary. Until it is.

Feature Branch Workflow

How it works

All development for a new feature is performed in a dedicated feature branch.
This allows multiple developers the ability to iterate on a feature without modifying master.
- _Hopefully_ this means that master never gets incomplete code, making it advantageous for continuous integration/deployed environments.
This feature encapsulation allows teams to utilize pull requests.
- This allows teams to discuss and review code before it’s merged into master.
Some workflows build on top of this workflow, such as Gitflow and Forking Workflow.

Example

Start from master (i.e. git checkout master).
Create a new branch off of master (i.e. git checkout -b MyNewFeature).
Similar to before, make, stage, and commit changes (i.e. git add, git commit).
Push your new branch to the remote (or centralized) repo (i.e. git push origin MyNewFeature).
Use the tooling of your repo management system to create a PR (i.e. GitHub, GitLab, VSTS, Bitbucket, etc.)
- Note that if there are conflicts, those will need to be corrected locally (i.e. git pull –rebase again) and the feature branch re-pushed.
Prior to the pull request, if another developer wanted to contribute to the feature branch, they could pull it locally to contribute to it (i.e. git pull MyNewFeature) assuming the feature branch has already been pushed to the centralized repo.

Pros

Promotes code review and team collaboration.
Keeps master stable.

Cons

Long lived branches have a higher risk of merge conflicts, best to keep your features small.

When should the seasoned Git guru use it?

Always? /8)
- This workflow is likely the building block to another workflow you need.
Definitely best used for large teams and/or projects.

Gitflow

How it works

Builds upon the Feature Branch workflow.
However instead of just a master branch, you create additional branches with very specific purposes.
- As well as specific times when those branches should interact.
The master branch represents the officially released versions.
- Create version tags off of master.
A develop branch is used to iterate on the next version.
- All new feature branches are based on develop instead of master (unlike the Feature Branch workflow).
When it’s time to release, a new release branch is based off of develop.
- Fixes to the release are made directly to the release branch.
When the release has been tested and ready for production (i.e. release to manufacture, etc). the release branch is merged into both master and develop.
- This is when you tag master with the version number.
Hot fixes are made in separate branches based off of master.
- These are the only branches that are based off of master.
- Once the hot fix is complete, the hot fix branch is merged into both master and develop
- Tag the version in master.

Example

So, so, so many commands. See Atlassian’s write up for a complete walk through of this workflow with the necessary commands.

Pros

Ideal for projects with a scheduled release cycle.
Great for projects where you only need to support one version, for example, your company’s website.
All of the benefits of the Feature Branch workflow, i.e. pull requests, isolated feature development, collaboration.
Tooling exists to help streamline the process.
Master only has stable code.
Allows one team to polish the release while another(s) can work on features for the next release.
Hot fix branches allow teams to address issues without disrupting other teams working to polish a build or develop new features for the next version.
- Atlassian refers to this benefit as a “dedicated channel for hot fixes to production.“
No commits left behind.

Cons

Doesn’t work well with projects that need to support multiple versions concurrently, for example, supporting code for all currently supported versions of Windows.
- Welcome to Merge Hell. Population: You.

When should the seasoned Git guru use it?

Works great for projects that tend to roll forward.

Fork & Merge

How it works

Rather than everyone working off the same centralized repo, every developer gets their own server-side repo to work on.
Typically used / seen in the open source community (like projects on GitHub).
This avoids the situation where everyone is pushing code to the same central repo. Rather developers make changes in their own repo and when ready, submit a merge request from their own repo to the central repo.

NOTES:

Forked is nothing more than a server side git clone.
Typically you’ll have two remotes with this workflow, one for your forked version and one for the primary repo.
- By convention, yours will be named origin and the main will be called upstream.
- Having an upstream means you can keep your copy of the repo up to date with the latest from the primary, while continuing to work on your changes.

Example

Original repository is created – CodingBlocksRepo.
Billy Bob “forks” the CodingBlocksRepo, creating a new, personal / public copy on the server.
Git clone the newly forked repo to local – private work copy.
Commit any changes and push to the forked repo, not the original repo.
Issue a pull request from the forked repo with the latest changes over to the original repository.
- Discussion about the branch / changes can also occur as part of this process.
Original repo maintainer pulls branch to be integrated down to local, then merges it into their local master branch.
Maintainer then pushes master up to main centralized repo.

Pros

Keeps primary repo’s nice n’ clean.
Limits those who have write access to the upstream repo.

Cons

More work and slightly more complicated than other workflows.

When should the seasoned Git guru use it?

Any time you plan to contribute to open source projects on GitHub, Bitbucket, etc.

Microsoft’s Recommendations

How it works

Similar to Gitflow, Microsoft’s branching guidance will use release branches (plural!).
The biggest difference with this strategy compared to other workflows is the lack of merging (yay!).
Similar to the Feature Branching workflow, you’ll create feature branches off of master.
- These feature branches are the only branches that get merged.
When it’s time for a release, you create a new release branch for that version (i.e. the version will be part of the branch name).
Any fixes to a release should be cherry picked to all of the other relevant branches that need the fix
No need for tagging versions.

Example

The new command here is git cherry-pick.
- Michael typically includes -x when using the command line.

Pros

No more merge hell.
Total control over which commits get merged and where they are merged to.
No “I forgot to push the latest tag” issues.
Works well for large projects/teams.
Perfect for software with multiple versions that need to be supported concurrently.
When there is a merge conflict, _you_ know the details (i.e. _your_ code is involved).

Cons

Very easy to forget to cherry pick a commit to every branch it needs to go to (or maybe you didn’t even know all of the branches it needs to go to).

When should the seasoned Git guru use it?

Great when you need to support multiple concurrent releases.

Resources We Like

Git (GitHub)
Comparing Workflows (Atlassian)
Types of Git Workflows (GitHub)
Adopt a Git branching strategy (docs.microsoft.com)
Opinionated Git
Git Tips (Viget)
Microsoft Re-Designs the iPod Packaging (YouTube)

Tip of the Week

CodePrep.io – Ace your next coding interview!
Every Git tip you’ll need. Ever. (GitHub)
Learn Julia! (JuliaLang.org)

Share the joy

Comparing Git Workflows

Sponsors

Survey Says

What's your social platform of choice?

News

Why talk about Git workflows?