This is the fifth day of my participation in the More text Challenge. For details, see more text Challenge

This article has participated in the weekend study program, click to see the details.

preface

As I mentioned in my last blog post, I had a colleague who liked to format the code and then submit it. Every time he changed a file, even if it was only one line, he would format the entire file. Looking back at git commit records, you can see that all commit history is overwritten

Take a look at the git commit record for a small project:

Dude, what’s with this screen full of ones?

Reading this, you might think this is a case of a small company having an irregular submission record, but it’s not just a small company problem. If team leaders don’t set the standards, the quality of their colleagues can be mixed, whether it’s a big company or a small one. From this point of view, it is necessary to have a git commit specification in your team, so what should you look for in git commit? Today, ice cube is here to take care of git submissions

The three elements of the commit

Mainstream submission specifications generally include: title (type, short summary), content, remarks. Summary of which is required to fill, the type of best also fill, the rest are optional.

Below the big ice cube to see that introduce what these three aspects specifically refer to:

A, the title,

The title is divided into three parts: type, scope of change and concise summary:

1, type,

The main types of specifications are:

  • Feat: New feature or feature change related
  • Fix: Related to fixing bugs
  • Docs: Changed documentation, comments related
  • Style: Changes the code formatting related, such as removing Spaces, changing indentation, switching between single and double quotes, adding or deleting semicolons, etc., do not affect the code logic
  • Refactor: Refactoring code, related to changes in code structure (theoretically without affecting existing functionality)
  • Perf: Performance changes related to performance and page optimization
  • Test: Add or change test cases related to unit tests
  • Build: Related to changes that affect compilation, such as package path changes, NPM procedure changes, etc
  • Ci: Changes in continuous integration. Some build systems now like to describe CI functions in YML. In the event of such changes, ci is recommended
  • Chore: Related to other changes such as file deletion, build process modifications, dependency library tool updates and additions
  • Revert: Related to the rollback version

In fact, feat, fix and perf are the most commonly used in actual development. Git submission is basically to realize requirements, change bugs and optimize performance. In addition to the main types mentioned above, we can also customize the types according to the team requirements, after all, specifications are dead, people are alive. For example, in order to make it easier for you to read, we will leave only a few commonly used ones and change them all into Chinese, such as:

  • Feature change: New feature or feature change related
  • Bug fixes: Bug related fixes
  • Optimization: Performance changes, performance, page optimization related

There is no good or bad, what is suitable for the team is the best!

2. Scope of change

When a project is divided into several modules, it is important to specify which module changed so that it is easy to see which module the committer changed in the Git commit record. For example, the compiler module is modified this time, and the router module is modified next time. Such as:

  • compiler
  • router

3. Simplify your summary

Required summary is very important, is generally a summary of the text. It’s easy to see at a glance what the main commit is, whether it’s adding functionality or fixing a problem, and it’s also the default line in most Git administration tools. If you write standards, the submission will look nice and neat. Such as:

Fix: Fixed infinite raffle bugCopy the code

Second, the content

Content mainly fill in detailed changes, can be newline. Of course, it doesn’t have to be like writing a small composition, after all, our programmers’ time is still very precious. If the condensed summary is perfectly written, it’s ok not to write the content. However, if there is a lot of change and there is enough time, it is responsible to fill in the implementation, requirements and background of this submission. Such as:

- Fixed the infinite draw bug where the interface for multiple draws can be called repeatedly when the network is not good Changed the logical decision of the lottery interface this time, in the concurrent request...... Adopted... So... .Copy the code

Third, note

Comments don’t seem to be that important. The main function is to add some additional hooks, such as automatically triggering code linkage compilation after the commit record, or automatically generating notification of Git commit.

Afterword.

The specification of the team’s Git commit, commit log record at a glance, with automated integration tools can automatically generate Git change log. And call the mailbox interface prompt, automatically send commit, build, release records of people, so the team managed Git commit specification is very necessary, even an indispensable part.

The purpose of this article is to provide ideas for normalized Git submission, so that problems can be identified and solved in advance, so as not to be confused when looking through git records. If it helps you, just like it, and if there are mistakes, you are welcome to point them out. Thanks for reading.

PS: today is the fifth day to participate in the nuggets’ more text challenge, I did not save the draft, but I was still trying to write more on Saturday, I do not know when I can finish a blog in an hour?

Although not many people see it, but also to their own drainage ~ more challenging article catalog is as follows:

  • Flex layout container elements and project elements attributes
  • 2021.06.02 how to play with CSS Gradient Background
  • How to Use SVG to create Text Effects along Arbitrary Paths
  • 2021.06.04 “Front-end code specification of 3 categories and 15 subcategories, let the team code be standardized!”