DEV Community

Cover image for Advantages of Git-flow over standard git commands

Advantages of Git-flow over standard git commands

Soumya Dey on September 14, 2020

In this post we'll look at a git workflow called Git-flow, and discuss why you should use it over the standard git commands. What is gi...
Collapse
 
darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

Nice article, but as always with this kind of tool, I'm very sceptical about it's actual usefulness. It sounds a lot like a very small improvement for someone who knows git already and a very good excuse not to get to know it better for everyone else.

Collapse
 
soumyadey profile image
Soumya Dey • Edited

Git-Flow integrates very easily into your existing Git. You dont have to change anything, only your workflow will be optimized. It will also improve your project structure. But that doesn't mean you have to always use it in all of your projects.
But yes you can always give an excuse for not learning a new thing.

Btw thanks a lot for your reply...

Collapse
 
leob profile image
leob

It occurs to me that you can do all of the above quite easily with standard Git commands. If it's an approach and a philosophy then fine, but I don't think I'd need a specialized tool or commands per se.

Collapse
 
soumyadey profile image
Soumya Dey

Yes...as I said in the post...git-flow is not a replacement for standard git commands...it just combines some standard commands and automates some tasks to make your workflow more optimized...
You can do all these manually...Git-flow just makes it easy for you

Collapse
 
bloodgain profile image
Cliff • Edited

You would think, but experience has taught me that on a team with other programmers, a standardized workflow is a really good idea, approaching absolutely necessary. Some people need help remembering how to do each step in a workflow, and well-written scripts can help avoid mistakes for everyone. And it's much better to use community-tested tools like this than write your own, unless you really are a master at git and have a special requirement that couldn't be met just by configuring your repo and/or adding hooks and using a well-tested tool like this one.

It also helps if you realize that Git Flow is a standard workflow for Git, and these scripts implement it for you.

Collapse
 
jonlauridsen profile image
Jon Lauridsen

I recommend fully and completely against git-flow:
Research shows effective teams deploy multiple times a day, but git-flow discourages that by adding the “develop” branch, and by introducing feature branches and hot fixes. Those concepts are all performance-negative.

Science shows we should aim to have a single main branch that is always deployed, and just commit to that. Any branches you create must live for a maximum one day, preferably much shorter. Don’t worry about hotfixes either, just land changes to main branch. Instead featureflags become the way to control what and when things are released

git-flow is a tool and workflow that can look impressive, but it actually puts up more barriers and adds more deploy latency where science suggests we should aim for less.

The science I refer to is DORA and Accelerate book by Dr. Nicole Forsgren.

Collapse
 
leob profile image
leob • Edited

As with all of these new or different techniques or approaches you need to begin by asking yourself: what problem am I trying to solve ?

If the way you work right now is fine and there is no problem really, then just stick with what you're doing and don't jump on the latest bandwagon because it's "hipster" or because everyone does it.

So is Gitflow good or not - as always, "it depends" ... but the moment someone offers me a "solution", then the first thing I ask: okay cool, but what was the problem again ?

Collapse
 
bloodgain profile image
Cliff

If you're already doing Continuous Release, I agree Gitflow probably isn't going to help your team.

However, not everyone is doing or can do Continuous Release, for any number of reasons. Those teams can often be helped by defining a standardized workflow that everyone follows. For instance, I work on a simulation for a government customer that has integrated test dates and milestones we have to follow. So we have a fielded build we have to support with hotfixes, a future build of that line for the next integrated test, and a future build that adds support for whole new assets that will require a lot of early development before it's ready to be deployed that we can't hold up the next build for. I've been trying to suggest that my project adopt Git Flow or a modified version of it because that's still WAY better than what we're doing right now, which involves lots of dev and release branch cross-merging instead of merging selectively and consciously from hotfix and feature branches.

As an aside, though, thank you for actually backing up your "research/science shows" statements with the source. I was going to accuse you of using weasel words there, but now I have a book to check out. :-)

Collapse
 
xavierbrinonecs profile image
Xavier Brinon
Collapse
 
soumyadey profile image
Soumya Dey

That's your opinion...and its fine... everyone doesn't like the git-flow...
But forget about feature branch and hotfixes....even if you only have a develop branch...it keeps your deployed code more error and bug free...

Thanks a lot for your reply

Collapse
 
dhandspikerwade profile image
Devin Handspiker-Wade

I like git-flow, however I always seem to run into the same problem. When feature requires client or external stakeholder feedback before it could be considered done, where does that fit? External feedback could come back in minutes or months and doesn't make sense to block a release.

