We tried git flow for awhile, but it didn't really meet our needs, so we got rid of it. Plus the whole thing feels a bit yak shavey to me.
The main practical concern was that we need to make long-lived releases of our components that we would need to support in the long term. Git flow (and, at the time, its opinionated tooling) just assumes you have the one master branch for making releases. We needed to maintain a few at a time. There have been some accommodations in tooling for this since then [1] so maybe it wouldn't be a problem any more.
From the yak shave perspective, I guess I was just unable to find much of value in this process over a much more ad-hoc approach where people work in branches, rebase from time to time, and then put in for a merge with their team when they're done. All of this to-ing and froing with the develop branch, feature branches, bug branches etc, leads to much more typing and work to do simple things, but doesn't really add a lot of value to the repo in terms of stability or readability or anything else, as far as I can tell.
In my view, git flow abstracts away git even more, and conceals the actual mechanics of branches, commits, and merges, doesn't add much value to the repo, and potentially does harm by detouring devs away from really learning the tools they actually need to understand to do work in industry at large.
Maybe this is something that makes sense at a larger scale? Not sure.
> The main practical concern was that we need to make long-lived releases of our components that we would need to support in the long term. Git flow (and, at the time, its opinionated tooling) just assumes you have the one master branch for making releases.
This is patently false. I really don't know where or even how you got that idea. Git flow holds release branches quite prominently, and the use case they cover is a carbon copy of what you complained git flow didn't supported. It's as if the decision to push aside git flow was made in spite of being entirely oblivious to what git flow actually is in its most basic aspects.
Do not use Git Flow for a web application deployed on your own infrastructure (SaaS, microservice, mobile backend, etc.). It will slow down development and make your software less reliable.
The entire purpose of Git Flow is saving up changes to release later, e.g., saving up for a weekly release event. Don't do that! Deploy your changes as soon as they are ready, if they aren't ready don't merge them into a shared branch. If you do Continues Delivery you don't need "hotfix" branches because every changes goes out as soon as it is ready, so you don't need any of the complexity of Git Flow.
By saving up changes for a release event it means more things are getting released at once. If there is a problem after deployment it will be harder to narrow down the cause. Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on, and expect someone to test and stabilize their changes before release. With trunk-based development (https://trunkbaseddevelopment.com/) or GitHub Flow (https://guides.github.com/introduction/flow/) developers take ownership of their code, and only merge to master after they have tested it. With a good deployment pipeline they can own their code all the way to production.
Git Flow also encourages humans to think about and make up version numbers, like 15.0.5. This is a pointless waste of brain power, web apps don't need version numbers. The artifact systems (packages, containers, etc.) may need something, but it can just be an incrementing number that no on thinks about.
Git Flow wastes so much time, and makes everything it touches so complex, all to enable the harmful behavior of saving up changes for later, and enabling the pointless use of version numbers.
Trunk-based development and Continues Delivery is the default way people develop, it is how you would work if you had a one person company with one customer. It also is how the biggest web companies in the world work. It scales from smallest to largest. Just use trunk-based development. Stay away from Git Flow.
> Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on
I don't see why this assertion would hold true. Anyone can test the code (the developer, the reviewer, the CI server, etc). This code can also be tested by applying it to various branches (current release, older release, etc).
> Do not use Git Flow for a web application deployed on your own infrastructure (SaaS, microservice, mobile backend, etc.).
Web applications, I think, are a special case where continuous change is the norm. Other applications do benefit from versioning. I certainly would be more wary about using Linux distros or git if they weren't versioned like they are now.
> > Git Flow fosters a harmful development mentality where developers merge untested changes to the develop branch, then move on
> I don't see why this assertion would hold true.
The sole and entire purpose of Git Flow is to save up changes for a later release, and have humans come up with version numbers for them[1].
By saving up changes for later you are saying "my changes aren't ready for production, but I'm merging them to a shared branch anyway, and they will be tested later when a release branch if cut from develop".
Contrast that to Trunk-based Development, where master is the only long-lived branch, and it should always be stable and ready for production. That means changes (PRs) must be tested and ready for production[2] prior to being merged.
As you said, Git Flow would still have code review, CI, etc. But the mentality it fosters within a development team is the it is OK to merge things that aren't tested enough to say "this is ready to be deployed right now". After all, a release branch will be cut and tested.
The developers that make the changes are not the ones that cut the release branches. By the time someone cuts a release branch a week or two may have passed since the changes were made. The developers have moved on, and now someone needs to test the release branch (with a week or twos worth of changes) to make sure it is ready for production.
> Web applications, I think, are a special case where continuous change is the norm. Other applications do benefit from versioning. I certainly would be more wary about using Linux distros or git if they weren't versioned like they are now.
Certainly things that require releases shipped to end users with long term support of old release require versions. But a large percentage of the people on HN trying to adopt the Git Flow coolness are doing web applications. Also, I question how good Git Flow is at addressing the need for supporting multiple long term releases at once. But that isn't my area of expertise, so I won't rule it out.
[1] If you remove saving up changes you don't have anything left of Git Flow. Hotfix branches exist because changes that aren't ready for deployment have been merged to the develop branch, and normal "elease branches are cut from the develop branch. But duning the weeks of saving up changes you will need to release fixes for critical bugs, so Git Flow introduces hotfix branches then branch off master. If you aren't saving up changes for later, there is not need for hotfixes, because you would just deploy like normal. So by eliminating saving up changes you eliminate all the complexity of hotfix branches. release branches only exist for saving up changes, so they go away too. With them going away you no longer need a human to make up pretty version numbers. With all that gone there is nothing left of Git Flow.
[2] Ready for deployment, there still can be a short staging or canary process.
These tools are good if you have to use Git-Flow. But I would advice against it. In every single company/project I've worked on that's used Git-Flow, pretty much everyone eventually agreed that it was overkil and needlessly complicated. Something like GitHub Flow is much simpler and straight forward, and typically what we've migrated to, or at least wanted to migrate to. Often such decisions need to go through management, which doesn't always go well due to GitHub Flow not having any rules for versioned releases or a hard-copy specification document among other things.
This is where something like Git Common-Flow [1] tries to fill the gap. Full disclaimer, I'm the author of Git Common-Flow. It was born out of my frustration after one too many arguments about Git-Flow vs GitHub Flow and what GitHub Flow lacks. Common-Flow is essentially GitHub Flow with the addition of versioned releases, optional release branches, and without the requirement to deploy to production all the time.
What's overkill about developing features in a dedicated branch, isolated from everyone else's commits? What's complicated in creating a branch, committing to it, and then merge the changes into the development branch?
The issues I have with Git Flow isn't feature branches, it's the develop branch, and the whole crazy merge dance between develop, release, and master branches. It doesn't provide much benefit and more often than not causes confusion and and problems.
What I'm in favor is is GitHub Flow or anything very similar to it, which just has master and feature branches, nothing else.
> The issues I have with Git Flow isn't feature branches, it's the develop branch
What's wrong with that?
> and the whole crazy merge dance between develop, release, and master branches.
I really don't understand your problem. What's so crazy about separating a stable from an unstable branch, and avoiding to push unstable features when you're preparing a new release?
> It doesn't provide much benefit
I see you never were forced to work overtime just because an overzealous manager decided to merge into a release an unstable feature that ended up triggering crashes in a client.
Do you know what's a good way to avoid that problem? Keeping a stable branch, and not confounding a release with the current state of the development branch.
Whenever I see these sort of complains it appears that the only people who complain about the need to organize a project around separate branches dedicated to track main, release and development branches are people who don't have much (if any) experience working on real-world software development projects.
I have no issues with separating the latest greatest development work from production ready code, I just think the way Git-Flow does it is needlessly complicated with multiple points of redundancy.
For example, the master branch is only ever updated when a release (or hotfix) branch is merged in to master, at which point you also tag master with the release version. Why do you need both a tag and a branch pointing at the latest release?
Instead of ignoring tags, why not use only tags to define releases? At which point you can get rid of master as defined by Git-Flow, and rename develop to master, so you just have a master branch. If the release process (QA, etc.) is lengthy, by all means create a release branch from master to avoid a change freeze. When ready for release, create the release tag on on the release branch and merge it back into master if needed.
Also the whole "feature/" and "hotfix/" prefixes on branch names feels pointless. Why not just call them all "change branches"? Anything that changes stuff, is a change branch. And how about we enforce descriptive names on branches like "add-2fa-support", "fix-login-issue", "update-font-awesome", and "change-search-behavior"? No prefixes needed and yet the purpose of the branches are perfectly obvious.
If I'm not sounding like a complete idiot here, please do have a look at Git Common-Flow [1]. I'm genuinely interested in hearing your feedback about it. Again, full disclaimer, I am the author of Git Common-Flow.
> Assumes nobody's changes ever collide or conflict with each other.
I don't believe that anyone using any VCS expects every single commit to be free from "conflict" or "change collision".
In fact, the whole point of using VCS is that "conflicts" and "change collisions" are a given, thus there is a need to use a specialized tool to manage merges and handle conflicts.
> Introduces a fear of refactoring
On who? They have the exact opposite effect.
Have you ever actually used any version control system?
My point was that any branching strategy will necessarily introduce an integration delay. Instead of merging to master every hour or so, the delay is measured in days. The longer the gaps between merges the larger the change set, the greater the risk and impact of merge conflicts.
And, yes, I have! SourceSafe, CVS, StarTeam, Subversion, Perforce, ClearCase, PVCS, Mercurial and Git in (roughly) chronological order by my reckoning. Thanks for asking.
If you're that worried about merge conflicts, isn't the real problem that you haven't refactored enough for SRP? If two people are working on different things, they probably shouldn't be editing the same code.
I've not used Git Flow, but at my current workplace, we use the following workflow:
- Master, main, and feature branches.
- Main is the trunk
- Work is done on feature branches that correspond to an issue
- Work is merged, once complete, from a feature branch back to main
- Main is about to use a CI/CD system to automate the testing and merging of feature branches and deploying them to a staging env. This is currently manually done.
- Releases are done by periodically merging main into master + squashing all the commits being merged into 1 commit. The result is that every commit on the master branch is a new version/release, which we tag appropriately.
The master branch is protected and only the project lead has the ability to override the protections and push to master. All work is normally merged following a pull request on github. It works very well for us. "Rebase early and often" is our mantra and conflicts are infrequent. I'm very happy with it so far.
Yeah I noticed that it's fairly similar. We don't have release branches, and our merging is less complicated for that. Also, even hot fixes are done on a feature branch, pushed to main, then finally to master.
Yes. Horses for courses, but in every case that I have seen, mostly web apps, merge to master is what works best. And things like long-lived branches, complex strategies and gitflow are a waste of time, counterproductive, or even actively harmful.
Also it's worth noting that unless you don't have a "shared mainline" (i.e. master branch) that all dev changes are merged to, frequently; then you can't have Continuous Integration
Very interesting. We've actually just implemented Driessen's workflow methodology in our own startup just one week ago! Got Flow sounds interesting, but I wonder how easily it will integrate in with our current hive of branches.
Our old technique was essentially to have a branch for each submodule development, and to 'git rebase' and re-use old branches for bug fixes and enhancements to those modules. Now that we have rolled out a full code review process, along with AWS CodeCommit and CodePipeline that allows us to deploy different branches to staging and production, we are busy revamping our branching processes to fit the Driessen model, and I wonder if Git Flow will slot in seamlessly with that??
We've implemented git-flow at work. Do you use git-flow with GitHub pull requests? I've found I'm more so using git-flow for just creating the feature/hotfix branches and then doing my merges inside of the pull request UI. It seems to be working ok for what we need but I wonder if I'm shorting myself on the workflow opposed to merging using the git-flow command line tool.
Literally the very FIRST link on the OP article is a link to the page you posted. I wouldn't call that plagiarism per se, as he pays attribution to the original article right from the outset.
We tried git flow for awhile, but it didn't really meet our needs, so we got rid of it. Plus the whole thing feels a bit yak shavey to me.
The main practical concern was that we need to make long-lived releases of our components that we would need to support in the long term. Git flow (and, at the time, its opinionated tooling) just assumes you have the one master branch for making releases. We needed to maintain a few at a time. There have been some accommodations in tooling for this since then [1] so maybe it wouldn't be a problem any more.
From the yak shave perspective, I guess I was just unable to find much of value in this process over a much more ad-hoc approach where people work in branches, rebase from time to time, and then put in for a merge with their team when they're done. All of this to-ing and froing with the develop branch, feature branches, bug branches etc, leads to much more typing and work to do simple things, but doesn't really add a lot of value to the repo in terms of stability or readability or anything else, as far as I can tell.
In my view, git flow abstracts away git even more, and conceals the actual mechanics of branches, commits, and merges, doesn't add much value to the repo, and potentially does harm by detouring devs away from really learning the tools they actually need to understand to do work in industry at large.
Maybe this is something that makes sense at a larger scale? Not sure.
[1] https://github.com/petervanderdoes/gitflow-avh#creating-feat...