Hacker News new | ask | show | jobs
by modderation 2052 days ago
Git Flow actually makes some sense if you need to track and retain history of self-contained fixes and features across concurrent release trains, where "retain history" means more than just a commit message.

With that said, I don't think this need is particularly common. Most projects are happier to throw away merge history in favor of a linear history with ephemeral branches and semantic versioning, and that's perfectly fine. The repository layout should be dictated by the project's needs, be it a glorified personal Undo Log, or a management tool on top of a Subversion repository.
2 comments
NateEag 2052 days ago
The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

https://www.endoflineblog.com/oneflow-a-git-branching-model-...

If you can tell me something GitFlow buys you which OneFlow doesn't, I'd be very intrigued.

link
barumi 2051 days ago
> The author of "GitFlow Considered Harmful" put out a simpler workflow that achieves all the upsides of GitFlow with none of the downsides:

I see no relevant difference between that workflow and GitFlow, besides the rebranding of old concepts and some unexplained focus on merging options.

I've also revisited the author's old rant from 2015 regarding gitflow and the only tangible criticism he had was the separation of the master/mainline and development branches, which is extremely shortsighted and miopic as it fails to acknowledge the reality of non-CICD/old-fashined software release lifecycles.

GitFlow has one main concept: using feature branches to do develop work, use release-specific branches to integrate changes, establish and enforce upstream/downstream relationships between branches. The rest is just rebranding and nit-picking over semantics.

link
globular-toast 2052 days ago
That's not git flow, that's just release/maintenance branches.

The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master. There is no point of that at all. Look at the diagram, move all tags from master to develop, delete master and rename develop to master. There, you now have the workflow you've described without redundant branches.

link
barumi 2051 days ago
> The main feature of git flow is having multiple redundant branches for no reason. Namely a separate develop and master.

This statement is simply wrong and ignorant.

The reason why mainline and develop branches exist is due to the fact that production-ready code and unstable code are not the same ops-wise.

Nowadays, with the dissemination of CICD practices, that difference has been shifted away from the source code repository and into the Delivery/Deployment phase of a CICD pipeline. Yet, the overall principle is the same, and arguably its still here. Calling those differences "redundant and for no reason" is just ignorant at multiple levels, from software engineering to the fact that the sofware lifecycle process for commercial software projects, the kind that had to "go gold", had very specific requirements.

link
globular-toast 2051 days ago
You don't have to look hard at the git flow diagram to see the redundancy. It's plain as day. Of course I'm talking about today. Why would I be talking about 20 years ago? We have continuous integration and automated build pipelines so there's no reason to have your build artifacts living in the git repository. git is for source code. There are other solutions better suited to storing artifacts.
link