Collapse
 
stereoplegic profile image
Mike Bybee • Edited

That's on the stakeholder, and you need to set a deadline for their feedback. If feedback is still absent at the deadline, and the PR passes tests, (dev team) review, and definition of done, you push the release without them. If you never got the feedback required to complete, you make a decision on what to do with it (keep the branch alive while rebasing, save a diff, or just kill it, and close the issue as stale due to no feedback).

The key in either case is to document your attempts to get feedback and the stakeholder's failure to provide it (CYA).

Collapse
 
dhandspikerwade profile image
Devin Handspiker-Wade

Maybe it's because I am viewing this as an agency, but none of that seems possible.

The definition of done requires the client's approval as something cannot be released to a client's site/app/service without their approval. Going back to a client with "The change needs to be re-tested " when they finally provide their feedback is a good way to end up with unhappy clients.

Thread Thread
 
stereoplegic profile image
Mike Bybee

I wasn't speaking specifically to clients (many stakeholders are internal, and I've worked numerous projects where all of them were), but even with external clients, you need language in the contract for cases where they are not responsive.

And sure, it is often the case that the feature just doesn't get pushed (but the client is still billed for your time) if they fail fulfill their obligation as a stakeholder.

And again, CYA applies universally.

Collapse
 
joeyguerra profile image
Joey Guerra • Edited

I've observed that client feedback requires them to see a working demo. And so to solve that problem, we do weekly demos. I really encourage daily demos (doubling down on the principle of short feedback loops to help me mitigate alignment issues).

Then the problem becomes, how do I deploy this version so that I can demo it. This is where having a Developer Enablement Platform (fancy word for k8s or Cloud Foundry or some Platform as a Service that lets developers deploy versions from their machine or pipeline) helps enable this. I fully acknowledge that this can be hard, politically, technically and financially :(

BTW, I've used glitch.com as a way to demo.

Collapse
 
soumyadey profile image
Soumya Dey

That entirely depends on the client...
Thanks for your reply...😊

Collapse
 
joeyguerra profile image
Joey Guerra

If there's a long-lived develop branch, what's the point of having the master branch anymore if it's never used to build the published artifact from?

What's your recommendation for when multiple people are adding separate features to a single repo and there's a deployment happening on Thursday but only 1 feature is ready for deployment and the others are still being worked on?

Collapse
 
soumyadey profile image
Soumya Dey

You didn't understand the workflow properly. The develop is there to save the master branch from any unwanted bugs. It works like a guard in front of the master.
And when ready the develop branch will be merged with the master.

And when several people are working on a repo... everyone will work with their own separate feature branch. When the feature is ready they will finish that and it will get merged to the develop, which will then be merged to master.
And master is the branch that is used to deploy your code.

Collapse
 
joeyguerra profile image
Joey Guerra

Who merges from develop to master?

Thread Thread
 
bloodgain profile image
Cliff

The designated integrator, which might be one person or a team. There might be testing required before, etc.

Thread Thread
 
joeyguerra profile image
Joey Guerra

My apologies. This post is about the tool. I got caught up in the underlying branching strategy that it supports, which touches a smallish nerve.

Thank you Soumya for writing this article. I really appreciate being reminded of past strategies and challenging the decisions that we made in the past to see if they are still valid in the present.

Collapse
 
bloodgain profile image
Cliff

Yeah, it can kind of be confusing if you don't read up about git flow first. This article is more about the support tool/scripts.

The releases sit on the master branch as tags. There is no standalone release branch. The dev branch is more like a dev and test branch that you release from. But any new hotfixes or new, separate releases might be branched off of master.

Collapse
 
bloodgain profile image
Cliff

There are some criticisms below of the Gitflow model. These criticisms are not new. Scott Chacon explained 9 years ago why it wasn't the right choice for GitHub's continuous release flow and explained the GitHub workflow:

scottchacon.com/2011/08/31/github-...

And if you go back to Vincent Driessen's original blog post introducing it, you'll note that he's made an update about why even he doesn't think it's the right fit for Continuous Release, with the reminder that context matters:

nvie.com/posts/a-successful-git-br...

Collapse
 
alibahaari profile image
Ali Bahaari

There is a bugfix branch which will be created from develop branch.

Collapse
 
ssinad profile image
Sina D

This looks like the same gitflow by Vincent Driessen.

Collapse
 
bloodgain profile image
Cliff

He didn't claim it wasn't. If you read the README for the extension he's recommending, the author, Peter Vanderdoes, credits Vincent Driessen and links to his article.