preface

Git, as a powerful code management tool, has always been the first choice of major companies, especially GitHub, the world’s largest open source community, uses Git to perfection.

In our daily work, collaborative development is the most efficient way, especially for large requirements and features, and even for new projects. In this case, the use of Git will inevitably lead to some problems.

First of all, there are easy problems in project development:

  1. Git branch management branch chaos;
  2. Workflow chaos;
  3. Failed to Review code effectively

The chaotic code management has buried a huge hidden danger to the online functions, and the premise of stability is to effectively manage the code, how to develop the workflow in line with the team style has become the top priority of our work!

Next, let’s talk about Git workflow through this article.

The directory structure of this article is as follows:

  • Comparison of mainstream Git workflow
    • Centralized workflow
    • Functional branch workflow
    • Gitflow workflow
    • Forking workflow
  • How to Optimize workflow
    • Standardize the work flow criteria, improve work efficiency
    • Commit specification
    • PR specification
    • CodeReview specification
    • Github slang is a bonus
  • Reference documentation

Comparison of mainstream Git workflow

Here, I summarize the major Git workflows currently on the market:

  • Centralized workflow;
  • Functional branching workflow;
  • Gitflow workflow;
  • Forking workflow;

Each workflow has its own pros and cons, none is best, only better.

Centralized workflow

If the development team members are already familiar with SVN, centralized workflow lets you experience the benefits of Git without having to adapt to a whole new process. This workflow can also serve as a friendly transition to a more Git-style workflow migration.

Using Git to enhance your development workflow has several advantages over SVN:

  • Each development can have its own local copy of the entire project. The isolated environment allows each developer to keep his or her work separate from the rest of the project’s changes, freely committing to his or her own local repository, completely ignoring upstream development until it’s convenient to incorporate the changes.
  • Git provides powerful branching and merging mechanisms. Unlike SVN, Git branches are designed to act as a security mechanism for integrating code and sharing changes between repositories.

The working mode is as follows:

The centralized workflow uses the central repository Master as the single point entity for all changes to the project, and all changes are committed to this branch. This workflow applies only to the master branch.

Developers clone master, edit files and commit changes in their own local projects; However, the changes are local and completely isolated from msater.

To publish changes to a project, the developer pushes changes from the local master branch into the central repository. Note that the push operation pushes up all local commits that are not yet in the central repository.

Functional branch workflow

Function branch workflow, which is based on centralized workflow, and then allocate separate function branches for different function development. The main branch of this workflow is still the Master branch, but developers cannot submit code directly to the Master branch during routine requirements development. Instead, they create a new functional branch for a specific requirement and give it a descriptive name, such as: Feat -add-new-page, issue-#94320, the descriptive name can let other developers quickly understand the main function branch, improve the efficiency of collaboration between different developers.

The core idea of the functional branching workflow is that all functionality should be developed in a dedicated branch, not on the Master branch. This isolation makes it easy for multiple developers to work on their own functional branches without messing up the trunk code. It also ensures that the code for the Master branch will not be problematic, which is great for the integration environment.

Also, feature development isolation makes it possible for the Pull Requests workflow to succeed. Once a development completes a feature, instead of immediately merging it to Master, it pushes it to the corresponding feature branch and initiates a pull Request to merge changes to Master.

This gives other developers a chance to Review changes before they become trunk code. This means that Code Review can be done earlier in the development process.

Once the Pull Request is approved, the publishing function is much like a centralized workflow.

  • First, make sure that the local master branch is synchronized with the upstream Master branch. Then merge the functional branches into the local master branch and push the updated local Master branch into the central repository (there is still room for suggestions and discussion from other developers before the branch is merged into the Master).
  • In addition, if you’re stuck on a feature development issue, open pull Requests and ask for advice from your classmates. The point of these approaches is that pull Requests make it easy for team members to comment on each other’s work!

Gitflow workflow

Instead of using concepts and commands that go beyond functional branch workflows, the Gitflow workflow assigns a clear role to the different branches and defines how and when the branches interact with each other. It defines a strict branching model around project release, which makes the iterative process of the project more smooth by allocating independent branches for code development, project release and maintenance. Different from the previous centralized and functional branching workflows, gitFlow workflow has two permanent branches: The master branch stores the history of the official release, while the Dev branch acts as the integration branch of the functionality. In addition, specific branches can be set for each stage of the project development.

Of course, you can also take advantage of all the benefits of a functional branching workflow: Pull Requests, isolation of experimental development, and more efficient collaboration.

Forking workflow

The Forking workflow is a distributed workflow that takes full advantage of Git’s branching and cloning capabilities. Can safely and reliably manage large teams of developers and accept contributions from untrusted contributors.

The Forking workflow is very different from other workflows. Instead of using a single server-side repository as a “central” code base, it gives each developer a server-side repository. This means that each contributor has two Git repositories instead of one, a private local repository and a public server-side repository.

The main advantage of the Forking workflow is that contributions can be easily integrated into a project, rather than requiring everyone to push to a single central repository. Developers push to their own server-side repository, only project managers can push to the official repository. This allows administrators to accept submissions from any developer without giving them access to a central repository.

The conclusion is that this distributed workflow provides a secure way for large, well-organized teams, including untrusted third parties, to collaborate. It is also an ideal workflow for open source projects. Namespace Maintainer is used for Fork projects.

How to Optimize workflow

Optimizing Git workflow can start with the following steps:

  • Standardize the working process criteria, improve work efficiency;
  • Commit code;
  • PR specification;
  • CodeReview specification;
  • Github slang is included;

Standardize the work flow criteria, improve work efficiency

I believe we all have the same feeling, in daily development, everyone’s development habits are different, strange development habits greatly improve the maintenance cost and communication cost of the subsequent code, so it is particularly important to standardize the work flow.

