Branching Strategy and migration to git-flow

Overview

This section describes the branching strategy with git-flow. 

Branching strategy

http://nvie.com/posts/a-successful-git-branching-model/

Release process

1- When ready to cut a release, create release branch for version x.x.x. Release branch is branched out of develop, once decided stable enough to attempt a release. This point forward, any hardening is done on the release branch. New feature development can resume on 'develop' without affecting the release. 

> git flow release start 1.7.0
Switched to a new branch 'release/1.7.0'
Summary of actions:
- A new branch 'release/1.7.0' was created, based on 'develop'
- You are now on branch 'release/1.7.0'

2- Once the release hardening has started, time to publish to remote so any bug fixes can be done on local repositories:

> git flow release publish 1.7.0
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 294 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:continuuity/reactor.git
 * [new branch]      release/1.7.0 -> release/1.7.0
Already on 'release 1.7.0'

3- To make changes to the release, track the branch

>git flow release track 1.7.0

 

4- Commit any changes as usual

>git commit -m "adding stuff to 1.7.0"
>git push

5- When all hardening and regression test is completed, ready to declare a candidate, time to merge to develop and master. To facilitate future hotfixes on 1.7.0, the branch is kept using the -k option:

> git flow release finish -k 1.7.0
Summary of actions:
- Latest objects have been fetched from 'origin'
- Release branch has been merged into 'master'
- The release was tagged '1.7.0'
- Release branch has been back-merged into 'develop'
- Release branch 'release/1.7.0' is still available

Hotfix process

1- When 1.7.0 requires a hotfix after being released, using the '1.7.0' tag on master, create a hotfix branch '1.7.1':

 git flow hotfix start 1.7.1 1.7.0
Switched to a new branch 'hotfix/1.7.1'
Summary of actions:
- A new branch 'hotfix/1.7.1' was created, based on '1.7.0'
- You are now on branch 'hotfix/1.7.1'
Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:
     git flow hotfix finish '1.7.1'

Often hot fixes are made on a codebase that may not be compatible with current 'develop' changes. For this reason a hotfix can also be done on the release branch. In this case, the hotfix applies to all codebase, so is merged back to 'develop' and 'master'. 

> git flow hotfix publish 1.7.1
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 296 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@github.com:continuuity/reactor.git
 * [new branch]      hotfix/1.7.1 -> hotfix/1.7.1
Already on 'hotfix/2.1.0'
Summary of actions:
- A new remote branch 'hotfix/1.7.1' was created
- The local branch 'hotfix/1.7.1' was configured to track the remote branch
- You are now on branch 'hotfix/1.7.1'
> git flow hotfix finish -k 1.7.1
Switched to branch 'master'
Merge made by the 'recursive' strategy.
 hotfix-1.7.1.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 hotfix-1.7.1.txt
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 hotfix-1.7.1.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 hotfix-1.7.1.txt
Summary of actions:
- Latest objects have been fetched from 'origin'
- Hotfix branch has been merged into 'master'
- The hotfix was tagged '1.7.1'
- Hotfix branch has been back-merged into 'develop'
- Hotfix branch 'hotfix/1.7.1' is still available

 

 



Installing git flow 

https://github.com/nvie/gitflow

git clone https://github.com/nvie/gitflow.git
cd gitflow
git submodule init && git submodule update
sudo make install ( if make not found, install Xcode )

Initializing repository

Use option -d to use default branch names used by the git flow model (master, develop, release/, feature/, /hotfix):

 

WARNING!!!

Checking out master before initializing is crucial. If not done, git flow will define develop as the "production" branch and feature branch will branch out of master instead of develop.  This step is necessary because CDAP's default branch is set to develop instead of master.  

If you are not running the git flow command for the first time use "git flow init -f" instead of "git flow init -d".

