Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

A successful Git branching model

400 views

Published on

  • Be the first to comment

A successful Git branching model

  1. 1. A successful Git branching model For a smooth and non conflicting development experience
  2. 2. 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.
  3. 3. 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.
  4. 4. The model Main Branches - Master Branch - Develop Branch Support Branches - Feature branches - Release branches - Hotfix branches
  5. 5. 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
  6. 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. 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. 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. 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. 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. 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. 12. The Big Picture
  13. 13. Thank you

×