Introduction

In software development, we use Git to track and manage code changes. Each commit records the code modification, commit message, and details. Clear and specific commit messages help team members quickly understand the reasons for changes and the specifics of the modification, which is crucial for ensuring efficient code management and smooth team collaboration.

During development, small features often undergo multiple tweaks before being merged into the main branch. Because changes can be minor, developers may neglect writing clear commit messages or use overly brief titles—or worse, omit them entirely. As the number of commits increases, it becomes harder to track the specifics of each change, affecting future maintenance and debugging.

Therefore, it’s recommended to break down changes into finer details when modifying multiple files and ensure each commit reflects the specific change in a timely manner. At this point, using language tools like GPT can quickly analyze the changes and generate consistent, detailed commit messages, ensuring clear documentation for each commit.

There isn’t a single correct way to write commit messages. Different companies may have different preferences and standards, and developers may have their habits. Therefore, writing standardized commit messages ensures consistency and readability during communication among developers.

Conventional Commits

Conventional commit messages can unify the format as much as possible, enhancing readability and consistency. Without considering company-specific rules, the industry generally follows common conventions, which usually include the following points:

1
2
3
4
5

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

This format isn’t absolute, but a good commit message structure generally includes the type, description, and body to describe the commit.

Type

The type is the most important part of a commit message, describing the type of change made. Common types include:

There can be other types as well, such as deprecate or release, or even custom ones like post for publishing a new article in my Hugo blog management.

Scope

Scope, added after the type, specifies the area or module affected by the change. This part is optional, providing more detail about the change. Examples:

• feat(ui): Add new UI feature

• fix(api): Fix bug in API

Description / Subject

The subject follows the type and scope and briefly summarizes the specific change in the commit. By convention, the subject is written in the imperative and kept under 50 characters, describing the code changes in a brief summary. This helps other developers quickly understand the purpose and content of the commit.

⚠️ No period at the end of the subject.

Examples:

• feat(auth): Add OAuth2 authentication mechanism

• fix(database): Fix database connection timeout issue

Body

The body starts one line after the subject and explains the details and context of the commit in a clear and detailed way. It can include:

1. The reason for the change
2. What issue was fixed or what feature was added
3. Any relevant technical details or considerations
4. Potential impacts (e.g., compatibility with other modules)

The body can be formatted using Markdown for better readability, such as using lists or code snippets. Each line should ideally stay within 72 characters for better readability in email clients or other tools.

How Do Others Write?

Let’s see how others write 😉.

Based on the examples below, some common rules can be summarized:

1. Concise title, usually under 50 characters, using present-tense verbs without punctuation.
2. The body elaborates on the changes if needed, referencing related issue numbers or review systems.
3. Standardized format (some projects use type labels).
4. Differences in type labels. Some use square brackets for the type, colons for separating the module from the description, and slashes to split the module and subsystem identifiers.
5. Signatures to indicate responsibility, especially in open-source projects.

If you’ve modified and committed many files and only write fix login.py, it will be very difficult to trace and maintain. You should explain the reasons properly, depending on what kind of developer you want to be.

• Ubuntu/OpenSSH 2b1ac6

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

sshd-socket-generator: do not parse server match config

In order to parse the match config, a connection test specification
needs to be passed. Right now, if a Match directive is used in the
config, the generator fails because no connection test specification is
provided. However, there is actually no reason to parse the match config
at generator time: the Match config is used to modify certain config
options on a per-connection basis. But, we are only concerned with
listening addresses in the generator. Just drop the offending code.

