Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what are the common workflows of Git". In the daily operation, I believe that many people have doubts about the common workflows of Git. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the questions of "what are the common workflows of Git?" Next, please follow the editor to study!

First, function drive

The three workflows in this paper have one thing in common: they all use "function-driven development" (Feature-driven development, referred to as FDD).

It means that requirements are the starting point of development, with requirements followed by functional branches (feature branch) or patch branches (hotfix branch). When the development is complete, the branch is merged into the main branch and then deleted.

II. Git flow

One of the earliest workflows that was born and widely adopted is Git flow.

2.1 Features

It has two main features.

First, there are two long-term branches of the project.

Main branch master

Development Branch develop

The former is used to store the released version, and any time you get it in this branch, it is a stable distributed version, while the latter is used for daily development and stores the latest development version.

Second, there are three short-term branches of the project.

Functional branch (feature branch)

Patch branch (hotfix branch)

Advance Branch (release branch)

Once the development is complete, they are merged into develop or master and then deleted.

For a detailed introduction of Git flow, please read the Chinese version of "Git Branch Management Strategy" that I translated.

2.2 Evaluation

The advantage of Git flow is that it is clear and controllable, while the disadvantage is that it is relatively complex and needs to maintain two long-term branches at the same time. Most tools use master as the default branch, but development takes place in the develop branch, which leads to frequent switching between branches, which is very annoying.

The bigger problem is that this model is based on "version release" and the goal is to produce a new version over time. However, many website projects are "continuously released" and are deployed as soon as the code is changed. At this point, there is little difference between the master branch and the develop branch, and there is no need to maintain two long-term branches.

III. Github flow

Github flow is a simplified version of Git flow and is designed to work with "continuous release". It is the workflow used by Github.com.

3.1 process

It has only one long-term branch, master, so it's very easy to use.

The process of official recommendation is as follows.

Step 1: pull a new branch from master, regardless of functional branch or patch branch, according to your requirements.

Step 2: after the development of the new branch is complete, or when it needs to be discussed, launch a pull request (PR) to master.

Step 3: Pull Request is both a notification to draw attention to your request and a dialogue mechanism for people to review and discuss your code together. You can also submit code constantly during the conversation.

Step 4: your Pull Request is accepted, merged into master, and after redeployment, the branch you pulled out will be deleted. (you can deploy first and then merge. )

3.2 Evaluation

The biggest advantage of Github flow is its simplicity, which can be said to be the most appropriate process for products that are "continuously released".

The problem lies in its assumption that updates to the master branch are consistent with product releases. In other words, the latest code for the master branch is the current online code by default.

However, sometimes this is not the case, just because the code is merged into the master branch does not mean it can be released immediately. For example, after the APP of the Apple Store is submitted for review, it will take a while before it can be put on the shelves. At this point, if there is a new code submission, the master branch will be inconsistent with the version just released. Another example is that some companies have a release window that can only be released at a specified time, which can cause the online version to lag behind the master branch.

In the above case, only one main branch of master is not enough. Usually, you have to create a new production branch tracking online version in addition to the master branch.

IV. Gitlab flow

Gitlab flow is a combination of Git flow and Github flow. It absorbs the advantages of both. It not only has the flexibility to adapt to different development environments, but also has the simplicity and convenience of a single main branch. It is recommended by Gitlab.com.

4.1 upstream priority

The biggest principle of Gitlab flow is called "upstream first" (upsteam first), that is, there is only one main branch master, which is the "upstream" of all other branches. Only code changes adopted by upstream branches can be applied to other branches.

An example is the Chromium project, which clearly states that the upstream branches are:

Branches of Linus Torvalds

A branch of a subsystem, such as netdev

An offshoot of a device manufacturer, such as Samsung

4.2 continuous release

Gitlab flow is divided into two situations to adapt to different development processes.

For "continuous release" projects, it is recommended that different environment branches be established in addition to the master branch. For example, the branch of "development environment" is master, the branch of "pre-release environment" is pre-production, and the branch of "production environment" is production.

The development branch is the "upstream" of the pre-release branch, and the pre-release branch is the "upstream" of the production branch. The code must change from "upstream" to "downstream". For example, when bug appears in the production environment, it is necessary to create a new functional branch, first merge it into master, confirm that there is no problem, and then cherry-pick to pre-production, and then enter production.

Only in case of emergency is it allowed to skip the upstream and merge directly to the downstream branch.

Release of version 4.3

For "version release" projects, it is recommended that each stable release pull a branch from the master branch, such as 2-3-stable, 2-4-stable, and so on.

Later, only by patching bug will you be allowed to merge code into these branches, and the minor version number will be updated at this time.

5. Some tips 5.1 Pull Request

When the functional branch is merged into the master branch, it must go through Pull Request (called Merge Request in Gitlab).

As mentioned earlier, Pull Request is essentially a dialogue mechanism, and you can use @ relevant people or teams to get their attention when you submit.

5.2 Protected branch

The master branch should be protected. Not everyone can modify the branch and have the authority to approve the Pull Request.

Both Github and Gitlab provide the function of "Protected branch".

5.3 Issue

Issue is used for Bug tracking and requirements management. It is recommended to create a new Issue first, and then create the corresponding feature branch. Functional branches are always designed to solve one or more Issue.

The name of the function branch can be the same as the name of issue and start with the number of issue, such as "15-require-a-password-to-change-it".

After the development is complete, you can write "fixes # 14" or "closes # 67" in the submission instructions. Github stipulates that as long as there are the following verb + numbers in the commit message, the corresponding issue will be closed.

Close

Closes

Closed

Fix

Fixes

Fixed

Resolve

Resolves

Resolved

In this way, you can also close multiple issue at a time, or close the issue of other code bases in the format username/repository#issue_number.

After the Pull Request is accepted, the issue is closed and the original branch should be deleted. If the issue is reopened later, the new branch can reuse the original name.

5.4 Merge nod

There are two types of merging in Git: one is "straight merge" (fast forward), which does not generate separate merge nodes, and the other is "non-straight merge" (none fast-forword), which produces separate nodes.

The former is not conducive to keeping the commit information clear, nor is it conducive to future rollback, and it is always recommended to use the latter (that is, the use of the-no-ff parameter). Whenever a merge occurs, there must be a separate merge node.

5.5 Squash multiple commit

To make it easier for others to read your submission, as well as for cherry-pick or undo code changes, you should merge multiple commit into one before initiating a Pull Request. (provided that you are the only one to develop the branch and have not merged with master. )

This can be done with the squash operation that comes with the rebase command.

At this point, the study of "what are the common workflows of Git" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.