Git branching strategies

Git Branching Strategy – I

Branches involved

• int branch: Where active development happens for the next bi-weekly release.
• prod branch: Reflects the code which is stable in production.
• feat-* branches: Where development of features to be released in distant future takes place.
• hotfix-* branches: Where critical bug in production needs a fix, which cannot wait till the next release.

Scenario – Next biweekly release development

int branch will be used for the next biweekly release development. Developer does commits to the int branch and before pushing it to remote does pull with rebase

[int]> git pull –rebase origin int

instead of simple pull

[int]> git pull origin int

Pull without rebase will download the Git objects and refs(fetch) from remote and merge origin/int into int branch.

Pull with rebase will download the Git objects and refs(fetch) and rebase int on origin/int. This will help preserve linear history.

Note: Make sure you have a clean working directory before you do a rebase. Either commit or stash your changes.

Also regularly merge changes from prod branch to get the hotfix commits.

> git checkout int
[int]> git merge prod

If no hotfixes have been done in the week, nothing will happen. Git will comment saying that you are already upto date.

Scenario – Distant future release feature development

**feat-*** branches will be used to work on feature that are supposed to be released in distant future(not in the next biweekly release).

Naming convention for the feature branch will be feat- followed by a short name you want to give to the feature you are working on.

To start working on a feature, create the feature branch from int branch.

[int]> git checkout -b feat-myfeature
[feat-myfeature]>

While you are making changes in the feature branch, commits will be done in the remote int branch for the upcomming biweekly release. To incorporate those changes in your branch, rebase feat-myfeature on origin/int.

[feat-myfeature]> git fetch origin int
[feat-myfeature]> git rebase origin/int

You can continue work on this feature branch locally, however it is advisable to push the branch on remote to secure your changes in the event of your system crash.

[feat-myfeature]> git push origin feat-myfeature

You’ll be working on this feature brach as long as you’ve not entered the biweekly release cycle of the feature.

To continue working on the feature branch, checkout the feature branch and keep rebasing on origin/int as discussed above. However, when you try to push this to remote again, you’ll have to force push since you have changed the history of the feature branch.

[feat-myfeature]> git push –force origin feat-myfeature

And as soon as you enter the release cycle of the feature,

• Get the latest changes from int branch

> git checkout int
[int]> git pull origin int

• Rebase feat-myfeature on int branch

> git checkout feat-myfeature
[feat-myfeature]> git rebase int

• Merge feat-myfeature into int branch and push to remote

>git checkout int
[int]> git merge feat-myfeature
[int]> git push origin int

• Continue working on the int branch now. Just remember to pull with rebase instead of simple pull

[int]> git pull –rebase origin int

Scenario – Hotfix

In this case we need to fix a bug live in production. For this, we will create hotfix branch from the prod branch. Naming convention for the hotfix branch will be hotfix-\<year\>-\<week\>-\<sno\>

>git checkout prod
[prod] git pull origin prod
[prod]> git checkout -b hotfix-2016-12-1
[hotfix-2016-12-1]>

Make the necessary changes in the hotfix branch and merge it into prod branch when done.

> git checkout prod
[prod]> git merge hotfix-2016-12-1
[prod]> git push origin prod

Production release

Every biweekly release to production will be done from int branch. After the code is stable in production, merge int into prod branch.

> git checkout prod
[prod]> git merge int

Note – This will always be a fast forward merge if the hotfix changes were merged properly into int branch previously.

Tagging

After the production release, tag the release commit. Naming convention for tag will be rel-\<year\>-\<week\>

> git checkout prod
[prod]> git tag -a 'rel-2016-12' -m 'This is the Solrx 12th week release'

Git Branching Strategy – II

Branches involved

• int-* branches: Where active development happens for a particular bi-weekly release.
• prod branch: Reflects the code which is stable in production.
• hotfix-* branches: Where critical bug in production needs a fix, which cannot wait till the next release.

Scenario – biweekly release development

Every biweekly release is associated with the week number in which it gets released. For e.g. week 12, week 14 and so on. The changes going in week 12 will be made on week12 int branch and similarly changes going in week 14 will be done in week14 int branch. Naming convention for int branch will be int-\<year\>-\<week\>.

Each int branch will get created from the previous available int branch. So int-2016-14 will get created from int-2016-12 if available, else from int-2016-10 branch.

>git fetch
>git branch

Find out the last int branch that was created. Create the new int branch from that branch.

> git checkout int-2016-12
[int-2016-12]> git checkout -b int-2016-14
[int-2016-14]>

Continue working on the int branch and get changes from remote by pulling with rebase

[int-2016-14]> git fetch origin int-2016-14
[int-2016-14]> git pull –rebase origin/int-2016-14

Regularly get the changes from the previous int branch and the prod branch(for hotfix commits) by merging them in the int branching you are working on.

>git checkout int-2016-12
[int-2016-12]> git fetch origin int-2016-12
[int-2016-12]> git checkout int-2016-14
[int-2016-14]> git merge int-2016-12

>git checkout prod
[prod] git fetch origin prod
[prod] git checkout int-2016-14
[int-2016-14] git merge prod

Scenario – Long running feature development

For feature that don’t have a fixed FCI date or its release is way in future, create a feature branch from the latest int branch. Naming convention for feature branches will be feat- followed by short name you want to associate with the feature.

>git checkout int-2016-14
[int-2016-14] git checkout -b feat-myfeature
[feat-myfeature]>

Regularly get the changes from the last int branch by merging it into feature branch.

[feat-myfeature]> git merge int-2016-14

When the release for the feature is near, merge feature branch into the respective int branch.

>git checkout int-2016-20
[int-2016-20]> git merge feat-myfeature

Scenario – Hotfix

In this case we need to fix a bug live in production. For this, we will create hotfix branch from the prod branch. Naming convention for the hotfix branch will be hotfix-\<year\>-\<week\>-\<sno\>

>git checkout prod
[prod] git pull origin prod
[prod]> git checkout -b hotfix-2016-12-1
[hotfix-2016-12-1]>

Make the necessary changes in the hotfix branch and merge it into prod branch when done.

> git checkout prod
[prod]> git merge hotfix-2016-12-1
[prod]> git push origin prod

Production release

Every biweekly release to production will be done from the respective int branch. After the code is stable in production, merge int into prod branch.

> git checkout prod
[prod]> git merge int-2016-12

Note – This will always be a fast forward merge if the hotfix changes were merged properly into int branch previously.

Tagging

After the production release, tag the release commit. Naming convention for tag will be rel-\<year\>-\<week\>

> git checkout prod
[prod]> git tag -a 'rel-2016-12' -m 'This is the Solrx 12th week release'