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

Git Engineering Development practice (4)-- Git Branch Management Strategy I. the Challenge of Git version Management

Git is a very good version management tool, but there are still great challenges in version management. In engineering development, the code collaboration between developers will inevitably bring many problems and challenges:

A. how to start a Feature development without affecting other Feature?

B, because it is easy to create new branches, how to manage more branches, and how to know what each branch does over time?

C, which branches have been merged back into the trunk?

D, how to manage Release? How do you freeze Feature when you start a Release, and how can developers continue to develop new features while Prepare Release?

E, Bug appears in the code on the production line, how to fix it quickly? And the fixed code should include the developer's branch and the next Release?

Most developers use Git generally using three or even two branches, one is Master, one is Develop, and one is based on various branches of Develop. It can barely support when the project is small, but if there are more developers and the project cycle is too long, there will be all kinds of problems.

In the practice of Git source code management, Git Flow was born, which is used for Git branch management.

Second, a brief introduction to the mainstream branch strategy.

There are three mainstream branching strategies for Git: Git Flow, GitHub Flow, and TBD.

Git Flow is the most widely used Git branch management practice.

GitHub Flow is mainly used in GitHub code hosting tools.

Https://guides.github.com/introduction/flow/

Trunk based development

TBD (Trunk-based development), which is a single-trunk branch practice, is popular in SVN.

Https://trunkbaseddevelopment.com/alternative-branching-models/

Each development team should choose the most appropriate branch practice according to the characteristics of the team and the project. The first is the release cycle of the project. If the release cycle is long, Git-Flow is the best choice. Git-Flow can solve the problems of new function development, version release, production system maintenance and so on. If the release cycle is short, then TBD and GitHub Flow are good choices. GitHub Flow features the integration of Pull Request and code review. If the project already uses GitHub, GitHub Flow is the best choice. GitHub Flow and TBD have higher requirements for infrastructure such as continuous integration and automated testing.

III. Brief introduction of Git Flow

Git Flow is a source code management model built on Git to organize software development activities, a set of code of conduct when using Git for source control and a tool to simplify part of Git operations, and a source code management best practice built on Git.

By using the ability of Git to create and manage branches, Git Flow sets a specific meaning name for each branch, and merges all kinds of activities in the software life cycle into different branches, thus realizing the mutual isolation of different operations in the software development process.

The common software development models are waterfall model, iterative × × hair model, agile development model and other different models, each model has its own application scenario. Git Flow focuses on solving the problem of confusion in development activities due to various conflicts of source code in the development process. Therefore, Git flow can be well used in conjunction with various existing development models.

The data of Git Flow branch model are as follows:

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

4. Brief introduction of Git Flow model 1. Introduction of Git Flow model

In the Git Flow model, there are two kinds of branches: primary branch and auxiliary branch, in which the main branch is used to organize activities related to software development and deployment, and the auxiliary branch is used to organize various development activities to solve specific problems.

2. 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 master branch and develop branch.

A, master branch

In general, master branches can only be merged from other branches and cannot be modified directly in the master branch. The master branch holds code (Production Ready state) that is ready to be deployed in a production environment. When the development activity reaches a certain stage and produces a new piece of code available for deployment, the code on the master branch is updated. At the same time, every update, it is best to add the corresponding version number label (TAG).

All Commit on the Master branch should hit Tag.

B, develop branch

A, the develop branch is the branch that keeps up-to-date with the current development, and typically performs evening Nightly Build and automated testing on this branch.

B, develop branches arise from master branches and exist for a long time.

C, when the function of a version is developed and the function is stable through the test, it will be merged into the master branch and type the tag with the corresponding version number.

D and develop branches are generally named develop

The develop branch is the main development branch that contains all the code to be released to the next Release, mainly merging other branches, such as the Feature branch.

3. Auxiliary branch

Auxiliary branches are branches of various software development activities that are used to organize and solve specific problems. The auxiliary branch is mainly used to organize the parallel development of new functions of the software, simplify the tracking of the code for the development of new functions, assist in the release of versions, and urgently fix the defects in the production code. Auxiliary branches usually exist only for a limited period of time.

Auxiliary branches include the feature branch for developing new features, the release branch for assisting release releases, and the hotfix branch for fixing defects in production code.

All auxiliary branches have fixed use purpose and branch operation restrictions. The method of using the auxiliary branch is defined by naming the branch.

