This article mainly shares two points:

  1. Understand and use the Git-flow branch management strategy.
  2. Improve our CI/CD flow based on Git-flow.

Current problems

During the development process, different members of the team often develop different features simultaneously, which can cause the following problems:

  • They often submit tests and deploy online at different times, so how do you clarify the responsibilities of the branch?
  • Different functions may have interdependent code, assuming that they belong to different branches. If one party wants to submit tests, it must merge with the other party first, but the other party is not ready to submit tests. Without a good branch management strategy, it is easy to cause chaos in branch management.
  • Whether different branches should correspond to different environments, how they should correspond, how Jenkins should implement.

Introduce the git – flow

When encountering problems, I went to the Internet to look for solutions. I came across Ruan Da Capital’s Git Branch Management Strategy, which introduced the Git-Flow branch model, which can solve the current problems. The following will be shared based on theory and practice.

Here is the branch management model of Git-flow, which is divided into primary and temporary branches:

The main branch

  • master
  • develop

Master corresponds to the code in the production environment.

Develop is the development branch. When develop code reaches a plateau and is ready for release, merge it to Master and mark the merge with the version number.

Temporary branch

Different from major branches, temporary branches have a limited life cycle and need to be deleted when they are used up. Temporary branches can be divided into:

  • feature
  • release
  • hotfix

Each of these branches serves a specific purpose and is governed by strict rules about which branches may be its original and which must be its merge target.

Feature – Feature branch

Check out from Develop and must be merged back into Develop.

When developing a feature, check out the feature branch from Develop. The feature branch remains in develop until it is merged into Develop and then deleted.

Create order function branch:

git checkout -b feature-order develop
Copy the code

After completing the order function, switch to Develop and merge feature-order:

#Switch to the develop
git checkout develop
#merge
git merge --no-ff feature-order
#Delete feature - the order
git branch -d feature-order
#Push develop
git push origin develop
Copy the code

The –no-ff flag causes the merge to always create a new commit object, even if the merge can be performed by caching. This avoids losing information about the history of the element branch and groups all commits with added elements together. The difference between using –no-ff and not using it is shown below:

Release The pre-publish branch

Check out from Develop and must be merged to Develop and Master.

Pre-release branches are typically used when code is released to the test environment and then merged into Develop and Master after testing is complete.

Hotfix branches may be used during testing to fix bugs encountered during testing, merge the fixes to release and remove hotfixes.

Create the Release branch. Create a Release branch from develop. If the current version of the code on master is 1.1.0 and a larger version is about to be released, develop is ready to create a release branch with the version number:

#Create the release-2.0.0 branchGit checkout -b release-2.0.0 developCopy the code

The relex-2.0.0 branch will exist for some time until it is ready for release. Instead of developing new features on this branch, you should check out the new Featrue branch on the Develop branch, or the Featrue -* main feature branch.

When release-2.0.0 is ready to publish, merge release-2.0.0 to master and mark the commit, and also merge it to develop to synchronize changes made on release-2.0.0:

#Switch to the master
git checkout master
#Combine the release - 2.0.0Git merge - no - ff release - 2.0.0#Mark version numberGit tag - a 2.0.0#Switch to the develop
git checkout develop
#mergeGit merge - no - ff release - 2.0.0#Remove the release - 2.0.0Git branch - d release - 2.0.0Copy the code

Hotfix fixes bug branches

Check from master and release, must merge back to Master and release, or if there is no release, merge back to Develop.

If you find a major bug in your production environment that needs immediate resolution, you can create the Hotfix-2.0.1 branch and start fixing the problem:

#Check out the hotfix - 2.0.1Git checkout -b hotfix-2.0.1 masterCopy the code

Merge branches after repair:

#Merge the masterGit checkout master git merge --no-ff hotfix-2.0.1 git tag -a 2.0.1#Merger developGit checkout develop Git merge --no-ff hotfix-2.0.1#Delete the hotfix - 2.0.1Git branch - d hotfix - 2.0.1Copy the code

Use git – flow

The previous section described and demonstrated how to use Git-Flow, but the process is still a bit cumbersome. In fact, there is a library gitFlow that is a concrete practice of the Git-flow model.

Install Git-Flow and integrate it into the shell as documented in its Github README. – See Installing Git-flow & Integration with Your shell section

After the installation, run git flow init -d to initialize it.

Developing new features

To synchronize billing, order, etc., create a primary branch and then a secondary branch:

Git flow feature start feature-1.0 Git flow feature start feature-order Git flow feature start feature-billCopy the code

List/start/end feature branches:

Git flow feature Git flow feature start feature-1.0 Git flow feature Finish feature-1.0Copy the code

After completion of development:

Git flow feature Finish feature-1.0Copy the code

Other types of branches are similar.

Application of Git-flow in CI/CD

The following is the flow chart of my Git branch workflow and Jenkins multi-branch pipeline:

Create feature-order and feature-finance as follows:

git flow feature start feature-order
git flow feature start feature-finance

#Push to the corresponding feature branch
git flow feature publish feature-order
#Pull the corresponding feature branch
git flow feature pull feature-order
Copy the code

When the order is first developed, the following steps are required to deploy it to the test environment for testers:

#Finish developing the order feature, automatically merge it into Develop and remove feature-Order
git flow feature finish feature-order
#The order function in Develop is ready, checks out the pre-release branch, and when pushed triggers Jenkins' build task to deploy automatically to the test environmentGit flow release start release-1.0.2.0-orderCopy the code

In the process of testing, if you need to fix the problem, you can directly modify it on release-1.0.2.0-order. After modification, the lift will automatically trigger the build task. When the test is complete and there are no problems, it is time to deploy online. Perform the following steps:

#Merge to master, delete release-1.0.2.0-orderGit flow release Finish release-1.0.2.0-orderCopy the code

Check out the Hotfix branch on master when a bug needs to be urgently fixed when deployed online:

#Check out the hotfix - order
git flow hotfix start hotfix-order
#Incorporated into the master
git flow hotfix finish hotfix-order
Copy the code

If you need to add small changes to the online version, you need to use the Support branch:

#Check out the support - story
git flow support start support-story
#Incorporated into the master
git flow support finish support-story
Copy the code

So far, the possible process involved in the online development of the order function has been introduced. The financial function is the same as above. As for the Jenkins configuration, it will not be expanded here. In Jenkinsfile, the replease-* branch is deployed to the pipeline of the test environment, and the master is deployed to the pipeline of the online environment. Of course, it needs to support parameterized configuration and deployment, and can choose to deploy to the test or online. If it is not clear how to build Jenkins and configure the multi-branch pipeline, Please refer to my previous article “Building a multi-branch pipeline for CI/CD with Jenkins”.

conclusion

The branch management strategy of Git-flow has solved my current problem about the chaos of branch management, greatly improved the efficiency of team collaboration, and optimized the CI/CD process accordingly, hoping to inspire everyone.

reference

  • Git branch management policy
  • A successful Git branching model
  • gitflow
  • Manage Development and Delivery Workflow with JGit-Flow and Jenkins-Pipeline