The very popular and standardized methodology for working with Git is simply called GitFlow. Here is a brief description of the main rules of that flow:
- There is a main working branch, usually called develop, where all the development for the latest version of the application occurs.
- New project features are implemented in separate branches called feature branches that always start from the develop branch. When work on a feature is finished and the code is properly tested, this branch is merged back to develop.
- When the code in develop is stabilized (without known bugs) and there is a need for a new application release, a new release branch is created. This release branch usually requires additional tests (extensive QA tests, integration tests, and so on), so new bugs will definitely be found. If additional changes (such as bug fixes) are included in a release branch, they need to eventually be merged back to the develop branch.
- When code on a release branch is ready to be deployed/released, it is merged to the master branch, and the latest commit on the master is labeled with an appropriate version tag. No other branches but feature branches can be merged to the master. The only exceptions are hot fixes that need to be immediately deployed or released.
- Hot fixes that require urgent release are always implemented on separate branches that start from the master. When the fix is done, it is merged to both the develop and master branches. Merging of the hot fix branch is done as if it were an ordinary release branch, so it must be properly tagged and the application version identifier should be modified accordingly.
The visual example of GitFlow in action is presented in the following. For those that have never worked in such a way and also have never used a distributed version control system, this may be a bit overwhelming. Anyway, it is really worth trying in your organization if you don't have any formalized workflow. It has multiple benefits and also solves real problems. It is especially useful for teams of multiple programmers that are working on many separate features, and when continuous support for multiple releases needs to be provided.
This methodology is also handy if you want to implement continuous delivery using continuous deployment processes because it makes it clear which version of code represents a deliverable release of your application or service. It is also a great tool for open source projects because it provides great transparency to both the users and the active contributors:
So, if you think that this short summary of GitFlow makes a bit of sense and it did not scare you yet, then you should dig deeper into online resources on that topic. It is really hard to say who is the original author of the preceding workflow, but most online sources point to Vincent Driessen. Thus, the best starting material to learn about GitFlow is his online article titled A successful Git branching model (refer to http://nvie.com/posts/a-successful-git-branching-model/).
Like every other popular methodology, GitFlow gained a lot of criticism over the internet from programmers that do not like it. The most commented thing about Vincent Driessen's article is the rule (strictly technical) saying that every merge should create a new artificial commit representing that merge. Git has an option to do fast forward merges, and Vincent discourages that option. This is, of course, an unsolvable problem because the best way to perform merges is a completely subjective matter. Anyway, the real issue of GitFlow is that it is noticeably complicated. The full set of rules is really long, so it is easy to make some mistakes. It is very probable that you would like to choose something simpler.
One such simpler flow is used at GitHub and described by Scott Chacon on his blog (refer to http://scottchacon.com/2011/08/31/github-flow.html). It is referred to as GitHub Flow, and is very similar to GitFlow in the following two main aspects:
- Anything in the master branch is deployable
- The new features are implemented on separate branches
The main difference from GitFlow is simplicity. There is only one main development branch, master, and it is always stable (in contrast to the develop branch in GitFlow). There are also no release branches and such big emphasis on tagging the code. There is no such need in GitHub Flow because, as they say, when something is merged into the master, it is usually deployed to production immediately. A diagram presenting an example of GitHub Flow in action is shown in here.
GitHub Flow seems like a good and lightweight workflow for teams that want to set up a continuous deployment process for their project. Such a workflow is, of course, not viable for any project that has a strong notion of release (with strict version numbers), at least without any modifications. It is important to know that the main assumption of the always deployable master branch cannot be ensured without a proper automated testing and building procedure. This is what continuous integration systems take care of, and we will discuss that a bit later.
The following is a diagram presenting an example of GitHub Flow in action:
Note that both GitFlow and GitHub Flow are only branching strategies, so despite having Git in their names, these strategies are not limited to that single DVCS solution. It's true that the official article describing GitFlow mentions even specific git command parameter that should be used when performing a merge, but the general idea can be easily applied to almost any other distributed version control system.
In fact, due to the way it is suggested to handle merges, Mercurial seems like a better tool to use for this specific branching strategy! The same applies to GitHub Flow. This is the only branching strategy sprinkled with a bit of specific development culture, so it can be used in any version control system that allows you to easily create and merge branches of code.
As a last comment, remember that no methodology is carved in stone and no one forces you to use it. Methodologies are created to solve some existing problems and keep you from common mistakes or pitfalls. You can take all of their rules or modify some of them to your own needs. They are great tools for beginners that may easily get into common pitfalls.
If you are not familiar with any version control systems, you should then start with a lightweight methodology like GitHub Flow without any custom modifications. You should start thinking about more complex workflows only when you get enough experience with Git or any other tool of your choice. Anyway, as you gain more and more proficiency, you will eventually realize that there is no perfect workflow that suits every project. What works well in one organization doesn't necessarily work well in others.