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

This article will explain in detail how the work flow of Git is, and the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

As a source code management system, Git inevitably involves multi-person cooperation.

Collaboration must have a standard workflow, so that everyone can cooperate effectively and make the project develop in an orderly way. "Workflow" in English is called "workflow" or "flow", which means that the project flows forward smoothly and naturally like the current, without impact, collision, or even whirlpool.

Here are three widely used workflows:

Git flow

Github flow

Gitlab flow

If you are not familiar with Git, you can read the following article first.

"Git usage specification process"

List of commonly used Git commands

"detailed explanation of Git remote operation"

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.

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 "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

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".

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

About how the workflow of Git is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.