Shulou(Shulou.com)06/02 Report--

Git branch strategy and the release of the management of the case analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Show the development model I successfully used in my project a year ago. I always intended to write these things out, but I never found the time, and now I've finally finished it. What is presented here is not the details of any project, but the strategy of the branch and the management of the release.

In my demo, everything is done through git.

Why choose git?

In order to compare and argue between git and the central source control system, please take a look at link 1, link 2 here. As a developer, I like git more than any other existing tool. Git has really changed the way developers think about mergers and branches. In traditional CVS/SVN, merging / branching is always a bit scary ("pay attention to merge conflicts, they will kill you").

But these operations in git are so simple and effective that they are really part of your daily workflow. For example, in CVS/SVN books, branching and merging are always the focus of the last chapter (for advanced users), while in every git book, link 1, link 2, link 3, which is already included in Chapter 3 (fundamentals).

Branching and merging are no longer scary because of its simplicity, directness and repeatability. Version control tools support branching / merging more than anything else.

This is the end of the introduction of the tools, and we are now moving on to the topic of the development model. The model I want to show is essentially a collection of processes, and it is necessary for every team member to follow these processes in order to manage the software development process.

Scattered but also concentrated

The way we set up a good code base in our branching model revolves around a real central code base. Note that the code base here is only seen as a central code base (because git is a DVCS, that is, a distributed version control system, there is no such thing as a central code base from a technical point of view). We are used to naming this central code base origin, which is also the habit of all git users.

Every developer reports to origin, the central node of pull and push. But in addition, each developer can also change to other node pull to form a sub-team. For example, for more than two developers working on a large new feature at the same time, this is useful in order not to push development progress to origin prematurely. In the above example, Alice and Bob, Alice and David, Clair and David are all such subteams.

From a technical point of view, this simply means that Alice defines a git remote called Bob, which points to a code base for Bob, and vice versa.

Main branch

The core of the development model is basically the same as the existing model. The central code base always maintains two main branches:

Master

Develop

The master branch on origin is consistent with that of each git user. The other branch that runs in parallel with the master branch is called develop.

We think of origin/master as the main branch of its HEAD source code that always represents the state of readiness of the production environment.

We think of origin/develop as the main branch of its HEAD source code that always represents the last delivery in time for the next release. Some people also call it an "integration branch". The source code is also used as a source for nightly build automation tasks.

Whenever the develop branch reaches a stable stage and can be released to the public, all changes are merged into the master branch and hit a release version of tag. We will discuss the specific method of operation later.

So every time the changes are incorporated into master, this is a really new release product. We recommend strict control over this, so theoretically we can hang a hook script for each submission of the master branch to automate the construction and release of our software to the production environment.

Supporting branch

In our development model, the main branches of master and develop are followed by a variety of supporting branches. Their purpose is to help team members deal with development tasks such as tracking features, preparing for release, and quickly fixing online problems in parallel. Unlike previous main branches, these branches have a limited life cycle and will eventually be deleted.

The different types of branches that we may use are:

Feature branch

Release branch

Hotfix branch

Each branch has a special purpose and has strict rules, such as which branches are their initial branches and which branches must be the goal of their merger. Let's go through them quickly.

These "special" branches are technically nothing special. The type of branches depends on how we use them. They are all ordinary and ordinary branches of git.

Feature branch

May be sent from: develop

Must be merged back to: develop

Branch naming convention: any name except master, develop, release-* or hotfix-*

The Feature branch (sometimes referred to as the topic branch) is used to develop new features, including upcoming or future releases. When we start to develop a feature, the goal of releasing the merger may not be clear. The life cycle of the Feature branch will be synchronized with the development cycle of the new feature, but will eventually merge back to develop (well, bring the new feature with the next release) or be abandoned (what a sad attempt).

The Feature branch usually exists only in the developer's code base, not in the origin.

Create a feature branch

When starting a new feature, send a branch from the develop branch

$git checkout-b myfeature developSwitched to a new branch "myfeature" merges the completed features back to develop

Completed features can be merged back to develop

Branch and catch up with the next release:

$git checkout developSwitched to a new branch "develop" $git merge-no-ff myfeatureUpdating ea1b82a..05e9557 (Summary of changes) $git branch-d myfeatureDeleted branch myfeature (was 05e9557) $git push origin develop

The-no-ff flag causes the merge operation to always produce a new commit, even if the merge operation can be completed quickly. This tag avoids mixing the history of all submissions from the feature branch and team collaboration with other submissions from the main branch. Compare:

In the example on the right, it's impossible to tell which commits have implemented this feature from git's history-you may have to look at each commit log. Restoring a complete feature (such as through a set of submissions) becomes a headache on the right, but it becomes easier if you use-- no-ff.

Yes, this will create some unnecessary (empty) submission records, but get a lot of benefits.

Unfortunately, I haven't found a way to type the-no-ff tag by default on git merge, but this is important.

Release branch

May be sent from: develop

Must merge back to: develop and master

Branch naming convention: release-*

The Release branch is used to support preparations for the release of the new production environment. Allows dotting points and crossing points to be generated in the final stage. It also allows minor problem fixes and meta data (such as version number, release date, etc.) when preparing for release. After the release branch has done all this work, the develop branch will be "flipped" and begin to receive the next release of new features.

