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? |
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? |
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.
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 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.
You've got nothing to lose, it's essentially just a naming convention for git. You won't be locked into anything.
That said, git-flow was a great way to introduce sanity to our branching. Our designers figured it out very quickly, too.