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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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...
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.
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
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.
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.
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 ?
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. :-)
I second that: georgestocker.com/2020/03/04/pleas...
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
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.
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).
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.
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.
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.
That entirely depends on the client...
Thanks for your reply...😊
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?
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.
Who merges from develop to master?
The designated integrator, which might be one person or a team. There might be testing required before, etc.
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.
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.
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...
There is a bugfix branch which will be created from develop branch.
This looks like the same gitflow by Vincent Driessen.
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.