We chose (nearly) to complete all the expected development as the time to issue the release branch from the develop dispatch. At the very least, all the features that are ready to build the release have been merged into the develop branch in time. Features that will be released later should not be merged into the develop branch-they must wait until the release branch is dispatched before merging.

At the beginning of a release branch, we give it a clear version number. Until the branch was created, the description on the develop branch was a "next" release change, but this "next" release didn't really say whether it was 0.3 release or 1.0 release. This is determined at the beginning of a release branch. This will become a code for the promotion of the project version number.

Create a release branch

The Release branch is sent from the develop branch. For example, our current production environment releases version 1.1.5, and a release is about to be released. The develop branch is ready for the "next time" release, and we have decided to set the new version number as 1.2 (instead of 1.1.6 or 2.0). So we dispatched a release branch and named it after the new version number:

$git checkout-b release-1.2 developSwitched to a new branch "release-1.2" $. / bump-version.sh 1.2Files modified successfully, version bumped to 1.2.$ git commit-a-m "Bumped version number to 1.2" [release-1.2 74d9424] Bumped version number to 1.21 files changed, 1 insertions (+), 1 deletions (-)

After creating and switching to the new branch, we completed the promotion of the version number. The bump-version.sh here is a fictional shell script that changes some files in the code base to reflect the new version. (of course, you can also make these changes manually-the point is that some files have changed.) then the promoted version number will be submitted.

This new branch will exist for some time until it is actually released. There may be bug fixes during that time (this is more reasonable than doing it in develop). However, we strictly prohibit the development of huge new features here, and they should be merged into the develop branch and put into the next release.

Complete a release branch

When the release branch is really released, there are some things that need to be put to the finish line. First, the release branch is merged into master (don't forget that each commit on master represents a real new release); then, type a tag for this commit on master as an important reference for version history; and finally, merge the changes made by the release branch back to develop so that subsequent releases also include fixes to these bug.

The first two parts work like this under git:

$git checkout masterSwitched to branch 'master'$ git merge-- no-ff release-1.2Merge made by recursive (Summary of changes) $git tag-a 1.2

Now the release work has been completed, and the tag has been typed, which can be used as a reference in the future.

Add: you can also type tag with the-s or-u flag.

In order to keep a record of the changes in the release branch, we need to merge these changes back to develop. The git operation is as follows:

$git checkout developSwitched to branch 'develop'$ git merge-- no-ff release-1.2Merge made by recursive. (Summary of changes)

This step may lead to conflict (only theoretically possible, because we have changed the version number), once found, resolve the conflict and submit it.

Now that we've actually completed a release branch, it's time to delete it, because its mission is complete:

$git branch-d release-1.2Deleted branch release-1.2 (was ff452fe) .hotfix branch

May be sent from: master

Must merge back to: develop and master

Branch naming convention: hotfix-*

The Hotfix branch is very similar to the release branch because they both mean the release of a new production environment, although the hotfix branch is not previously planned. They are dispatched from the master branch to the corresponding tag when there is an unexpected need for a quick response to the real-time production version.

The root cause of this is to allow one of the team to quickly fix the problems in the production environment, and the other members can continue to work according to the work plan without much impact.

Create a hotfix branch

The Hotfix branch is created from the master branch. For example, suppose version 1.2 is the current production environment and there is a serious bug, but the current develop is not stable enough. Then we can send out a hotfix branch to start our repair work:

$git checkout-b hotfix-1.2.1 masterSwitched to a new branch "hotfix-1.2.1" $. / bump-version.sh 1.2.1Files modified successfully, version bumped to 1.2.1.$ git commit-a-m "Bumped version number to 1.2.1" [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.11 files changed, 1 insertions (+), 1 deletions (-)

Don't forget to promote the version number after sending out the branch!

Then, fix the bug and commit the changes. It can be done through one or more submissions.

$git commit-m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem5 files changed, 32 insertions (+), 17 deletions (-) complete a hotfix branch

When we are done, the fix to bug needs to be merged back to master and also to develop to ensure that the bug has been resolved in subsequent releases. This is done in exactly the same way as the release branch.

First, update master and type a tag for this release:

$git checkout masterSwitched to branch 'master'$ git merge-- no-ff hotfix-1.2.1Merge made by recursive (Summary of changes) $git tag-a 1.2.1

Add: you can also type tag with the-s or-u flag.

Then, merge the repaired bug into develop:

$git checkout developSwitched to branch 'develop'$ git merge-- no-ff hotfix-1.2.1Merge made by recursive (Summary of changes)

An addition to this rule is that if a release branch already exists, then the hotfix changes need to be merged into the release branch, not the develop branch. Because after merging the fixes for bug back to the release branch, the release branch will eventually merge back to the develop branch. (if you need to fix the bug immediately in the develop branch and can't wait for the release branch to merge back, you can still merge back to the develop branch directly, which is absolutely no problem.)

Finally, delete this temporary branch:

$git branch-d hotfix-1.2.1Deleted branch hotfix-1.2.1 (was abbe5d6).

Abstract

In fact, there is nothing new in this branch model. The big picture at the beginning of the article is very useful for our project. It is very easy for team members to understand this elegant and effective model and reach a consensus within the team.

Here is also a high-definition PDF version of the big picture, which you can use as a manual for quick browsing.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.