pramodshinde/git-branching.md

## git-branching.md

      
    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

Raise PR of staging against master
Merge PR into staging only if


 CI build/Test cases are passing
 PR is approved


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.  
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

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


Fix the bug and test
Raise PR against master
Merge PR into master if


 PR is approved
 CI Build/Test cases are passing


Deploy it to master by following instruction in  Releasing/deploying new feature to master(production) section.
Merge hotfix/MYP-2-handle-email-uniqueness branch into staging

    git checkout staging
    git merge hotfix/MYP-2-handle-email-uniqueness


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

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


Fix the bug and test
Raise PR against staging
Merge PR into staging if


 PR is approved
 CI Build/Test cases are passing


Deploy it to staging
Merge hotfix/MYP-2-handle-email-uniqueness branch into develop

    git checkout develop
    git merge hotfix/MYP-2-handle-email-uniqueness