"Go" a successful git branching model.

---restore content starts---

• Limited ability, the translation of this article is not authentic, if it is difficult to understand, but also please check the original text. --dbzhang800 20110921

In this article, I introduce a development model (development model) that I introduced to my project (including work and private projects) about a year ago and which has been proven to be very successful. I've been trying to write something about it for a while, but I've never had enough time to do it before. I won't talk about any details of the project, only the branching strategy (branching strategy) and release Management (Release Management).

It focuses on git, all of our source version management tools.

Why is Git?

To find a complete and thorough discussion of the advantages and disadvantages of git (compared to a centralized source control system), refer to this page. The gunpowder there is very strong. As a developer, I like git better than all the other tools I have available. Git really changes the way developers merge and branch and understand. In the classic CVS/SVN world, merging/branching has always been considered a bit scary ("Beware of merge conflicts, it will bite you!"), and things that are seldom used (it may be used once every once in a while).

But for git, these operations are very inexpensive and simple, and they are considered daily work?? One of the core operations in the process, which is really the case. For example, in CVS/SVN's books, branching and merging are discussed in later chapters (for advanced users), and in each git book it is introduced in chapter 3rd (the basic section).

The result of simple and high-frequency use is that branching and merging are no longer a scary thing to do. Version control tools are more desirable than other tools to support branch/merge operations.

There are enough introductions to the tools, let's go into the development model. The pattern I'm going to show here is essentially just a set of processes that every team member has to follow to make the software development process manageable.

To center but concentrate (decentralized but centralized)

The configuration of the repositories we use that are well-matched with this branch model requires a central "real" repository. Note that it is only considered as a central repository (because Git is a dvcs, there is no such thing as a central repository at the technical level). We use origin to refer to this repository because all git users are familiar with the name.

Each developer pulls (pull) and pushes (push) to Origin. But in addition to this centralized push-pull relationship, each developer may pull a replacement code from another developer to form a sub-team. This can be useful, for example, when working with two or more developers on a large new feature, before pushing the work code to a durable origin. In, Alice and Bob,alice and David, as well as Clair and David, formed sub-teams respectively.

Technically, this simply means that Alice defines a remote of git named Bob, which points to Bob's software repository. Vice versa.

Main Branch (main branches)

In essence, the development model is inspired by the existing model. The central repository maintains two immortal main branches:

• Master
• Develop

Every git user should be familiar with the master branch in origin. Parallel to master, there is another branch called develop.

We consider origin/master as such a main branch, whose source head always represents the state of the product readiness.

We consider origin/develop as such a main branch, whose source head always represents the state of the latest development changes that will be used for the next release. Some people like to call it "Integration Branch (Integration Branch)". This is also the source source of the automatic nightly build.

When the source code in the develop branch reaches a stable point and is ready to be released, all changes should be merged back into the master branch and then tagged with the version number. As to how this is achieved, the next step is to discuss it further.

Therefore, as defined by (our), whenever a change is merged back to master, it will result in a new product release. We tend to adopt very strict strategies, so in theory we can use a git script hook that automatically builds and transfers the software to the product server when there is a commit on master.

Auxiliary Branch (supporting branches)

In addition to master Branch Master and develop, our development model uses a variety of auxiliary branches to help parallel development among team members, mitigate the pain of feature tracking, prepare product launches, and quickly fix defects in released products. Unlike the main branch, the lifetimes of these branches are always limited, because they are eventually removed.

The different types of branches we may use:

• Feature Branch (Feature branches)
• Publishing Branch (release branches)
• Quick Repair Branch (Hotfix branches)

Each of these branches has a specific purpose and must adhere to strict rules: which branches they originate from, and which branches they must merge into. We will be introducing them again soon.

From a technical point of view, these branches have absolutely no "particularity". Branch types are divided according to how we use them. There is no doubt that they are still common git branches.

Feature Branch (Feature branches)

May originate from branch: Develop

Must be merged back to branch: Develop

Branching naming conventions: any name except master, develop, release-*, or hotfix-*

The feature branch (sometimes referred to as the topic Branch) is used to develop new features for an upcoming or forward version. When you start to develop a new feature, the target that contains the feature may not be well-defined at this time. The essence of the feature branch is that it always exists during the development of new features, but it eventually merges back into the develop branch (which will be added to the next released version) or obsolete (in the case of a frustrating experiment).

Typically, the feature branch exists only in the developer's repository, not in origin.

Create Feature Branch

When you start working on a new feature, create a new branch from the develop branch:

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

The completed feature is incorporated into the develop

The completed features will be merged back into the develop branch and will eventually be added to the upcoming release:

$ git checkout developswitched to branch ' develop '$ git merge--no-ff myfeature Updatingea1b82a. 05e9557(Summary of changes)$ git branch-d myfeatureDeleted Branch Myfeature (was 05e9557).  $ GIT push origin develop      

The tag --no-ff allows a merge operation to always generate a commit object even under conditions that can be fast-forward. This avoids the loss of historical information in the feature branch and allows all commits in the feature branch to remain in one piece. Comparison:

