Git Work Flow

Reprint: http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

As a source code management system, Git inevitably involves the collaboration of many people.

Collaboration must have a standardized workflow, so that everyone effectively cooperate, so that the project is well-organized development. "Workflow" in English, called "Workflow" or "flow", is intended to be a water flow, the analogy of the project as the flow of water, smooth, natural flow forward without impact, collision, or even vortex.

This article describes three widely used workflow processes:

• Git Flow
• Github Flow
• Gitlab Flow

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

• The Git usage specification process
• List of common Git commands
• "Git remote operation in detail"

First, function-driven

The three workflows in this article have one thing in common: "Function-driven development" (Feature-driven development, or FDD).

It means that demand is the starting point for development, with the need for functional branching (feature branch) or patch branching (Hotfix branch). When development is complete, the branch is merged into the main branch and then deleted.

Second, Git flow

One of the earliest and most widely used workflows is git flow.

2.1 Features

Its main features are two.

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

• Main Branchmaster
• Development Branchdevelop

The former is used for the release of the release, any time in this branch to get a stable distribution version, the latter for daily development, storage of the latest development version.

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

• Function branch (feature branch)
• Patch Branch (Hotfix branch)
• Pre-Send branch (release branch)

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

For a detailed introduction to git flow, please read the Chinese version of the GIT branch management strategy that I translated.

2.2 Reviews

The advantage of Git flow is that it is clearly controllable, with the disadvantage of being relatively complex and requiring the maintenance of two long-term branches simultaneously. Most tools will be master treated as default branches, but development is develop done in a branch, which makes it very annoying to switch branches frequently.

The bigger problem is that this model is based on "release", and the goal is to produce a new version after a period of time. However, many web site projects are "continuous publishing", and the code is changed and deployed once. At this point, master branches and develop branches are not very different, there is no need to maintain two long-term branches.

Third, Github flow

Github flow is a streamlined version of Git flow, specifically designed to work with "continuous publishing." It is a workflow used by github.com.

3.1 Process

It has only one long branch, that is master , so it is very simple to use.

The official recommended process is as follows.

The first step: according to the requirements, from pulling out the master new branch, do not distinguish between functional branches or patch branches.

The second step: after the new branch development is completed, or need to discuss, the master launch of a pull request (PR).

Step three: Pull request is both a notification, a notice of your request, and a dialogue mechanism where you review and discuss your code. During the conversation, you can also keep submitting your code.

Fourth step: Your pull request is accepted, merged master , redeployed, and the branch you pulled out is deleted. (It is also possible to deploy and merge first.) ）

3.2 Reviews

The biggest advantage of Github flow is that it is simple and the most appropriate process for a "continuous release" product.

The problem lies in its assumption that master branch updates are consistent with the release of the product. That is, the master most recent code for the branch is the current code on the line by default.

However, sometimes this is not the case, the code merge into master the branch, does not mean that it can be released immediately. For example, the Apple Store app was submitted for review and waited for a while to get on the shelves. At this point, if there is a new code submission, the master branch will be inconsistent with the version that was just released. Another example is that some companies have a publishing window that can be published only for a specified time, which also causes the online version to lag behind the master branch.

In this case, there is only master one main branch that is not enough. Typically, you have to master create a new branch to track the online version outside of the branch production .

Iv. Gitlab Flow

Gitlab flow is a combination of Git flow and Github flow. It absorbs the advantages of the two, both to adapt to the different development environment of elasticity, but also a single main branch of the simple and convenient. It is a recommended practice for gitlab.com.

4.1 Upstream priority

Gitlab Flow's biggest principle is called "Upstream priority" (Upsteam first), where there is only one main branch master , which is the "upstream" of all other branches. Only the code changes adopted by the upstream branch can be applied to other branches.

The Chromium project is an example, which clearly stipulates that the upstream branches are:

1. Linus Torvalds's Branch
2. Branches of subsystems (such as Netdev)
3. A branch of a device manufacturer (such as Samsung)

4.2 Continuous release

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

For "continuous release" projects, it is recommended to master establish different branches of the environment outside of the branch. For example, the branch of the "development environment" is that the branch of the "pre-environment" is master pre-production that the branch of the "production environment" is production .

The development branch is the "upstream" of the pre-issued branch, and the pre-branch is the "upstream" of the production branch. Changes in code must be "upstream" to "downstream" development. For example, the production environment has a bug, it is necessary to create a new feature branch, the first to merge it to master confirm that no problem, and then cherry-pick pre-production , this step is not a problem, just enter production .

Only emergency situations allow skipping upstream and merging directly into downstream branches.

Version 4.3 released

For a version release project, the recommended practice is to master pull a branch out of a branch, such as 2-3-stable , and so on, in each stable version 2-4-stable .

Later, only the bug is patched, allowing code to be merged into these branches, and the minor version number is updated at this point.

Five or one tips 5.1 pull Request

A function branch is merged into master a branch and must pass the pull request (Gitlab is called the merge request).

As I said before, pull request is essentially a dialog mechanism that you can draw attention to when you commit to a @ person or team.

5.2 Protected Branch

masterBranches should be protected, not everyone can modify this branch, and have the authority to approve pull Request.

Both Github and Gitlab provide the "Protect branch" (Protected Branch) feature.

5.3 Issue

Issue is used for bug tracking and demand management. We recommend that you create a new Issue and then create a new feature branch. Feature branches are always designed to resolve one or more Issue.

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

After the development is completed, in the submission instructions, you can write "fixes #14" or "closes #67". GitHub requires that the corresponding issue be closed as long as the following verbs + numbers are in the commit message.

• Close
• Closes
• Closed
• Fix
• Fixes
• Fixed
• Resolve
• Resolves
• Resolved

This way you can also close multiple issue at once, or close the issue of other code libraries, in the format username/repository#issue_number .

When pull request is accepted, issue is closed and the original branch should be deleted. If the issue is reopened later, the new branch can be reused with the original name.

5.4 Merge Node

Git has two kinds of merging: a "straight-forward merge" (Fast Forward), not a separate merge node, and a "non-straight-forward merge" (none Fast-forword) that generates a separate node.

The former is not conducive to maintaining the clarity of the commit information, but also not conducive to future rollback, it is recommended to always use the latter (that is, the use of --no-ff parameters). Whenever a merge occurs, a separate merge node is necessary.

5.5 Squash Multiple commits

To make it easier for others to read your submissions and to facilitate cherry-pick or revoke code changes, you should merge multiple commits into one before initiating pull request. (provided that the branch was developed by you alone and not master merged.) ）

This can take rebase the actions that accompany the command squash , please refer to the "Git usage specification process" I wrote.

Finish

Git Work Flow