A live document updated over time to collect various Git related links that I find useful.
My Own Documents
Third Party Documents
In current projects, we tend to float between two branching models depending on the requirements of the customer / project and the planned deployment process.
This was previously known asÂ A successful Git branching modelÂ with an extremely detailed overview andÂ instructionsÂ here. It has since spawned a project to help make using this model easier – git-flow.
This is a great branching model for a team of people who work towards creating planned versioned deployments (whetherÂ it be time based such asÂ every second Tuesday, or milestone based).
In essence, this model uses two main branches:
origin/master – the main branch where the source code ofÂ
HEADÂ always reflects aproduction-readyÂ state.
origin/develop -Â where the source code ofÂ
HEADÂ always reflects a state with the latest delivered development changes for the next release. Some would call this the â€œintegration branchâ€. This is where any automatic nightly builds are built from.
Then developers createÂ supporting branches as part of their development process:
- feature branches – branched off
origin/develop for active development of a new feature / enhancement;
- hotfix branches – a branch off
origin/master to apply a critical fix to production code;
- release branches – short lived branches off
origin/develop which are used for final testing and patched before being merged to
The model works very well in practice and the above linked document is a excellent read on Git branchingÂ practicesÂ in general as well as git-flow in particular.
This is the model used at Github and discussed by Github developer Scott Chacon here.
This is suited for projects thatÂ deployÂ continuouslyÂ rather than around the concept of releases and so it’s less constrained than git-flow. These are two very different models and Scott puts forth his arguments in favour of the Github model in his post linked above.
In essence, Github flow works as follows:
origin/master is always deployable. Always.
- Similarly to git-flow, new features are done in their own branch – but off of
origin/master in this case.
- Now, when you believe your new feature is complete, a merge request is opened so someone else can review and check your work. This is the QA process.
- Once someone else signs off, you merge back into
- This is now deployable and can and will be deployed at anytime.