Organizing a project is hard. You have all of these different personalities you have to bring together, all of these technologies you have to make sense of, and to top it all off, you need to make sure your client is getting your best code at any given point. There are numerous methods available to help with organizing your code, but with time and money on the line, it can be quite a daunting task.
Enter Gitflow.
Gitflow is a method of organizing your code based off a blog post from Vincent Driessen (http://nvie.com/posts/a-successful-git-branching-model/). It describes dividing the branches of your git repository into several different roles. These roles help keep code neat and tidy, and prevent issues of overwriting and conflicts.
The branches that Vincent outlines are as follows:
- Master branch: This is the main release branch, and should be the most polished code available. This branch is created via the next branch,
- Release Candidate branch: This branch contains code that is almost ready for release, but may need additional bugfixes before becoming ready for full release. This branch is based off the next type of branch,
- Develop branch: This is the current build for the application, and may contain more unstable code. These are also known as snapshot builds or nightlies, as they are updated on a daily basis.
Master, Release Candidate, and Develop branches should never be pushed into directly. To add new code to these static branches, you should use the working branches that Vincent describes:
- Hotfix branches: These are branches off master containing very specific bugfixes for the master environment. These are emergency creation branches, and should not be the normal method of merging in new code. That honor is bestowed upon:
- Feature branches: These are branches that are created by the individual developers on a per-feature basis. New unstable code is created and debugged here, and is pull requested into the develop branch. Using separate working and static branches allows the main code to remain as pure as possible, and free from the clutter the development process entails.
A handy tool designed to assist with this type of git usage is available via Hubflow (https://github.com/datasift/gitflow). Feel free to take a look at that tool for simplifying the process of utilizing gitflow in your daily workflow.
In connection with Gitflow, Semantic Versioning allows any user to see where in the development process an application is. It uses an X.Y.Z-BuildNo format, where X is a major release with breaking API changes, Y is a minor release with solely non-breaking feature additions, and Z is bugfixes designed to correct issues in previous features. The -BuildNo at the end is used to denote a snapshot version or release candidate, so the user is aware that it may be more unstable than normal releases.
As Gitflow and Semantic Versioning is followed on individual projects, it will solve many issues in communicating the current state of the application, and ensure that all the developers involved are working nicely together.
For a more in depth overview of this training, feel free to take a look at the source documentation at http://therebelrobot.github.io/HubFlow-Site/build/#
