Ask HN: Who uses gitflow?
We're looking at switching to gitflow (http://nvie.com/posts/a-successful-git-branching-model/), but the decision makers are on the fence. Are there any examples of a successful gitflow project?
10 comments
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.
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.
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
0 - http://scottchacon.com/2011/08/31/github-flow.html
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.
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.
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.
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.
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.
You've got nothing to lose, it's essentially just a naming convention for git. You won't be locked into anything.
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.
That said, git-flow was a great way to introduce sanity to our branching. Our designers figured it out very quickly, too.
Also look at "github flow" which is a slight modification of the original git flow design: https://guides.github.com/introduction/flow/index.html
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.
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.
What reservations do you have about it? What is your current workflow?