A successful Git branching
model
For a smooth and non conflicting development experience
The Problem
- Multiple member working on different parts unnecessarily delaying each
other.
- Cant release urgent changes because there are uncomplete features in the
code .
- Inability to isolate features for testing.
- Inability to revert a specific feature without reverting other features or code
changes.
- A lot of time wasted on merge conflicts.
The Goal
- Focus on a specific target while developing.
- Be able to apply urgent changes
- Isolate features for testing.
- Flexibility and ability to revert features or code parts without affecting other
parts.
- Ability to work on features for distant releases.
- Reduce merge conflict time.
The model
Main Branches
- Master Branch
- Develop Branch
Support Branches
- Feature branches
- Release branches
- Hotfix branches
Main Branches
- These Branches will always be there and live as
long as the project lives
- Master should always reflect a production-ready
state.
- Develop reflects a state with the latest delivered
development changes for the next release
Support Branches - Feature
Feature branch is used to develop a new feature for the next or a distant
release.
May branch off from : develop
Must merge back into : develop
Branch naming convention:
anything except :
master,develop, release-*, or hotfix-*
Support Branches - Feature
Create a feature branch from the develop branch
Implement the feature .
When done , merge back into develop branch
$ git checkout -b myfeature develop
// do the coding
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
Support Branches - Release
- Should be created once ready or almost done for a new release.
- no new features should be added here
- Clears space for other team members to work on new features from the
development branch.
- Changes on this branch should be done to solve bugs found before release
- Metadata , version number ,build data , etc...
May branch off from : develop
Must merge back into : develop and master
Branch naming convention : release-*
Support Branches - Release
- Create a release branch from the develop
branch.
- Update release metadata.
- Solve any found bugs.
- When done , merge into develop branch and
release branch
- Give a tag on the master branch
- Delete the branch
$ git checkout -b release-1.2 develop
// do the coding
$ git commit -a -m "updated version
number”
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
$ git checkout develop
$ git merge --no-ff release-1.2
$ git branch -d release-1.2
Support Branches - Hotfix
- Hotfix branches are created when it’s
needed to apply urgent changes or
hotfixes for bugs detected on the
production that can’t wait for the next
release.
- Its behaviour is very similar to a release
branch because it eventually creates a
new release.
May branch off from : master
Must merge back into : develop and master
Branch naming convention : hotfix-*
Support Branches - Hotfix
- Create a hotfix branch from the develop branch.
- Update version.
- Solve any found bugs.
- When done , merge into develop branch and
release branch
- Give a tag on the master branch
- Delete the branch
$ git checkout -b hotfix-1.2.1 master
// apply hotfix and update version number and
metadata etc..
$ git commit -m "Fixed severe production
problem"
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
$ git branch -d hotfix-1.2.1
The Big Picture
Thank you

A successful Git branching model

  • 1.
    A successful Gitbranching model For a smooth and non conflicting development experience
  • 2.
    The Problem - Multiplemember working on different parts unnecessarily delaying each other. - Cant release urgent changes because there are uncomplete features in the code . - Inability to isolate features for testing. - Inability to revert a specific feature without reverting other features or code changes. - A lot of time wasted on merge conflicts.
  • 3.
    The Goal - Focuson a specific target while developing. - Be able to apply urgent changes - Isolate features for testing. - Flexibility and ability to revert features or code parts without affecting other parts. - Ability to work on features for distant releases. - Reduce merge conflict time.
  • 4.
    The model Main Branches -Master Branch - Develop Branch Support Branches - Feature branches - Release branches - Hotfix branches
  • 5.
    Main Branches - TheseBranches will always be there and live as long as the project lives - Master should always reflect a production-ready state. - Develop reflects a state with the latest delivered development changes for the next release
  • 6.
    Support Branches -Feature Feature branch is used to develop a new feature for the next or a distant release. May branch off from : develop Must merge back into : develop Branch naming convention: anything except : master,develop, release-*, or hotfix-*
  • 7.
    Support Branches -Feature Create a feature branch from the develop branch Implement the feature . When done , merge back into develop branch $ git checkout -b myfeature develop // do the coding $ git checkout develop $ git merge --no-ff myfeature $ git branch -d myfeature $ git push origin develop
  • 8.
    Support Branches -Release - Should be created once ready or almost done for a new release. - no new features should be added here - Clears space for other team members to work on new features from the development branch. - Changes on this branch should be done to solve bugs found before release - Metadata , version number ,build data , etc... May branch off from : develop Must merge back into : develop and master Branch naming convention : release-*
  • 9.
    Support Branches -Release - Create a release branch from the develop branch. - Update release metadata. - Solve any found bugs. - When done , merge into develop branch and release branch - Give a tag on the master branch - Delete the branch $ git checkout -b release-1.2 develop // do the coding $ git commit -a -m "updated version number” $ git checkout master $ git merge --no-ff release-1.2 $ git tag -a 1.2 $ git checkout develop $ git merge --no-ff release-1.2 $ git branch -d release-1.2
  • 10.
    Support Branches -Hotfix - Hotfix branches are created when it’s needed to apply urgent changes or hotfixes for bugs detected on the production that can’t wait for the next release. - Its behaviour is very similar to a release branch because it eventually creates a new release. May branch off from : master Must merge back into : develop and master Branch naming convention : hotfix-*
  • 11.
    Support Branches -Hotfix - Create a hotfix branch from the develop branch. - Update version. - Solve any found bugs. - When done , merge into develop branch and release branch - Give a tag on the master branch - Delete the branch $ git checkout -b hotfix-1.2.1 master // apply hotfix and update version number and metadata etc.. $ git commit -m "Fixed severe production problem" $ git checkout master $ git merge --no-ff hotfix-1.2.1 $ git tag -a 1.2.1 $ git checkout develop $ git merge --no-ff hotfix-1.2.1 $ git branch -d hotfix-1.2.1
  • 12.
  • 13.