Introduction of a successful Git branching model Release Branch

English Original:

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

Chinese version:

In this article, I present a development model. I've introduced this development model to all of my projects (both at work and in private) for more than a year, and it has proven to be very successful. I'm going to write about this for a long time, but I've never been able to do it, and now I've got time. I'm not going to talk about the specifics of any project, just about branching strategies and releasing management-related content.

It mainly embodies git's management of our source code version.

Why is git?

For a comprehensive discussion of the pros and cons of git versus other centralized code management tools, see here. Such arguments are always chattering. As a developer, I prefer git to other development tools today. Git really has changed the way developers think about merging and branching. I used to use the classic cvs/subversion, but every time the merging/branching and other behaviors were always scary ("Beware of the conflicts in the merger, it's killing me!") ”）。

But for git, these behaviors are simple and funny, and they are considered a central part of everyday work. For example, in many cvs/subversion books, branching and merging are always discussed in later chapters (for advanced users), but in each git book, the 3rd chapter is fully covered (as a basis).

The result of simple and repetitive features is that branching and merging are no longer something to fear. Branching/merging is considered more important than other features for version management tools.

About tools, no more, let's look directly at the development model. This model is not a model: in managing software development progress, each player must develop in a certain order in the face of each development process.

distributed rather than centralized

For this branching model, we set up a repository that works well, which is a fact on the repository. Note, however, that this repository is only considered a central repository (because Git is a distributed version management system, and technically, there is no central repository). We will refer to this repository as the original library, which is easy to understand for all git users.

Each developer is on the origin code and commits the code. But in addition to the centralized access code relationship, each developer can also get code version changes from other teammates in the sub-team. For example, for large version changes made with 2 or more developers, this mechanism becomes useful to prevent premature submission of work to the Origin library. On the way, like the following team: Alice and Bob,alice and David,clair and David.

Technically, this means that Alice has created a remote node for git, and for Bob, that node points to Bob's repository, and vice versa.

Main Branch

In the core, the development model is largely supported by other existing models. The Central Library has 2 branches that can be continued:

• Master Branch
• Develop Branch

Each git user is familiar with the original master branch. Another branch that is parallel to the master branch, which we call the develop branch.

We think of the original library/master library as the main branch, the head source code exists in this version, and at any time is a pre - production state.

Auxiliary Branch

Our development model uses a variety of ancillary branches, along with key branches (master and develop) to support team members in parallel development, making it easy to track functionality, assisting with production release environment readiness, and quickly repairing real-time online issues. Unlike key branches, these branches always have a limited lifetime because they are eventually removed.

The types of branches we use include:

• Function Branch
• Publishing Branch
• Hot Repair Branch

Each branch has a specific purpose and is subject to strict rules, such as which branches can be used as the source branch and which branches can be used as the target of the merge. We'll do a walkthrough right away.

From a technical point of view, these branches are not special branches. The types of branches are categorized based on the method we use. They are, of course, common git branches.

Function Branch

It is possible that the branch version of the develop branch will eventually have to be merged into the develop branch.

Branching naming conventions: Except for master, develop, release-*, orhotfix-*, other names are available.

Feature branches (sometimes referred to as topic branches) typically develop new features for upcoming releases or future releases. When a new feature is developed, a release version containing the feature cannot be determined at this time. The essence of the feature version is that it will exist as long as the feature is in development, but will eventually be merged into the develop branch (to determine whether to add new functionality to the soon-to-be-released release) or cancel (for example, a disappointing test).

Feature branches typically exist in the developer's software library, rather than in the source code base.

Create a feature Branch

When you start a feature development work, you create a branch based on develop.

$ git checkout-b myfeature developswitched to a new branch "Myfeature"

Merge a feature to develop branch

The completed functionality can be merged into the develop branch to explicitly add to future releases:

$ git checkout developswitched to 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 create a new commit object, even if the merge operation can be fast-forward. This avoids the loss of historical information about the presence of this feature branch, combining all submissions for that feature. Comparison:

In the latter case, it is not possible to see in GIT history which submissions implemented a function together-you must read all the log information manually. If the entire feature is rolled back (such as a set of commits), the latter approach is a real headache, and using No-ffflag is easy.

Yes, it creates a new (empty) Commit object, but the payoff is much larger than the overhead.

Unfortunately, I haven't found a way to make NO-FF the default option for a merge operation, but it should be possible.

Release Branch

The release branch may be detached from the develop branch, but must be merged on the develop and master branches, and it is customary to be named: release-*.

The release branch is prepared for the release of the new product. It allows us to make some minor changes at the last minute. They allow small bugs to be modified and ready to publish metadata (version number, development time, etc.). When all this work is done on the release branch, the develop branch receives features more clearly for the next hit release.

