Hacker News new | ask | show | jobs
by antoncohen 3186 days ago
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.

Edit: Fixed spelling of incrementing.

3 comments

> 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.

Version numbers are used to represent specific states of the project in order to have fixed testable and auditable versions. It's what the user sees when he needs to check which software version he's using when talking about the software he's using, and what programmers need to know when they need to work on bugs/features present in previous versions of the software but not on others. If your app needs to be debugged and there are peopleother than yourself using, testing or working on the software, it needs version numbers. Otherwise, everyone will needlessly waste their time.

Version numbers waste as much brain power as knowing the name of someone you need to contact on a daily basis. You don't need to make up version numbers because plenty of people already did that. For instance, Semantic Versioning is a thing.

http://semver.org/

Notice I said "web application deployed on your own infrastructure".

While you said "[versions are] what the user sees when he needs to check which software version he's using when talking about the software he's using, and what programmers need to know when they need to work on bugs/features present in previous versions of the software but not on others."

In good SaaS products users don't see version numbers. What version of Gmail are you using? What version of GitHub? They don't have versions. There are also only two versions of your software, what is deployed and what us being deployed (or multiple "being deployed" if you have multiple canaries). Engineers can look up build numbers and changes in the CI system or other internal tracking tools without humans making up version numbers.

Semver is great for libraries and shipping applications, where third parties need to know about breaking changes so they can adjust their applications or configuration.

When deploying your own app to your own infrastructure, Semver wastes people's time. I've worked at a company that switched to Git Flow right before I started. I've seen so much time wasted by people discussing versions and branches. Should I merge to develop or a release branch, or is it a hotfix, should it be 15.1.0 or 15.0.1, or no, someone else claimed 15.0.1 before me, now I'll rename my branch to hotfix-15.0.2, oh 15.0.3 is done being tested before my 15.0.2, so they will rename to 15.0.2 and I'll rename to 15.0.3, oops I forgot to merge their changes into my 15.0.3 so I reverted 15.0.2, now I need to deploy 15.0.4 that has the changes from 15.0.2 and 15.0.3.

Seriously, no joke, this is what happens what you try to use Git Flow for a web app.

Not everything is a Web App. Git flow is more appropriate for libraries and things that do have versions and branches.

Not everything must be one size fits all. There are many different ways to code.

An incriminating number indeed.