This is a community collaborative translation of the article, has been translated, more information please click
Introduction to collaborative translation 。

In this article, I’m going to generalize the development models used in some of the projects (both public and private) THAT I introduced a year or so ago that turned out to be very successful. I’ve been dying to write and share this for a while, but I just haven’t gotten around to it yet. I won’t go into any project details, just branch strategy and release management.


0
retranslation

rayle

Why use Git?

see
web

0
retranslation

rayle
daily
manual
each
Git
manual

With simple and repeatable genes, branching and merging are less of a concern. Version control tools should focus on branching/merging and nothing else.

Now that we know enough about the tools, let’s move on to the development model. The development model I’m going to introduce is nothing more than a specification that every team member must follow before entering the software development process.


0
retranslation

Summer

Decentralization and centralization

origin

origin
origin

Technically, Alice will add a remote Git branch to the local library and name it Bob, pointing to Bob’s repository. So did everyone else.


0
retranslation

wilson_yang

The main branch

Git’s core is heavily inspired by existing patterns in development, with the central repository maintaining two main branches throughout its life cycle:

  • master
  • develop

origin
master
master
develop

We call origin/ Master the primary branch, where the HEAD of the source code always points to the state available for production.

We call origin/ Develop the main branch, and the HEAD of the source code in this branch always reflects the latest development status of the next release. Some people call this branch the “integration branch.” All daily automated builds are built from here.


0
retranslation

Summer
develop
master
master
According to the definition
master

0
retranslation

wilson_yang

Auxiliary branch

master
develop

Possible auxiliary branch classifications are:

  • Function branch
  • Release branch
  • Fix Bug branches

Each branch has a special purpose. The branch from which these branches originate and the branch they merge back to are strictly defined. We’ll talk more about that later.

Technically, auxiliary branches have no special meaning. We categorize auxiliary branches according to their specific use function. Secondary branches are no different from regular Git branches.


0
retranslation

wilson_yang

Function branch

Functional branches may derive from:

develop

Functional branches must be merged back into:

develop

Functional branch naming convention:

master
develop
release-*
hotfix-*

Feature branches (or feature branches) are used to develop new features that will be available soon or later. When development begins after a functional branch is created, the point in time after which it will be merged is unknown. The essence of functional branching is that it always exists with the development process, but is bound to be merged back into Develop (with new features clearly added in the next expected release) or discarded (in case experiments don’t go as planned).

Functional branches usually exist in the developer’s repository and do not appear in the Origin repository.


0
retranslation

wilson_yang

Create a functional branch

develop 

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"Copy the code

Add completed functionality to development

develop 

$ git checkout develop Switched to branch 'develop' $ git merge --no-ff myfeature Updating ea1b82a.. 05e9557 (Summary of changes) $ git branch -d myfeature Deleted branch myfeature (was 05e9557). $ git push origin developCopy the code

--no-ff

--no-ff

Of course, it creates more empty commits, but the benefits far outweigh the costs.


0
retranslation

Summer

Release branch

This branch may derive from:

develop

Must be merged into:

develop
master

Branch naming convention:

release-*
develop
develop
develop

It is at the beginning of the release branch that the upcoming release is assigned a version number — an unprecedented version number. Until that point, the Develop branch had reflected the “next release” changes, but it was still unclear whether the “next release” would ultimately be 0.3 or 1.0 until the release branch started. This decision is made at the beginning of the release branch and is enforced by the project’s rules for version number collisions.


0
retranslation

Summer

Create a publishing branch

develop
develop 

$git checkout -b relea-1.2 develop Switched to a new branch "relea-1.2" $./bump-version.sh 1.2 Files modified successfully, $git commit -a -m "cab version number to 1.2" [relea-1.2.74D9424] cab version number to 1.2 1.2 1 files changed, 1 insertions(+), 1 deletions(-)Copy the code

bump-version.sh
those

New branches exist until a release is confirmed. In the meantime, bug fixes may be applied to this branch (rather than the Develop branch). Do not add large new features to this branch. These branches must merge back into the Develop branch and then wait for the next big release.


0
retranslation

Summer

Complete and publish your branch

master
master
master
develop

Perform the following two steps in Git:

$git checkout master Switched to branch 'master' $git merge --no-ff release-1.2 merge made by recursive. (Summary of Changes) $git tag -aCopy the code

At this point, this version has been modified and is being used as a future reference version.

Note:You might want to use it again
-sor
-u <key>To encrypt the signature.

develop 

$git checkout develop Switched to branch 'develop' $git merge --no-ff release-1.2 merge made by recursive  changes)Copy the code

This step may cause merge conflicts (perhaps because we have changed the version number). If so, try fixing it and commit again.

Now that we have completed all the steps, the release branch can be removed because we no longer need it:

$git branch -d relex-1.2 Deleted branch relex-1.2 (was FF452FE).Copy the code


0
retranslation

wilson_yang

Thermal repair branch

Branches may come from:

master

Must be merged into:

develop
master

Branch naming convention:

hotfix-*

The Hotfix branch is similar to the Release branch in that both indicate that a new production release is imminent, although not expected. They arise because an existing production version is undesirable and must take effect immediately. When a serious bug in the production version must be fixed immediately, the hot fix branch may create a branch from the corresponding tag on the master branch used to mark the production version.

develop

0
retranslation

JiaZombie

Create a bug fix branch

master
develop 

$git checkout -b hotfix-1.2.1 master Switched to a new branch "hotfix-1.2.1" $./bump-version.sh 1.2.1 Files modified successfully, $git commit -a -m "bump version number to 1.2.1" [hotfix-1.2.1 41e61bb] bump version Number to 1.2.1 1 files changed, 1 insertions(+), 1 deletions(-)Copy the code

Don’t forget to update the version number after you close the branch!

Then, fix bugs and commit once or multiple times separately.

$git commit -m "Fixed severe production problem" [hotfix-1.2.1 abbe5d6] Fixed severe production problem 5 files changed, 32 insertions(+), 17 deletions(-)Copy the code


0
retranslation

JiaZombie
Complete a bug fix branch
master
develop
master 

$git checkout master Switched to branch 'master' $git merge --no-ff hotfix-1.2.1 Merge made by recursive. (Summary of Changes) $git tag -aCopy the code

Note: You may also want to use -s or -u

to encrypt the signature.


0
retranslation

JiaZombie
develop 

$git checkout develop Switched to branch 'develop' $git merge --no-ff hotfix-1.2.1 merge made by recursive of changes)Copy the code

develop
develop
develop
develop


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


0
retranslation

Summer

summary

While this branching pattern is nothing new at this point, the “big picture” at the beginning of this article shows how useful it really is for our projects. It results in an elegant and easier to understand model and enhances team members’ understanding of branching and its release process.

A clearer PDF version of the larger image is provided here. It is recommended to print it out and hang it on the wall for worship and quick viewing during development.

Update:
gitflow-model.src.key

Git branch model. PDF download

0
retranslation

wilson_yang

Original address:
Nvie.com/posts/a-suc…Translation Address:
Laravel-china.org/topics/9992…

All translations in this article are for study and communication purposes only. Please note the translator, source, and link to this article


Our translation work is in accordance with
CCIf our work has violated your rights and interests, please contact us immediately.