Student: How do I writeGit CommitInformation, everyone has their own opinion, and every team has its own rules. There is no clear standard, and today is not about standards, but a relatively elegant way to do it.

[ac7536f1f] update some files
[cdc6708ad] change style
[93d4b716d] remove css files
[dfb928e85] update readme
Copy the code

Before, when I wrote the submission information, I only put the subject information. Now, you can see the downside of this, because when you look at these messages, you don’t really know what the commits are. Commit message [52a9e19] Update; commit message [52a9e19] Update; Maybe after a while, this student will not know what is submitted.

There are no clear standards for Git Commit messages, but there are some good rules:

  • Make submitting information business relevant
  • Indicate the type in the submission information
  • Decription if necessary
  • Keep your submission brief
  • Try to use English

Make submitting information business relevant

The first code snippet at the beginning of this article is the commit record I submitted earlier. Looking at it now, I don’t know what I wrote. The only way to know exactly what is committed and what features are involved is to use the versioning tool.

Commit information, like code, is not only for yourself, but also for the rest of the team, as well as for comments on the commit information. In my experience, I’ve seen a lot of people write and submit information for convenience. Fixed a login problem, but only wrote Fix bug in the submission message. As a result, it is very difficult to backtrack and troubleshoot problems in the code. Over time, only one Commit can be performed. Keep in mind that submitting information is not just for you, but for your team.

The sample

use

Implement single sign-on interface

Implement new features

Here’s a tip: when submitting code, if you can’t think of anything else, you can use the requirement description as your submission information.

Indicate the type in the submission information

Let’s start by sorting out the reasons for submitting code, which can be broadly divided into several categories: new features, code upgrades or changes, Bug fixes, documentation, theme UI changes, and test cases. There are no more than a few reasons to submit code, so now add a label to each of these reasons and you get the following list.

  • Feat: new features
  • Upgrade: Function Upgrade or code change
  • Fix: Bug fixes
  • Doc: Written as a document or README
  • Style: Theme UI changes
  • Test: adds Test code

The sample

use

Feat: Implement single sign-on interface

Implement single sign-on interface

Keep your submission brief

Imagine if a submission message is dozens or even nearly 100 words long. Being a lazy programmer when you can, of course you can’t write such a long submission. Keep the number of words to a minimum, preferably no more than 50 characters, as long as you can correctly express what this submission represents.

The sample

use

Feat: Implement single sign-on interface

Implement single sign-on interface and modify login.java… (100 words omitted)

For reasons of length, error examples use ellipsis (…). Instead. As you can see, the green example already expresses the topic of this submission correctly, so there is no need to write so many words.

Decription if necessary

A description is a supplementary or detailed description of the submitted information, which is rarely noticed by students. But sometimes descriptions are necessary, such as when merge code conflicts, and submitters need to include the conflicting files in the description.

The description can be broken into multiple lines, with a line break at the 72nd character.

The sample

use

Upgrade: Update meta

  • update contributors
  • update eslint
  • update jest
  • update webpack

Upgrade: Update meta

Try to use English

Some people can say Chinese is the mother tongue, why not recommend using Chinese. In team development, it is much clearer to use Chinese. Not everyone in a team is good at English, so you need to make sure that your submissions can be read by others, otherwise it’s counterproductive.

More or less everyone has used Windows for development, when using CMD to view git log, Chinese is garbled. This is too unfriendly, if you want to display a normal SAO operation. This is why it is advisable to use English as much as possible.

Cmd Git log garbled

Another reason is that if we write an open source project and submit it to GitHub for developers around the world, it will be very friendly to submit information in English (in case the project becomes popular).

English information Format

If you’re going to use English, pay attention to the format of the text you submit. English case and symbols will affect the appearance of the submitted information. So we have to put some constraints on the English format.

  • The statement begins with an uppercase character
  • Do not end statements with periods (.)

The sample

use

Fix: Fix can’t login bug

Fix: Fixes the login bug

The article continues to update, scan the qr code below to pay attention to the public number for the first time to read


In this paper, starting from: https://baozi.fun/2020/07/10/write-elegant-commit-message

This article is formatted using MDNICE