A, feature branch

Feature Branch usage Specification:

A. You can initiate a feature branch from the develop branch.

B. the code must be merged back into the develop branch.

C. Feature branches can be named with any name other than master,develop,release-*,hotfix-*.

The feature branch (topic branch) is usually used when developing a new software feature, and the code changes on the branch are eventually merged back into the develop branch or simply discarded (such as experimental and uneffective code changes).

In general, feature branch code can be saved in the developer's own code base without being forced to submit to the main code base.

After the Feature branch is developed, it must be merged back to the Develop branch. After merging the branch, the Feature branch is usually deleted, but it can also be retained.

B, release branch

Release Branch usage Specification:

A, can be derived from the develop branch

B. Must merge back to develop branch and master branch

C. Branch naming convention: release-*

The release branch is designed to release new product versions. The code on the release branch allows testing, bug modifications, and instructions (version number, release time, compile time, etc.) needed to prepare for the release. By doing release-related work on the release branch, you can make the develop branch free to accept code submissions on the new feature branch and enter a new software development iteration cycle.

When the code on the develop branch already contains all the software features planned for the upcoming release and has passed all the tests, consider preparing to create the release branch. And all business requirements outside the current upcoming release must ensure that they are not mixed into the release branch (to avoid introducing some uncontrollable system defects).

Once the release branch is successfully derived and given a version number, the develop branch can serve the next version. The version number can be named according to the version number naming convention defined by the project.

When you publish a Release branch, merge Release into Master and Develop, remember the Release version number with a Tag on the Master branch, and then you can delete the Release branch.

C, hotfix branch

Hotfix Branch usage Specification:

A, can be derived from the master branch

B. Must merge back to master branch and develop branch

C. Branch naming convention: hotfix-*

The hotfix branch was created unplanned to produce a new version of the software that can be deployed in a production environment.

When the software in the production environment encounters an abnormal situation or finds a software defect that is so serious that it must be repaired immediately, it is necessary to derive a hotfix branch from the TAG version specified on the master branch to organize the emergency repair of the code. The advantage is that it does not interrupt the ongoing development of the develop branch, allowing the people on the team responsible for the development of new features to work in parallel with those responsible for emergency code fixes.

The hotfix branch is created based on the Master branch, and after development, you need to merge back to the Master and Develop branches, while typing a tag on the Master.

V. the significance of Git Flow engineering practice

The Git Flow development model restricts the usual software development activities from the perspective of source code management, and provides a management model for software development. The Git Flow development model keeps the code warehouse clean and tidy, isolates the development among the team members, and effectively avoids the inefficiency and confusion caused by the interaction of the code in the development state.

In order to simplify the complexity of Git instructions when using the Git Flow model, nvie has developed a set of git enhanced instructions that can run on Windows, Linux, Unix and Mac operating systems.

Https://github.com/nvie/gitflow

The Git Flow tool is a set of tool commands that encapsulate Git commands as follows:

Git flow init git flow feature start xxx git flow feature finish xxx git flow release start 0.1.xx git flow release finish 0.1.xx git flow hotfix start xxx git flow hotfix finish xxx

Using the Git Flow tool, you only need two commands to complete Git Flow branch management. If you use the Git command, it is cumbersome enough for the developer.

6. Git Flow branch management application example 1, create develop branch git branch developgit push-u origin develop2, start new Feature development git checkout-b some-feature develop# Optionally, push branch to origin:git push-u origin some-featuregit statusgit add some-filegit commit 3, complete Featuregit pull origin developgit checkout developgit merge-- no-ff some-featuregit push origin developgit branch-d some-featuregit push origin-- delete some-feature4, start Releasegit checkout-b release-0.1.0 develop# Optional: Bump version number, commit# Prepare release Commit 5. Finish Releasegit checkout mastergit merge-- no-ff release-0.1.0git pushgit checkout developgit merge-- no-ff release-0.1.0git pushgit branch-d release-0.1.0# If you pushed branch to origin:git push origin-- delete release-0.1.0git tag-a v0.1.0 mastergit push-- tags6, start Hotfix

Git checkout-b hotfix-0.1.1 master

7. Complete Hotfixgit checkout mastergit merge-no-ff hotfix-0.1.1git pushgit checkout developgit merge-no-ff hotfix-0.1.1git pushgit branch-d hotfix-0.1.1git tag-a v0.1.1 mastergit push-tags

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.