(LP: #2076023)

• apple/ml-stable-diffusion 5d5f15

1
2
3

Add diffusionkit into setup.py

Adds diffusionkit to package installation dependency to avoid erroring out when converting UNet.

• apple/ml-stable-diffusion cf4e1e

1
2
3

Update README.md

Correct wording.

• facebook/facebook-ios-sdk 21b018

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

Configure IAP Observation Time From Server

Summary:
The IAP observation time refers to how frequently we check a user's transaction history for new transactions in nanoseconds. The default is 3600000000000 nanoseconds or 1 hour. In D63005744, we updated the app events config API to include the ```ios_iap_observation_time```.

This diff updates the app events configuration on the client-side to read and store this value. We then set the IAP observation time based on the cached app events configuration.

Reviewed By: jjiang10

Differential Revision: D63052228

fbshipit-source-id: 0535f88e148da197cf1178653c19c753d7f20c54

• facebook/react 23cd3a

1
2
3
4

[rcr] Remove runtimeModule compiler option (#31145)

Now that the compiler always injects `react-compiler-runtime`, this
option is unnecessary.

• AdGuardHome af0f43

1
2
3
4
5
6

chore: update Google DNS list

Add 3 new domains that appear in https://www.google.com/supported_domains but not in this list.
For the technically minded, generate your own list with:
curl -fsSL https://www.google.com/supported_domains | sort | sed -E 's%^(.*)$%|www\1^$dnsrewrite=NOERROR;CNAME;forcesafesearch.google.com%'
:-)

• Tailscale 9a7346

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

types/lazy: add DeferredInit type

It is sometimes necessary to defer initialization steps until the first actual usage
or until certain prerequisites have been met. For example, policy setting and
policy source registration should not occur during package initialization.
Instead, they should be deferred until the syspolicy package is actually used.
Additionally, any errors should be properly handled and reported, rather than
causing a panic within the package's init function.

In this PR, we add DeferredInit, to facilitate the registration and invocation
of deferred initialization functions.

Updates #12687

Signed-off-by: Nick Hill <mykola.khyl@gmail.com>

⭐ Using GPT to Quickly Generate Commit Messages

Once we’re familiar with standardized commit messages, we can apply this in practice, using GPT to automate the process. Here’s how to automate this with Git and VS Code.

First, stage your code changes in VS Code.

Next, open the terminal below and enter the following command to generate the diff log of the staged files and pipe the result directly into the VS Code editor.

1

git diff --cached | code -

You can also add some prompt text to quickly copy and paste into GPT for generating commit messages.

For Windows with prompt:

1

cmd /c "(echo Refer to the previous output: & git log -n 5 --name-only & echo. & echo No need for unnecessary words, here is the diff content, generate a commit message that adheres to git conventions: & git diff --cached) | code -"

For Linux with prompt:

1
2
3
4
5

# Simple prompt
{ echo "Write a concise Git commit message based on the following diff:"; git diff --cached; } | code -

# Referencing previous output
{ echo "Refer to previous output:"; git log -n 5 --name-only; echo ""; echo "Write a concise Git commit message based on the following diff:"; git diff --cached; } | code -

VS Code will open a new window with the prompt and diff content. You can copy and paste this into GPT to generate a standardized commit message.

A GPT input example—here I write a more detailed prompt for consistent results:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Please help me write a Git commit message that follows these rules: The title should follow this format: <type>(<scope>): <subject> where the type is selected from feat, fix, docs, style, refactor, test, chore, ci, build, hotfix, perf. The scope indicates the affected area, such as database, controller, template, etc. The subject is a brief summary of the commit, under 50 characters, in the imperative mood, and without a period. In the body: Explain the details of the change, mainly answering "why" and the reason behind the change, with each line under 72 characters. Include motivation for the change and compare with previous behavior. If it's a breaking change, start with "BREAKING CHANGE: <description>", explaining the reason for the change and providing migration instructions. Please write the Git commit message based on the following changes, skipping irrelevant chatter and going straight to the point. Use markdown code format for the output.

diff --git a/source/j1939/J1939_lib.c b/source/j1939/J1939_lib.c
index 704c318..463f8c0 100644
--- a/source/j1939/J1939_lib.c
+++ b/source/j1939/J1939_lib.c
@@ -125,7 +125,7 @@ uint32_t J1939_Send_Data(uint8_t priority, uint32_t PGN, uint8_t SA, uint8_t *da
         j1939_1.this_ecu_tp_cm.control_byte = CONTROL_BYTE_TP_CM_BAM;
     }
     // 設置傳輸協議連接管理（TP.CM）
-    j1939_1.this_ecu_tp_cm.number_of_packages_beging_transmitted = (data_length + 7) / 8; /* Rounding up */
+    j1939_1.this_ecu_tp_cm.number_of_packages_beging_transmitted = (data_length / 7) + ((data_length % 7) != 0); /* Rounding up */
     j1939_1.this_ecu_tp_cm.PGN_of_the_packeted_message = PGN;
 
     // 傳送 TP.CM（優先權固定為 6）

GPT might generate the following commit message based on the above content:

1
2
3
4
5

fix(j1939): correct TP.CM package calculation logic

Adjust rounding logic from `(data_length + 7) / 8` to 
`(data_length / 7) + ((data_length % 7) != 0)` for accurate package 
counting.

By using this method, we can quickly generate submissions that meet the standards, ensuring the quality of the submission.

Avoid Using Gitmoji

In the past, I used Gitmoji, and these visually appealing emojis did add some fun to otherwise tedious commit messages.

However, I encountered errors when converting commits to patches and applying those patches internally. I don’t recall the exact reason, but it was likely due to the symbols at the beginning of the commit messages (such as colons), which caused older versions of Git to fail during the apply process. Therefore, Gitmoji poses compatibility issues, and its use is not highly recommended.

Additionally, Gitmoji lacks consistent guidelines. Your interpretation of an emoji may differ from mine, leading to potential misunderstandings. For example:

1. 🐛 is typically used for bug fixes, while 🚑️ is used for urgent bug fixes, but the distinction between them is unclear.
2. 🔥 is for code removal. If a bug 🐛 causes compilation failure and removing the code solves the problem, should you use 🔥 or 🐛?
3. 🔒️ represents security fixes. If the security issue is essentially caused by a bug 🐛, which one should you choose?

These are just a few of the concerns that arise when using Gitmoji, and there are many other potential confusions that I won’t list here.

It is clear that writing concise and well-structured commit messages is far more effective in conveying precise information and intent than using an emoji that might not resonate with others.

Moreover, by adhering to standardized commit message structures with clear type and scope, it becomes easier to convey the nature of the changes and the parts of the project being affected.

Conclusion

Writing clear and standardized Git commit messages is essential for code traceability, version control, and teamwork. Good commit messages help developers quickly understand the changes and reduce maintenance difficulties. Using tools like GPT can help generate high-quality commit messages quickly, improving development efficiency and maintaining consistency in version control.

This article also provides examples of commit messages from various open-source projects, showcasing stylistic differences between developers. However, the overarching rules remain the same: specific types, clear and concise titles, detailed descriptions when needed, and references to relevant issues or identifiers for quick tracking.

At the same time, it’s best to avoid over-reliance on emoji-based commit messages (such as Gitmoji) to ensure compatibility and readability across different environments. Following good commit practices and standards promotes team collaboration and ensures the long-term stability of the codebase.

Effectively utilizing these tools and standards will help streamline the development process, ensuring that each change is correctly understood and managed, ultimately improving overall development quality.

References

1. Git - Contributing to a Project
2. Conventional Commits
3. Commit Message Guide  |  Blockly  |  Google for Developers
4. Git Commit Messages: 50/72 Formatting