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

This article focuses on "how to standardize the submission of Git". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to standardize the submission of Git.

1. Preface

At present, most companies are using Git as version control, and every programmer commits the code every day. Many developers, including myself, sometimes submit it in a hurry or in an attempt to save trouble:

Git commit-m "modify bug, optimize code"

After a while, suddenly look for a specific submission and you will find that it is not very easy to find. So we need to regulate our code commit to avoid this situation. At the same time, a good submission specification also helps us to generate a clear ChangeLog, which is more conducive to collaboration among colleagues.

If you want to be a contributor to a well-known open source project, you should regulate your own code submission.

2. Git submission specification

At present, the industry has done relatively well, the more valuable reference is the submission specification of the well-known front-end framework AngularJS. Let's first look at an example:

Corresponding format:

[optional scope]: # blank line [optional body] # blank line [optional footer]

More stringent projects may be submitted requiring English descriptions, especially international open source projects.

Based on the above example, let's take a look at the Git submission specification recognized by the industry.

Type

Refactor said that this submission is refactoring code, that is, it is a submission type type, in addition to refactor and:

The new function of feat, as its name implies, is the realization of new requirements.

Fix repair is the repair of bug.

Docs documents, mainly used to describe changes to the document.

Style is mainly about code style-related submissions, such as formatting, etc.

Refactor refactoring code, refactoring of existing functions, but different from bugfix.

Test test-related submissions are less commonly used.

Changes to the chore build process or aids are less common, such as using Maven before and replacing it with Gradle.

The type submitted for each submission statement is required, and it makes the role of this submission clear at a glance.

Scope (optional)

It is used to indicate the scope of impact of this submission, and it is convenient to locate quickly. You can specify which module (usually the module name) or which layer (data layer, service layer, or view layer) is affected.

Subject

It is the above modified copyright information, which is a brief description of this submission. Just like Brother Pang should write an article with a title, don't be too long.

Body (optional)

It is a more detailed description of the items involved in this submission, listing the code functions. Here, Fatso is used to use the list syntax of markdown, that is, to separate entries with a dash. Of course, body is not required, if subject can describe it clearly.

Foot (optional)

Describe the break change or issue associated with this submission.

Break change

Indicate whether destructive changes have been made in this submission, such as version upgrade, reduction of interface parameters, interface deletion, migration, etc. If the above impact occurs, it is strongly recommended to include break change in the submission information, which is conducive to quick positioning, rollback and review if something goes wrong.

Issue

If you find that the project has bug, or optimization suggestions, or even a new task, you can use issue to submit a task to the project.

Issue is not the exclusive function of some Git platforms. Platforms such as JIRA also have similar functions. Their functions are more or less the same, and they can well reflect the growth and participation of the project. Then when the Git is submitted, we can associate the issue involved in this submission in the foot area.

# related to issues # F12YC Magazine F45JW # shutting down Closes # F12YC

There is no fixed format here, but try to refer to some well-known projects to do.

3. Tool Amway

With all that said, I'm sure you already know something about the specifications submitted by Git. Here are some useful tools to help you put these specifications in place. There are many Git Commit Message template plug-ins in the Intellij IDEA plug-in market, and these specifications can be implemented visually.

At this point, I believe you have a deeper understanding of "how to standardize the submission of Git". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.