About Git submission specifications

create by db on 2021-1-25 16:34:46

Recently revised in 2021-1-25 19:34:56

Idle time to have a tight mind, busy time to have leisure fun

This article has participated in the call for good writing activities, click to view: back end, big front end double track submission, 20,000 yuan prize pool waiting for you to challenge

directory

  • preface

  • The body of the

  • conclusion

preface

Returns the directory

It’s the same with programming.

If you have a project and you write it yourself from start to finish, you can write it however you want and no one can interfere with you. But in a team environment where everyone is individual, the code will be a mess and the project will be ruined. Both development and future maintenance will be a disaster.

At this time, someone put forward why not unify the standard, we all follow this standard. As a result, ESLint, JSHint and other code tools have mushroomed and become essential for project construction.

The Git Commit specification may not be that dramatic, but if you see a bunch of stupid commits during a rollback, you’ll probably get upset. Therefore, strictly abide by the norms, self-interest.

The body of the

Returns the directory

The role of submission specifications

In most cases, the person who read the commit history is not the same person who submitted the code. When someone reads your commit history, they probably don’t know the details of the code. How can you let them know the meaning of each commit in the shortest time?

  • What is the scope of impact of each submission?
  • In which commit was this bug fixed?
  • In which commit was this new feature added?
  • Is the change backward compatible?
  • Is the code rolled back?
  • Did you just change the documentation and format the code?
  • Have tests been modified or refactored?
  • Is the code optimized for performance?

Format of the submission specification

With what specification?

One popular approach is Conventional Commits, which are inspired by, and largely based on, Angular Commits.

The contracted commit specification is a lightweight convention based on commit messages. It provides a set of simple rules for creating a clear commit history; This makes it easier to write standards-based automation tools. This convention dovetails with SemVer, describing new features, bug fixes, and disruptive changes in the commit message.

Its message format is as follows:

<type>[optional scope]: <description> // header
/ / an empty line
[optional <body>]
/ / an empty line
[optional <footer(s)>]

Copy the code

Here’s a simple example:

Feat (config): Allows config objects to inherit directly from other Config objects BREAKING CHANGE Adds the extends field to config objects to inherit config Close Issue #23Copy the code

And of course we could write it a little bit more succinctly

Feat: Enable config objects to inherit from other Config objectsCopy the code

Note:

  • Git commit: Git commit: git commit: Git commit: Git commit: Git commitgit commit -aThe edit page is displayed. If it’s a single line, you can justgit commit -m 'COMMIT MESSAGE'Complete the submission.

Format on

Header (required)

The header section is a single line with three fields: Type (required), scope (optional), and Description (required).

and

can be omitted

(s)>

Such as:

Feat: Added Financial ReportCopy the code

1. Type (required)

Type is mandatory. It is used to specify the commit type. Feat and fix are mandatory, and docs, style, build, refactor, and Revert are mandatory. (Refer to Renrendai Big Front-end Technology Center)

# main typeFeat. Fix a bug# special typeStyle: changes that do not affect the meaning of the code, such as removing whitespace, changing indentation, adding or deleting semicolons. Build: changes that are made to the builder or external dependencies, such as webpack, NPM refactor: changes that use revert when refactoring. Do git revert to print the message# do not use typeTest: Adds tests or modifies existing tests PERF: changes to improve performance CI: Changes related to CI (Continuous Integration Services) : Does not modify SRC or other modifications to Test, such as changes to the build process or ancillary toolsCopy the code

Note:

  • When a change includes both the main type and the special type, the main type is used.

2. Scope (optional)

It is optional to specify the scope of the modification in the format of the project name/module name. It can be a file address, such as /lib/utils. It can also be a function point parser. No more than two words is recommended

Such as:

Loation // Indicates that the impact is small. A small function. Module // indicates that a module, such as the login module, home page module, and user management module, is affectedCopy the code

Note:

  • If multiple modules are modified at one commit, it is recommended to split them into multiple COMMIT for better tracking and maintenance.

3. Description (required)

It is mandatory and contains a maximum of 50 characters.

The specification is as follows:

  • Start with a verb and use the present first-person tense such as’ change ‘rather than’ changed ‘or’ changes’
  • The first letter is lowercase
  • Ending without a period (.)

(optional)

It is optional. The specific modification information should be as detailed as possible.

The body mainly describes the situation before the change and the motivation for the change. There is no requirement for small changes, but the body must be added to explain major requirements and updates.

Footer (s)(optional)

Optional, place remarks what, if it is a bug, you can put the bug ID, generally do not need to write.

Recommended Tools

commitizen

This is a node-based interactive constraint command tool for those who like to use the command line.

Used for details, please refer to the Git commit message specification | the nuggets – everyone borrow big front-end technology center

Git Setup template

For those who prefer to use git tools with interfaces like sourceTree, git configuration templates can be used.

Use details, please refer to Always should pay attention to the git commits specification | blog garden – Four two

conclusion

Returns the directory

Of course, in practice, you don’t have to use this rule, but you can use it and make changes on your own.

The commit specification is very beneficial for future maintenance. In the near future, when using Git, merge code will often have conflicts, some unexpected accidents, such as someone else accidentally overwrites your code, and this feature is a long time ago, so what do you do? In general, it’s nice to have a local backup, but probably no one will save one locally every time they commit, because that would be inefficient and, depending on the cycle and requirements of the project, as the project gets bigger and bigger, more and more packages will be backed up locally. No one would choose that. The last way to do this is to version back, of course, if you submit the information succinct, otherwise god knows which one it is.

As for when to commit, try to complete a new feature or optimize a feature, fix a bug, etc. But there is a premise here that you have to have no problems with the local test, otherwise that is useless.

The road ahead is long, and I see no end.

References:

  • About Git submit specifications | blog garden – challenger V

  • Git commit message specification | the nuggets – everyone borrow big front-end technology center

  • Always should pay attention to the git commits specification | blog garden – Four two

  • Git commits specification | zhihu – yinfxs

  • template_git | GitHub – ctaodream

Postscript: Hello friends, if you think this article is good, remember to give a thumbs-up or star, your thumbs-up and star is my motivation to write more and richer articles!Making the address

Document agreement



dbThe document library 由 dbusingCreative Commons Attribution – Non-commercial Use – Same way Share 4.0 International LicenseGrant permission.

Based on thegithub.com/danygitgitOn the creation of works.

Use rights other than those authorized by this License agreement may be obtained fromCreativecommons.org/licenses/by…Obtained.