A successful Git branching model

Branching workflow using topic and integration branch
We will be covering the branching workflow with a simple example.
Say for instance, you are currently working on a new feature on the current branch. Suddenly, somebody finds a bug in the production and you are now tasked to fix that bug, parallel to working on the new feature earlier.
On the way of work on a topic branch to add functions, it becomes necessary to fix bugs.
Before starting on the bug fix, you would want to create a new branch based off the integration branch. This new branch will isolate the bug fix from the new feature that you were working on.
You can start working independently from the addition of functions by creating a new topic branch for fixing bugs.
When you ready to release the bug fix, merge the bug fix topic branch into the integration branch.
You can make it public by including it in the original branch
Once that is done, you can proceed to switch back to your original feature branch and continue working on the new feature.
You can go back to the original branch to continue working on the addition of functions
On your feature branch, you will notice that commit "X", which is the bug fix commit, is needed in order for you to continue implementing the new feature. In other words, you will have to synchronize your current branch with the changes on the integration branch.
There are two options to go about doing this. The first is to merge the integration branch that includes commit "X" with the current branch.
The second option is to rebase the current branch to the integration branch that includes commit "X".
For this example, we will use the rebase approach which will produce a resulting history that is similar to the example below.
Rebase a unified branch
Now that we have commit "X" on our current branch, we can safely proceed to work on our new feature.
As you can see here, branching allows us to effectively work on multiple concurrent tasks.

Column 「A successful Git branching model」

We highly recommend that you check out the article "A successful Git branching model" at http://nvie.com/posts/a-successful-git-branching-model/. It covers one of the most popular approaches for managing Git branching workflow.
The article suggests that we maintain four types of branches, each with different roles.
  • Main branch
  • Feature branch (topic branch)
  • Release branch
  • Hot fix branch
Branch model at Git

Main branch

The main branch consists of the master and develop branches.
  • Master
    Codebase residing in the master branch is considered to be production-ready. When it is ready for a specific release, the latest commit will be given a release tag.
  • Develop
    Codebase residing in the develop branch is used in your team's day to day development. This is where all new features are merged to, waiting to be deployed in upcoming releases. This branch is very much like the integration branch that we have described earlier in this section.

Feature branch

The feature branch works like a topic branch which we have covered earlier.
When you plan to start working on a new feature/bug fix, you would want to create a feature branch. A feature branch would normally be created off a develop branch. This feature branch can reside in your local machine throughout the entire development lifecycle of the feature.
You should push this branch up to the remote repository whenever you are ready to merge the change set with the develop branch.

Release branch

When you plan to roll out a new release, you would want to create a release branch. A release branch helps you to prepare and ensure that the new features are running correctly.
By convention, release branch names normally start with the prefix "release-".
The release branch is typically created off the develop branch when it becomes close to being production-ready.
Only bug fix and release related issues should be addressed on this branch. Having this branch would allow other team members to continue pushing new features to the develop branch without interrupting the release workflow.
When you are ready to release, merge the release branch with the master branch and tag a release number to the newly created merge commit.
You would also want to merge the release branch into the develop branch, so that both the master and develop branches receive the latest change/bug fix from the release branch.

Hot fix branch

When you need to add an important fix to your production codebase quickly, you would want to create a Hot fix branch off the master branch.
By convention, hot fix branch names normally start with the prefix "hotfix-".
The advantage of a hot fix branch is that it allows you to quickly issue a patch and have the change merged with the master branch without having to wait for the next release.
A hot fix branch should be merged with the develop branch as well.

Comments

  1. composer identity import -p hlfv1 -u PeerAdmin -c composer-data/fabric-dev-servers/fabric-scripts/hlfv1/composer/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/signcerts/Admin@org1.example.com-cert.pem -k composer-data/fabric-dev-servers/fabric-scripts/hlfv1/composer/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/114aab0e76bf0c78308f89efc4b8c9423e31568da0c340ca187a9b17aa9a4457_sk

    ReplyDelete
  2. composer network deploy -a med.bna -p hlfv1 -i PeerAdmin -s randomString -A admin -S adminpw

    ReplyDelete
  3. composer identity issue -i admin -s adminpw -u ministryAdmin -x true -p hlfv1 -n med -a org.hyperledger.composer.system.NetworkAdmin#admin
    An identity was issued to the participant 'org.hyperledger.composer.system.NetworkAdmin#admin'
    The participant can now connect to the business network with the following details:
    userID = ministryAdmin
    userSecret = tDEdjccsUUxp

    ReplyDelete
  4. export COMPOSER_PROVIDERS='{ "github": { "provider": "github", "module": "passport-github", "clientID": "bc59b52e786c42d40f95", "clientSecret": "60bc312b3182d7587ce0c350d20f72836cbf5fb4", "authPath": "/auth/github", "callbackURL": "/auth/github/callback", "successRedirect": "/", "failureRedirect": "/error" }}'

    ReplyDelete
  5. composer-rest-server -p hlfv1 -n med -i admin -s adminpw -N never -a true -m true

    ReplyDelete

Post a Comment