
Ask HN: Who uses gitflow? - spaux
We&#x27;re looking at switching to gitflow (http:&#x2F;&#x2F;nvie.com&#x2F;posts&#x2F;a-successful-git-branching-model&#x2F;), but the decision makers are on the fence. Are there any examples of a successful gitflow project?
======
jcmurrayii
My team uses gitflow as part of our normal development process. As gitflow is
just a process for managing your branching and merging features into your
mainline branches, no project out there will show 'success' based solely upon
using gitflow.

Here is why we use gitflow:

We have 5 developers working on a project at a time.

We release versions of this application to our testing environments twice a
day, and to production every 1-3 days.

Before we started using gitflow, we had deployments to our production
environment hald back due to commits that weren't tested yet, and thus having
no surety that we were good to go to production. Now that we use gitflow, my
developers keep their work in feature branches, can commit at will, and only
merge it back to our develop branch when the feature is complete. Furthermore,
we use 'releases' in git flow as well, so I can take a snapshot of develop,
make changes only to fix what is in a release, and merge the release back when
it is signed off on by the business. It has allowed us to continue to move
VERY quickly, and still control precisely what is in each build.

The killer feature, for me at least, is the 'hotfix' feature though. With
deploying as often as we do, there are bound to be issues that need to be
fixed right now. using 'git flow hotfix' I get a branch that is based off of
master (production), can make the changes we need, and when I merge it back,
it is automatically merged to both master and develop, tagged as a release,
and I can deploy a build from master immediately.

------
rubiquity
Gitflow seems a bit too complicated for my liking. I've been using Scott
Chacon's "GitHub Flow"[0] for over three years, with the added twist that
after the PR has been reviewed and approved, I rebase all of my commits to a
single commit with a descriptive commit log of changes and a link to a
Trello/Basecamp/whatever card for the feature.

0 - [http://scottchacon.com/2011/08/31/github-
flow.html](http://scottchacon.com/2011/08/31/github-flow.html)

~~~
qohen
[0] [http://scottchacon.com/2011/08/31/github-
flow.html](http://scottchacon.com/2011/08/31/github-flow.html)

~~~
rubiquity
Haha, whoops. Thank you.

------
kasey_junk
I recently started with a group that uses gitflow. It is my first experience
with it. Thus my experience with it is pretty ignorant.

That said, it seems to be way too heavy weight to me. Especially given modern
DVCS abilities. I literally cannot figure out the advantages of having a
master branch and a development mainline vs just using tags.

Basically it seems to be a workflow with the assumption that branching is
hard, based on a version control system where branching is easy.

TLDR; Ignorant view == skip it.

------
marcofiset
We have been using it for a year and had absolutely no problems whatsoever. We
create feature branches for almost everything that requires more than a single
commit. It allows us to check in temporary breaking changes in our branches,
without impacting the work of other developers.

We use release branch when we have a fixed feature set that we're ready to
deploy.

Hotfixes for live problems that need to be fixed ASAP.

------
usingpond
Yes you should use it. We name feature branches after JIRA tickets for
accountability and transparency. It's made tracking branches and tickets
associated with them super easy and fast.

You've got nothing to lose, it's essentially just a naming convention for git.
You won't be locked into anything.

------
erichurkman
We use the idea, but I think most of our team has abandoned the actual git-
flow scripts. We manage our pull requests via Github, so the git-flow feature
finish workflow wasn't being used.

That said, git-flow was a great way to introduce sanity to our branching. Our
designers figured it out very quickly, too.

------
SEJeff
Also look at "github flow" which is a slight modification of the original git
flow design:
[https://guides.github.com/introduction/flow/index.html](https://guides.github.com/introduction/flow/index.html)

------
t0mbstone
I have used git flow for a number of projects (everything from small-time to
enterprise-scale) and it seemed to work just fine, from what I saw. Just my
two cents.

------
jarin
git-flow is just an easy way to manage your branching. There's nothing locking
you into it, since it's just a branch naming system and shortcuts for regular
old git commands, so you might as well just try it. I think you'll find it's
very nice and easy to work with. If for some reason you don't like it or it
doesn't work for you, you can just stop using it.

------
mswift
What reservations do you have about it? What is your current workflow?

