DEV Community

Cover image for Git-Flow vs Github-flow
Massii
Massii

Posted on

7 1

Git-Flow vs Github-flow

Git-flow

Git-flow was described by Vincent Driessen on his 2010 post A successful Git branching model. I’ve found it to be a great way to organize a repository. In short, you:

  • Keep your master branch as the code that has been released,
  • Use a develop branch as the current “snapshot” of what will go into the next release - your living beta,
  • Spawn off feature branches off develop for every new feature, which are merged back into it when they’re ready,
  • When you are ready to release, you merge to master and tag with a release version.

There are other considerations for how to deal with hotfixes, but that’s the gist of it. You can see a git-flow diagram below:

This is a great approach and it has several advantages:

  • master always remains as a stable reflection of your live code,
  • You can trivially do hotfixes without worrying about unfinished features,
  • Feature branches ensure that teams working in parallel don’t trip over each other and that conflicts need to be handled only once (the moment the feature is done),
  • It allows teams to cherry-pick changes other teams may be doing on their feature branches, without needing these commits to be on develop already,
  • It lets you do a release off develop at any point - if a feature isn’t ready, that’s OK, you just leave it for the next release.

There are helper scripts to assist you with Gitflow. Atlassian’s SourceTree supports it directly as well.

Github-flow

Proponents of Github-flow (and its cousin Gitlab-flow) have a few complaints about it. The main argument is that it goes against continuous delivery, since at some point someone needs to “flip a switch” and do a release from develop into master.

That’s a valid argument. Nothing is less continuous than manual switch-flipping.

The Github-flow proposal is that you should:

  • Do away with the develop branch altogether,
  • Spawn all feature branches off master, and merge them back into master when ready,
  • Version tagging should not be carried by a human, but by an automated process whenever code is pushed to live,

These are valid points and they do result on a lighter-weight workflow. But they ignore that there are cases where you want a manual release, a negotiation of what is supposed to go into any particular version.

My take on it

Both systems have their uses. I think something like Github-flow is a great approach if what you are developing is an application. On that case, just using a master branch plus features branches works well, and you can do your releases in an automated fashion. The deployment itself is the atomic end-product you care about.

When you are building a library, where people outside your team might depend on specific versions, I think git-flow is the right approach. For a library, you want to lump your versioned changes together into a conceptual unit - including potentially separating or delaying breaking changes. At this point, coming to an agreement on what should go into a version makes sense, as does the manual release process of git-flow.

If anybody outside of your team depends on your versioning scheme, or will need to have a clear conceptual overview of what changed on a particular release, I’d recommend using git-flow.

If whatever you are releasing is the final artifact, and it will be used but others will not need to reference its version, then GitHub-flow does the trick.

Source

Do your career a big favor. Join DEV. (The website you're on right now)

It takes one minute, it's free, and is worth it for your career.

Get started

Community matters

Top comments (0)

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay