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.
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?
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.
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.
[+] [-] gepoch|8 years ago|reply
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...
[+] [-] geezerjay|8 years ago|reply
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.
[+] [-] AlexCoventry|8 years ago|reply
[+] [-] antoncohen|8 years ago|reply
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.
[+] [-] u801e|8 years ago|reply
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.
[+] [-] jimeh|8 years ago|reply
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.
[1] https://commonflow.org/
[+] [-] geezerjay|8 years ago|reply
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?
[+] [-] wcarron|8 years ago|reply
- 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.
[+] [-] geezerjay|8 years ago|reply
[+] [-] erpellan|8 years ago|reply
If some work isn't release-ready by EOD it's pushed to a branch overnight so it's not just on a single laptop.
That's it. Works great!
[+] [-] SideburnsOfDoom|8 years ago|reply
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
https://en.wikipedia.org/wiki/Continuous_integration
[+] [-] cyberferret|8 years ago|reply
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??
[+] [-] brandoncordell|8 years ago|reply
[+] [-] opsroller|8 years ago|reply
[+] [-] cyberferret|8 years ago|reply