Commit specification

Git must write a commit message every time it commits code, otherwise it will not commit.

In general, the Commit message should be clear, stating the purpose of the commit and what it did. However, in daily development, people’s commit messages are very strange. It is common to use mixed Chinese and English messages, fix bugs and other general messages. As a result, the maintenance cost of subsequent code is very high, and sometimes I don’t know what problem my fix bug fixes.

Based on the above problems, we can monitor the user’s Git commit message in some way, so that the specification can better serve the quality and improve the efficiency of everyone’s research and development.

Commit message format:

    <type>(<scope>): <subject>
Copy the code

  • Type (required), which specifies the type of Git commit

    Common identifiers are as follows:

    Feat: New feature fix/to: Fix a bug. This feature can be found by QA or developed by ourselves. Suitable for one commit direct fix problem to: only diff generated does not automatically fix this problem. Suitable for multiple submissions. Finally submitted to fix the problem when using fix docs: documents (documentation) style: format (does not affect the change of code to run) refactor: refactoring (namely not new features, also not modify the bug code changes) perf: optimize the related, such as improving performance, experience the test: Add a test chore: changes in the build process or helper tools revert to a previous version merge code syncCopy the code

  • The scope (optional)

    Scope is used to specify the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project.

    For example, in Angular, it can be location, browser, compile, compile, rootScope, ngHref, ngClick, ngView, etc. If your changes affect more than one scope, you can use * instead.

  • The subject (must)

    Subject is a short description of the commit purpose, no more than 50 characters long.

    It is recommended to use Chinese (I feel Chinese people can describe the problem more clearly in Chinese).

    The ending is not marked with a period or other punctuation. Git commit message:

    Fix (DAO): The user query attribute is missing. Feat (Controller): The user query interface is developedCopy the code

Git commit specification git commit specification git commit specification

It makes it easier for programmers to trace commit history and see what happened. Once commit messages are constrained, it means that we will be careful with every commit, rather than trying to put all changes into a Git commit, and the history of changes will be clearer. Only a formatted COMMIT message can be used to automate output of the Change log.

PR specification

When collaborating based on Github Flow, how to communicate based on complete and clear Pull Request is a key step. Tool checking is the most powerful safeguard, but outside of the code, you have to rely on convention.

Writing a qualified PR should satisfy the following criteria:

  • A PR is only about one thing
  • Avoid oversized PR
  • PR title — Outlines the objectives of the Pull Request
  • PR Description — A Prospective Reviewer
  • Detail what feedback, if any, is required

A PR is only about one thing

If it is necessary to submit a PR for several things (for example, the changes are very small, they depend on each other, etc.), you need to specify each one and make sure that the PR description covers all the changes.

Large swaths of code formatting should be a separate Commit, not mixed with code changes, so that each Reviewer can easily review a clean code change DIFF.

Avoid oversized PR

Modifying PR for more than 1000 lines requires consideration of whether the PR can be split into subtasks separately (a reasonable program structure should also be decoupled).

If PR involves an excessive number of commits, the development process is often riddled with “try — fix — try another way” refactoring iterations. In this case, it is best to discard the process commit, apply meaningful changes one at a time to the new branch, and then raise PR.

PR title — Outlines the objectives of the Pull Request

For example, try XXX method to implement… , optimization… Fix the exception handling of XX in XX state.

PR Description — A Prospective Reviewer

Keep in mind that anyone in the company could read the Pull Request at any time, so the content and tone should be each with a potential Reviewer in mind. Do not assume that the Reviewer is already familiar with the context.

Provide a description of the origin of the work as appropriate and be sure to include links. For example, links to relevant business documents need to be added to places related to special businesses. When dealing with very exotic bugs, it is necessary to attach relevant clues and links to information.

Detail what feedback, if any, is required

Take a look at the code/discuss a technical implementation/comment on the design etc.

Know when you need feedback. If the PR is not complete (there are still some code changes to push) it should be highlighted, and a common practice is to prefix the title with [WIP] (in progress).

CodeReview specification

After the PR is submitted, the project Owner is required to CodeReview the CONTENT of the PR.

CodeReview objectives and Principles:

  • Improve code quality, identify potential defects early, and reduce the cost of fixing/fixing defects;
  • Promote knowledge sharing within the team and improve the overall level of the team;
  • For reviewers, the review process is also a process of thinking reconstruction, helping more people understand the system;
  • It is a means of transferring knowledge, letting others who are not familiar with the code know the author’s intentions and ideas so that it can be easily maintained in the future
  • Can be used to confirm that their design and implementation is a clear and simple;
  • Encourage each other to learn from each other’s strengths and strengths;
  • Complete Code Review efficiently and quickly;

Github slang is a bonus

  • PR a Pull Request. Pull requests to submit code to other projects;
  • LGTM Looks Good To Me. The code has been reviewed and can be merged;
  • SGTM Sounds Good To Me. Same as above;
  • WIP Work In Progress. If a feature is significantly modified, mark the WIP in the PR to tell the project maintainer that the feature is not complete and Review some of the commit code first.
  • PTAL Please Take A Look. They’ll also @SomeBody and tell them to come and see if there’s a problem.
  • TL; DR Too Long; Didn ‘t Read. It is generally used in the summary part at the beginning of a long article to remind users that the content is long. If you don’t want to discuss it in depth or the time is limited, you can read the summary.

Reference documentation

  1. Git workflow under the Byte development facility
  2. Git workflow experience sharing
  3. Pull Request Writing Guide
  4. CodeReview specification
  5. How to pull a request gracefully
  6. Martin Fowler thirty thousand words unscramble source code branch management model