>git clone git@github.com:continuuity/reactor.git
>git checkout master (make sure you're on the master branch before initializing.)
> git flow init -d
Using default branch names.
Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 
How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

Once initialized, local repository will default to 'develop' branch:

> git branch -a
* develop
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master

Developing a new feature

1- Create feature branch:

> git checkout develop   // (if not already there)
> git pull 
> git flow feature start my-feature
> git branch -a
  develop
* feature/my-feature   // you are now automatically on your 'my-feature' branch
  master
  remotes/origin/develop
  remotes/origin/feature/world-domination
  remotes/origin/master

2- Make changes and commit, same as usual. When you are ready to have your changes reviewed, execute 'git flow feature publish my-feature' from your local 'my-feature' branch:

> git flow feature publish my-feature
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 315 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
To git@github.com:continuuity/reactor.git
 * [new branch]      feature/my-feature -> feature/my-feature
Already on 'feature/my-feature'
Summary of actions:
- A new remote branch 'feature/my-feature' was created
- The local branch 'feature/my-feature' was configured to track the remote branch
- You are now on branch 'feature/my-feature'

3- Once the feature has been published, create a pull request in GitHub. This automatically sends a review request to the team via HipChat. Make any changes required, commit. 

 

4 - When your pull request is approved and your review is completed, do a 'git pull' from your 'my-feature' branch to bring it up to date. When the pull completes, immediately push to your local 'develop' branch via 'git flow feature finish'. In addition to updating your local 'develop' branch this also automatically deletes your 'my-feature' branch:

// from my-feature branch:
> git pull
> git flow feature finish my-feature
Switched to branch 'develop'
Updating e5f803a..0b61728
Fast-forward
 README.md | 2 ++
 1 file changed, 2 insertions(+)
Deleted branch feature/my-feature (was 0b61728).
Summary of actions:
- The feature branch 'feature/my-feature' was merged into 'develop'
- Feature branch 'feature/my-feature' has been removed
- You are now on branch 'develop'   // this is your local 'develop' branch

 

5- To finish, execute 'git push' from your local 'develop' branch. This pushes your local changes to the remote 'develop' branch:

// from local 'develop' branch:
> git push
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:continuuity/reactor.git
   ccb9ccb..e80d364  develop -> develop
   

 

 

 

 

Sharing feature branch 

If two developer need to work on the same feature branch, developer1, developer2:

developer1 creates the feature branch:

> git flow feature start our-shared-feature
Switched to a new branch 'feature/our-shared-feature'
Summary of actions:
- A new branch 'feature/our-shared-feature' was created, based on 'develop'
- You are now on branch 'feature/our-shared-feature'
Now, start committing on your feature. When done, use:
     git flow feature finish our-shared-feature

Developer1 makes some changes, commit as usual then publishes the feature branch:

>git commit -am "shared feature"
[feature/our-shared-feature 5156f25] shared feature
 1 file changed, 1 insertion(+)
 create mode 100644 OurSharedFile.java
 
> git flow feature publish our-shared-feature
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 311 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To git@github.com:continuuity/reactor.git
 * [new branch]      feature/our-shared-feature -> feature/our-shared-feature
Already on 'feature/our-shared-feature'
Summary of actions:
- A new remote branch 'feature/our-shared-feature' was created
- The local branch 'feature/our-shared-feature' was configured to track the remote branch
- You are now on branch 'feature/our-shared-feature'

Developer2 must now pull and "track" the branch:

> git pull
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 3 (delta 1), reused 3 (delta 1)
Unpacking objects: 100% (3/3), done.
From https://github.com/continuuity/reactor
 * [new branch]      feature/our-shared-feature -> origin/feature/our-shared-feature
Already up-to-date.

> git flow feature track our-shared-feature
Branch feature/our-shared-feature set up to track remote branch feature/our-shared-feature from origin.
Switched to a new branch 'feature/our-shared-feature'
Summary of actions:
- A new remote tracking branch 'feature/our-shared-feature' was created
- You are now on branch 'feature/our-shared-feature'

Developer2 is now on branch feature/our-shared-feature, can commit changes and git push

> git commit -am "modifying OurSharedFeature.java"
[feature/our-shared-feature 9da0a1e] modifying OurSharedFeature.java
 1 file changed, 3 insertions(+)

> git push
To https://github.com/continuuity/reactor.git
   5156f25..9da0a1e  feature/our-shared-feature -> feature/our-shared-feature

Developer1 can now pull the changes and vise versa:

> git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
Unpacking objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 3 (delta 1)
From github.com:continuuity/reactor
   5156f25..9da0a1e  feature/our-shared-feature -> origin/feature/our-shared-feature
Updating 5156f25..9da0a1e
Fast-forward
 OurSharedFile.java | 3 +++
 1 file changed, 3 insertions(+)

When feature is reviewed and redy to be merged to develop, either developer1 or developer2 can 'finish' the feature:

> git pull
> git merge develop   (<-- resolve any conflicts in the feature branch if needed)
> git flow feature finish our-shared-feature
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
 OurSharedFile.java |    4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 OurSharedFile.java
Deleted branch feature/our-shared-feature (was 9da0a1e).
Summary of actions:
- The feature branch 'feature/our-shared-feature' was merged into 'develop'
- Feature branch 'feature/our-shared-feature' has been removed
- You are now on branch 'develop'