
Using git-flow to automate your Git branching workflow - CarolineW
https://jeffkreeftmeijer.com/git-flow/
======
gepoch
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...](https://github.com/petervanderdoes/gitflow-avh#creating-
featurereleasehotfixsupport-branches)

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

------
antoncohen
Git Flow has been discussed here many times, I'll repost what I wrote last
time
([https://news.ycombinator.com/item?id=15379210](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/](https://trunkbaseddevelopment.com/)) or
GitHub Flow
([https://guides.github.com/introduction/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
> 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.

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

------
jimeh
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/](https://commonflow.org/)

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

~~~
erpellan
"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'.

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

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

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

~~~
geezerjay
Essentially you're following the git flow workflow.

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

------
erpellan
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
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](https://en.wikipedia.org/wiki/Continuous_integration)

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

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

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

