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