Recently, I found that some new members of the team have a bad problem, that is, all the information submitted by Git is OK, but when I use Sourcetree to look at it, all the information is OK, and I don’t know what problem was solved every time I submitted.

Since the newcomer does not speak code, then I also advise these newcomer rattail juice here, remember:

Git rollback crematorium

In a team, since we all maintain the same repository, we need to follow the corresponding workflow and commit specification. The Commit Message is an important point. A readable and clearly described Commit message allows the rest of the team to understand the role of the commit without having to look deeply into the code.

More importantly, after the specification commits the information, changelog can be generated directly from the COMMIT (that is, the document used to explain the differences from the previous version when a new version is released), which saves a lot of time.

Angular’s submission specification is simple and clear, with only three sections: header, content, and remarks. Therefore, new team members are required to fully comply with the specification:

< type >(< change scope >): < summary > // Empty line < description > // Empty line < remarks >Copy the code

Type and summary are mandatory, and the rest are optional. Here’s a breakdown of what to write in each section:

The title area

The format of the header line is:

< Type >(< change scope >): < Summary >Copy the code

Sample submission:

test(compiler): use `yarn bazel` instead of `bazel` in error message
docs(router): Correct equivalent for 'enabled' initial navigation
fix(language-service): Prevent matching nodes after finding a keySpan
Copy the code

These examples are taken from the official Angular submission and follow the header line convention, where:

< Type > is mandatory and can only be one of the following:

  • Feat: new features
  • Fix: fix the bug
  • Docs: Only the document has been changed
  • Style: Modify the code format (such as removing Spaces, changing indentation, adding and deleting semicolons, without affecting the code logic)
  • Refactor: Refactoring code (theoretically without affecting existing functionality)
  • Perf: Changes to improve performance
  • Test: Adds or modifies test cases
  • Chore: Change the build process, or add dependency libraries, tools, etc
  • Revert: Rollback to a previous version

Feat and fix are the two most commonly used, accounting for more than 50% of submissions.

This is not mandatory. When a project is divided into several modules, it is best to specify which module to change, such as the Compiler and Router modules in the Angular submission case above.

< summary > This is also mandatory and very important! Why is it called a short summary? It means that the text should not be too much, never more than 50 characters, and it is a summary and general text, for example:

Feat: Support Bigsur Fix: Fix Windows 7 Flash RollbackCopy the code

It must be obvious at a glance what functionality was added or what problem was solved by the commit, and this information can be used directly for Changelog.

Content area

This is a detailed description of the commit, broken down into multiple lines. Here’s a simple example:

Added timed tasks and ignored unpaid orders when running once a day in the early morningCopy the code

You can write many lines in the content area and describe them in great detail. For example:

perf: Use a new diff algorithm at rendering time to reduce the actual number of Page. SetData updates caused by Vue component updates. 1. Use runtime/ diffdata. js to check and optimize the size. The rule is A. B. After the second update, check the _data object. If there is a __keyPath, update it according to __keyPath, no __keyPath means no update. It reduces the case that only one root node property is changed but the data of the entire component tree is passed to page.setdata, thus reducing the real machine, especially Android, due to the large amount of setDataCopy the code

The advantage is that if other team members are interested in the submission, they can read the detailed description in the content area to get more information about the submission.

Therefore, we require newcomers: for minor changes, this section is not required, but for major requirements, updates, etc., a body must be added.

Note area

This section is only used in the following three cases:

  1. BREAKING CHANGE occurs

    perf(core): improve vdom diffing by removing 'foo' option

BREAKING CHANGE: The 'foo' option has been removed.
Copy the code

  2. Close an issue

    fix(v-model): handle events on blur

close #28
Copy the code

  3. Revert a submission

    revert: feat(compiler): add 'comments' option

This reverts commit 50c4d4bc92ac861c9be435965a3ae493779e527c.
Copy the code