The key moment to create a new release branch from the develop branch is that the develop branch achieves the desired state of the release. At least all the features to be released must be merged into the develop branch at this point in time. For all future ready release features must wait until the release branch is created and then merged.

It is not too early to assign a version number to the upcoming release when the release branch is created. Until then, the develop branch reflected changes for the next release, but it was unclear whether the next release was called 0.3 or 1.0 before the release branch was created. This decision was made when the release branch was created based on the rules of the project on the version number.

Create a release branch

The release branch is created from the develop branch. For example, the current product's release number is 1.1.5, colleague we have a big version coming soon. The develop branch is ready for the next release and we have to decide that the next version is 1.2 (not 1.1.6 or 2.0). So we separate the release branch into a branch name that reflects the new version number.

$ git checkout-b release-1.2 developswitched to a new branch "release-1.2" $./bump-version.sh 1.2Files Modified SUCCESSFU  Lly, 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 you create a new branch, switch to the branch and add the version number. Here, Bump-version.sh is a fictional shell script that can copy some files to reflect the new version (which of course can be changed manually to modify some files). The version number is then submitted.

This new branch may exist for a period of time until the release reaches its intended destination. During this time, the fix for the bug may be committed to the branch (instead of being committed on the develop branch). The addition of large new features is strictly forbidden here. They must be merged into the develop branch and wait for the next big release.

complete a Release Branch

When a release branch is ready to become a real release, some work must be done. First, the release branch is merged to master (since each commit to master is a newly defined release, remember). Then, the submission to master must be labeled to make it easier to refer to this historical version later. Finally, the changes on the release branch must be merged onto the develop branch so that future releases will also contain these bugs fixes.

The first two steps in Git are:

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

The release is now complete and tagged for future references.

EDIT: You may also want to use the-sor-u flags to tag your tags.

In order to be modified to remain on the release branch, we need to merge these into the develop branch, on git:

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

This step may result in a merge conflict (possibly due to a change in the version number). If so, fix it and then commit.

Now that we're really done, this release branch will be deleted because we don't need it anymore.

$ git branch-d release-1.2deleted branch release-1.2 (was Ff452fe).

Hot Repair Branch

Can be based on the master branch and must be merged back into the develop and master branches.
Branch Name conventions: hotfix-*

The hot fix branch is very similar to the publishing branch, and they are prepared for the new build environment release, although it is unplanned. They come from the production environment under abnormal state pressure. When the build environment validation flaw must be fixed right away, the hot fix branch can be created based on the corresponding and online version tag on the Master branch.

Its essence is that the work of a team member (on the Develop branch) can continue while another person prepares for a quick fix of the production environment.

Create Patch Bug Branch

Hotfix Branch (Patch Bug Branch) is separated from the master branch. For example, version 1.2 is a version of the current production environment and has a bug. However, the development Branch (develop) changes are not stable. We need to split up a patch bug Branch (hotfix branch) to resolve this situation.

$ git checkout-b hotfix-1.2.1 masterswitched to a new branch "hotfix-1.2.1" $./bump-version.sh 1.2.1Files Modified Succes Sfully, version bumped to 1.2.1.$ git commit-a-M "bumped version number to 1.2.1" [hotfix-1.2.1 41E61BB] bumped version n Umber to 1.2.11 files changed, 1 insertions (+), 1 deletions (-)

Do not forget to update the version number when the branch is closed (bump the edition)

Then, fix the bug, commit it one time or separate it multiple times.

$ git commit-m "fixed severe production problem" [hotfix-1.2.1 abbe5d6] fixed severe production PROBLEM5 files changed, 32 Insertions (+), deletions (-)

Complete a hotfix Branch

After completing a bugfix, you need to merge the Butfix into the master and develop branches so that the fixed bug is included in the next release. This is similar to completing the release branch.

First, update the master and tag the 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

Edit: You may also want to use the-sor-u parameter to encrypt your tag

Next, add the bugfix to the develop branch:

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

One exception to the rule is that if a release branch already exists, then the hotfix should be merged into the release branch instead of being merged into the develop branch. when the release branch is complete, merging the bugfix branches back into the release branch also causes the bugfix to be merged into the develop branch. (If the work in the develop branch is badly needed for this bugfix, you can also merge bugfix into the develop branch if the release branch is not completed)

Finally, delete the temporary branch:

$ git branch-d hotfix-1.2.1deleted branch hotfix-1.2.1 (was Abbe5d6).

Summary

Although this branching model does not have any shocking new things, the chart at the beginning of the article shows an astonishing practicality in our project. It forms an elegant thinking model that is easy to understand and enables team members to develop a common understanding of branching and publishing processes.

A high quality PDF chart is available here. Go ahead and hang it on the wall so you can get a quick reference at any time.

Introduction of a successful Git branching model Release Branch