Using git-flow to automate your Git branching workflow

by CarolineW • 9 years ago

25 25 9 years ago

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

brandoncordell• 9 years ago

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.

gepoch• 9 years ago

Warning: opinions

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

geezerjay5• 9 years ago

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.

AlexCoventry• 9 years ago

"Hacker News: the whole thing feels a bit yak shavey to me."

wcarron2• 9 years ago

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.

geezerjay5• 9 years ago

Essentially you're following the git flow workflow.

mgkimsal• 9 years ago

yep. replace "main" with "develop" and that's more or less git flow.

wcarron2• 9 years ago

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.

Maybe that means they're "cold fixes" haha.

jimeh3• 9 years ago

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.

[1] https://commonflow.org/

geezerjay5• 9 years ago

it was overkil and needlessly complicated.

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?

erpellan3• 9 years ago

"isolated from everyone else's commits"

Assumes nobody's changes ever collide or conflict with each other.

Introduces a fear of refactoring and making improvements as you go as that increases the risk of a merge conflict.

Delays discovery of changes being made where you might be able to have some positive input until the work is 'finished'.

jimeh3• 9 years ago

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.

erpellan3• 9 years ago

We commit everything to master and run CI/CD(staging) on every remote push.

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• 9 years ago

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

https://en.wikipedia.org/wiki/Continuous_integration

antoncohen2• 9 years ago

Git Flow has been discussed here many times, I'll repost what I wrote last time (https://news.ycombinator.com/item?id=15379210):

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• 9 years ago

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.

antoncohen2• 9 years ago

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

opsroller• 9 years ago

Fucking plagiarism at its best, here’s the original http://nvie.com/posts/a-successful-git-branching-model/

cyberferret2• 9 years ago

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.

Using git-flow to automate your Git branching workflow

Related Stories