Skip to content

Instantly share code, notes, and snippets.

@pramodshinde

pramodshinde/git-branching.md

Last active December 11, 2019 12:53
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pramodshinde/a811f2505009c7d851bdd7be14908e60 to your computer and use it in GitHub Desktop.
Save pramodshinde/a811f2505009c7d851bdd7be14908e60 to your computer and use it in GitHub Desktop.
Download ZIP
Git branching strategy
Raw
git-branching.md

Git Branching Strategy

Josh enforces to adopt the following described git branching strategy to keep every project on the same page when it comes to git branching.

We strongly recommend to keep following major branches in project

  • master - origin/master to be the main branch where the source code of HEAD always reflects a production-ready state(production deployed code), Direct push is not allowed into this branch.

  • staging - origin/staging to be a parallel branch to master branch to stage your features for QA and user acceptance testing.(staging deployed code)

    Note: you can also call this branch as uat

  • develop - origin/develop to be a parallel branch of master branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release (A working copy of code for every developer)

Feature Development

  • Ideally feature branch should branch out from master branch - if your are working on new independent and want a production deployed code for your feature.
  • If you don't want a production deployed code and want a code which is on staging or develop  then you can branch it out from respective branch.

Naming feature branch

git checkout -b feature/MYP-1-user-sign-up where

  • feature is a branch namespace
  • MYP a three character project short code  e.g. if project name is myproject then code is MYP
  • number following project code is the feature story/task/issue number here its 1 hence MYP-1
  • project code and issue number is followed by a short feature description here its user-sign-up

Feature branch pull request review

Feature branch PR should raised against develop branch only if on your dev machine following checklist is valid  

  • develop branch is rebased into feature branch
  • Resolved all rubocop and breakman issues (ruby specific tools. You use equivalant tools for other techhnologies)
  • All test cases are passing
  • New feature is tested thoroughly

and PR is ready to merge if

  • Pull request is approved
  • CI build is passing

Feature branch merging

You can merge feature PR  via Github UI or merge using command line.

You can merge feature branch into

  •  develop branch if staging & develop are in sync means code copy is same on both branch(Recommended approach)      
  git checkout develop
  git merge feature/MYP-1-user-sign-up
  • staging branch if staging & develop are not in sync and you want to give the feature branch urgently for testing.
  git checkout staging
  git merge feature/MYP-1-user-sign-up

Note: if feature branch is merged into staging directly DO NOT FORGOT to merge it back into develop to keep code in sync.

Releasing/deploying new feature to staging

  • if feature is merged into develop then merge develop into staging
  • If feature branch is merged into staging

Then you can deploy staging branch to staging environment if

  • CI build / Test cases are passing

Releasing/deploying new feature to master(production)

If new feature is deployed and tested on staging successfully it's ready to deploy on production.

To deploy feature to production following steps must be followed

  1. Raise PR of staging against master
  2. Merge PR into staging only if
  • CI build/Test cases are passing
  • PR is approved
  1. Once PR is merged its strongly recommended to create a release tag off the master with release summary/notes detailing about new features being deployed.  
  2. Deploy the code to production environment  

Hotfix or Bug fixing

At any point after deployment you realise that there is a bug/issue on the deployed environment then to tackle this we recommend to create a hotfix branch off the targeted environment

Case 1: if bug is reported on production/master branch

  1. Create a hotfix branch like hotfix/MYP-2-handle-email-uniqueness from master branch
   git checkout master 
   git checkout -b hotfix/MYP-2-handle-email-uniqueness
  1. Fix the bug and test
  2. Raise PR against master
  3. Merge PR into master if
  • PR is approved
  • CI Build/Test cases are passing
  1. Deploy it to master by following instruction in  Releasing/deploying new feature to master(production) section.
  2. Merge hotfix/MYP-2-handle-email-uniqueness branch into staging
    git checkout staging
    git merge hotfix/MYP-2-handle-email-uniqueness
  1. Merge hotfix/MYP-2-handle-email-uniqueness branch into develop
    git checkout develop
    git merge hotfix/MYP-2-handle-email-uniqueness

Case 2: if bug is reported on staging branch

  1. Create a hotfix branch like hotfix/MYP-2-handle-email-uniqueness from staging branch
   git checkout staging 
   git checkout -b hotfix/MYP-2-handle-email-uniqueness
  1. Fix the bug and test
  2. Raise PR against staging
  3. Merge PR into staging if
  • PR is approved
  • CI Build/Test cases are passing
  1. Deploy it to staging
  2. Merge hotfix/MYP-2-handle-email-uniqueness branch into develop
    git checkout develop
    git merge hotfix/MYP-2-handle-email-uniqueness
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment