Git-based source control model--git Flow

Original: http://www.ituring.com.cn/article/56870

What Git Flow is

Git flow is a model of the Organization's software development activities built on GIT and is a software development best practice built on top of git. Git flow is a set of behavior specifications and a tool for simplifying some git operations when using Git for source control.

In May 2010, in a blog post called "A successful Git branching model," @nvie introduced a software development model on top of git. By leveraging Git's ability to create and manage branches, you set specific meaning names for each branch and merge the various activities in the software life cycle into different branches. It realizes the mutual isolation of different operation in software development process. The activity model of this software development is called "Git Flow" by Nwie.

In general, software development models have different models, such as waterfall models, iterative development models, and recently emerging agile development models. Each of these models has its own application scenario. Git flow focuses on the problem of confusing development activities due to various conflicts in the source code during the development process. As a result, Git flow can be used in combination with a variety of existing development models.

Before you start studying the specifics of git flow, here's a picture of the model (quoted in Nvie's blog post):

Branching in Git flow

The Git flow model defines both the main branch and the secondary branch. The main branch is used to organize activities related to software development and deployment, and to assist branch organizations in various development activities in order to solve specific problems.

Main Branch

The main branch is the core branch of all development activities. The output from all development activities will eventually be reflected in the code of the main branch. The main branch is divided into the master branch and the development branch.

Master Branch

The master branch should be stored in code that is ready to be deployed in the production environment (Production readiness State). When the development activity is over, the code on the Master branch is updated when a new, ready-to-deploy code is generated. At the same time, each update, it is best to add the corresponding version number tag (tag).

Develop Branch

The develop branch is the branch that holds the latest development results. Usually the code on this branch is also the code that can be nightly released daily (Nightly build). So this branch can sometimes also be called "Integration Branch".

When the code on the develop branch has implemented all the functions in the software requirements specification, after passing all the tests, and the code is stable enough, you can merge all the development results back into the master branch. For newly submitted code suggestions on the Master branch, a new version number label (tag) is used for subsequent code tracking.

Therefore, each time the code on the develop branch is merged back into the master branch, we can assume that a new version is available for deployment in the production environment. In general, "Updating code on the master branch only when a new, deployable code is released" is a guideline that everyone is recommended to follow. Based on this, in theory, whenever a code is submitted to the Master branch, we can use Git hook to trigger the automatic testing of the software and the automatic updating of the production environment code. These automated actions will help reduce some of the transactional work after the new code is released.

Auxiliary Branch

A secondary branch is a branch of various software development activities that are used to organize a specific problem. Auxiliary branches are mainly used to organize the parallel development of new features of software, to simplify the tracking of new features development code, to assist in the release of releases, and to make urgent repairs to defects in production code. These branches are different from the main branch and usually only exist for a limited time frame.

Auxiliary branches include:

• The feature branch used to develop new features;
• Release branch for the auxiliary version release;
• Hotfix Branch for correcting defects in production code.

These branches have fixed usage purposes and branch operation restrictions. From a purely technical point of view, these branches are no different from other git branches, but by naming, we define how to use these branches.

Feature Branch

Usage Specification:

• Feature branch can be originated from develop branch
• The code must be merged back into the develop branch
• The name of the feature branch can be used in addition to,, master develop release-* , hotfix-* any names other than

The feature branch (sometimes called the "topic branch") is often used when developing a new software feature, where code changes are eventually merged back into the develop branch or simply discarded (e.g., experimental and poorly-performing code changes).

In general, feature branch code can be stored in the developer's own code base without forcing it into the main code base.

Release Branch

Usage Specification:

• can be derived from the develop branch
• Must be merged back to develop branch and master branch
• Branching naming conventions:release-*

The release branch is designed to release a new version of the product. The code on this branch allows for minor bug fixes, various explanatory information needed to prepare the release version (version number, release time, compile time, and so on). By doing this on the release branch, you can leave the develop branch free to accept code submissions on the new feature branch and into the new software development iteration cycle.

When the code on the develop branch already contains the software features planned for all upcoming releases, and all tests have passed, we can consider preparing to create the release branch. All business requirements outside of the current release will have to be ensured that they cannot be mixed into the release branch (avoid introducing some of the system flaws that are not controllable).

After the release branch has been successfully derived and given the version number, the develop branch can serve the "next version". The so-called "next version" is the version released after the current release. The name of the version number can be named according to the version number of the project definition.

Hotfix Branch

Usage Specification:

• can be derived from the master branch
• Must be merged back to master branch and develop branch
• Branching naming conventions:hotfix-*

In addition to being unplanned, the hotfix branch is very similar to the release branch: it can produce a new version of the software that can be deployed in the production environment.

When software in a production environment encounters an anomaly or discovers a software defect that must be repaired immediately, it is necessary to derive the hotfix branch from the tag version specified on the master branch to organize the emergency repair of the code.

The obvious benefit of doing this is not interrupting the development of the ongoing develop branch, allowing people in the team who are responsible for new features to work in parallel with those responsible for code emergency fixes.

Further

The Git flow development model constrains the usual sense of software development activities from a source control perspective. It should be said that for our software development provides a reference to the management model. The Git flow development model keeps Nvie's development code warehouse neat, isolating the development of each member of the team, and effectively avoiding inefficiencies and confusion caused by the interaction of code in the development state.

The so-called model, in different development teams, different cultures, different background of the project may need to be properly cut or expanded. Good luck to you all!

PS: To simplify the complexity of git instructions when using the Git flow model, Nvie developed a set of git enhancement instructions. Can run under Windows, Linux, UNIX, and Mac operating systems. Interested students can go and have a look.

Git-based source control model--git Flow