In the latter case, it is impossible to see from the history of Git which commit objects collectively implement a feature-you must read all the log information manually. Removing the entire feature (that is, a set of commits) is really a headache in the latter case, and if the --no-ff tag is used, it is easy to do so.

Of course, this creates some empty commit objects, but the payoff is much larger than this.

Unfortunately, I haven't found a way to enable --no-ff for the default behavior in git merge, but it's really needed.

Publishing Branch (release branches)

May originate from branch: Develop

Must be merged back to branch: Develop and master

Branch Naming conventions: release-*

The release branch is used to prepare the new product before it is released. It makes it possible to refine the details at the last minute. Further, it allows for minor bug fixes as well as preparation for publishing the required metadata (version number, build date, etc.). By doing this in the release branch, the develop branch can cleanly receive the functionality prepared for the next large release.

The key time to create a release branch from develop is when the develop branch (almost) can reflect the new version readiness State. At least all the feature branches of the distribution that will be constructed have been merged into the develop branch. All feature that are developed for future versions may not be incorporated-they must wait until the release branch is created.

It was at the beginning of the release branch that the upcoming product was assigned a version number-not previously. Until this moment, the develop branch began to reflect the "next version" of the change, but before the next release branch began, the next version will eventually become 0.3 or 1.0 is not clear. This decision is implemented by the project version number rule at the beginning of the release branch.

Create a publishing branch

The release branch is created from the develop branch. For example, suppose 1.1.5 is a version of the current product and we are about to have a large release. The develop branch is ready for "next Edition", and we've determined that this will be version 1.2 (not 1.1.6 or 2.0). Therefore, we create a release branch and give it a 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 Modifi Ed 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 Cha Nged, 1 insertions (+), 1 deletions (-)     

After creating a new branch and switching in, we modify the version number. The bump-version.sh here is a fictional script that is used to modify some of the files in the workspace to reflect the new version. (This can also be manually modified, of course). The modified version number is then submitted.

This new branch may persist until the release is finalized. During this time, the fixed bug is applied to the branch (not the develop branch). Adding big new features here is strictly forbidden. They must be merged into the develop and wait for the next big release.

Complete the publishing branch

Some actions need to be implemented when the status of the release branch is already in line with the requirements of the official release. First, the release branch is merged into Master (recall, by definition, every commit on master leads to a new version). Second, the commit on master must be tagged to make it easier to refer to this historical version later. Finally, all changes in the release branch need to be merged back into the develop so that future versions will also contain these bug patches.

In Git, the first two steps:

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

Release is now complete and tagged for future reference.

Note: You may also want to use the-s or-u <key> tags for private signing.

To keep the changes we made in the release branch, we need to merge them develop. In Git:

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

This may cause a merge conflict (most likely, because we have changed the version number). If so, fix and submit.

Now, we're really done, and the release branch will be removed because we don't need it anymore:

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

Quick Repair Branch (Hotfix branches)

May originate from branch: Master

Must be merged back to branch: Develop and master

Branch Naming conventions: hotfix-*

The hotfix branch is very much like the release branch, because it is also prepared for new products (albeit unplanned) releases. They originate from the need for an immediate response to an undesirable state in the currently released product. When an urgent bug in the product needs to be resolved immediately, a hotfix branch can be created from the tag that marks the product version in the Master branch.

The essence is that when a person prepares a quick fix for a product, the rest of the team's work on the develop branch can continue.

Create Hotfix Branch

The hotfix branch is created from the master branch. For example, suppose that 1.2 is a product that is currently released, but is causing a problem due to a serious bug. However, changes in the develop branch are not yet stable. We may choose to create a hotfix branch and start fixing the problem:

$ git checkout-b hotfix-1.2.1 masterswitched to a new branch "hotfix-1.2.1"$./bump-version.sh 1.2.1Files MoD Ified 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 file s changed, 1 insertions (+), 1 deletions (-)     

Don't forget to change the version number after you create the branch!

Then, fix the bug and commit the code as one or more commits.

$ git commit-m "fixed severe production problem"[hotfix-1.2.1 abbe5d6] Fixed Severe production problem5 files Cha Nged, insertions (+), deletions (-) 

End Hotfix Branch

When done, the fix to the bug needs to be merged into the master branch, and it needs to be merged back into the develop branch to ensure that the patch code is also included in the next release. This is exactly the same as the release branch at the end of the situation.

First, update master and label the publication.

$ 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    

Note: You may also want to use the-s or-u <key> tags for private signing.

Next, the fix code is also included in the develop:

$ 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 here is that when the release branch already exists, the hotfix changes need to be merged into this release branch, not develop. The patch code that merges into the release branch will eventually be merged into the develop when the release branch is complete. (You can also safely merge the patches into develop if the work in develop urgently needs this patch and can't wait for the release to be finalized.) )

Finally, remove this temporary branch:

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

Summary

Although there is nothing shocking about this branching model, the "big picture" given at the outset of this article has proved very useful in our project. It forms an elegant, easy-to-understand pattern and reinforces the team members ' understanding of the branching and sharing of the publishing process.

Transferred from: http://blog.csdn.net/passionboyxie/article/details/6820685

---restore content ends---

"Go" a successful git branching model.