Skip to content

Commit 4c9c214

Browse files
authored
Writing clear and meaningful Git commit messages
1 parent 621369f commit 4c9c214

File tree

1 file changed

+77
-0
lines changed

1 file changed

+77
-0
lines changed

_posts/2023-05-20-mediaengagement-technical-docs.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -753,6 +753,83 @@ $ git push origin master // push merge changes
753753
$ git push origin :hotfix-id // deletes the remote branch
754754
```
755755

756+
Writing clear and meaningful Git commit messages is an essential practice for maintaining a well-organized codebase. Here are some best practices to help you create effective Git commit messages:
757+
758+
## Git Commit Messages
759+
760+
Writing good Git commit messages improves collaboration, code tracking, and future maintainability. Following these best practices ensures that your messages are informative, concise, and provide meaningful context for your changes.
761+
762+
### 1. **Use the Imperative Mood**
763+
- Write your commit message as though you're giving a command. For example, use "Fix bug" instead of "Fixed bug" or "Fixes bug."
764+
- **Why?** The imperative mood is consistent with the way Git messages are structured (e.g., “merge branch” or “revert changes”), and it helps describe what the commit will do when applied.
765+
- **Example**:
766+
```
767+
Add feature to handle user authentication
768+
```
769+
770+
### 2. **Keep Messages Brief and Descriptive**
771+
- Keep the subject line (the first line of the commit message) under 50 characters. This ensures the message is easy to read and fits well in Git logs.
772+
- Be concise but make sure it clearly explains **what** the change is about.
773+
- **Example**:
774+
```
775+
Update navbar style to improve mobile experience
776+
```
777+
778+
### 3. **Use a Blank Line Between Subject and Body**
779+
- If you need to add more details, leave the first line for the summary, add a blank line, and then expand on the change in the body.
780+
- **Example**:
781+
```
782+
Refactor user authentication module
783+
784+
Reorganized the code to simplify login flow and enhance session management. Improved error handling and reduced duplication in the logic.
785+
```
786+
787+
### 4. **Explain the “Why” in the Body**
788+
- The body should explain **why** the changes were made and provide any additional context that will help future developers (or yourself) understand the reasoning behind the commit.
789+
- Avoid restating the "what" (already captured in the subject), and instead, focus on the "why" or "how."
790+
- **Example**:
791+
```
792+
Add caching for API responses
793+
794+
Implemented a caching layer to reduce the load on the external API and improve response times. This should help with scalability during peak traffic.
795+
```
796+
797+
### 5. **Reference Issues or Tickets**
798+
- Reference the relevant issue number to create a link between the commit and the ticket.
799+
- **Example**:
800+
```
801+
Fix issue with user registration validation
802+
803+
Closes #23 by adding validation for email formatting and preventing duplicate registrations.
804+
```
805+
806+
### 6. **Write Meaningful Messages**
807+
- Avoid vague terms like “update,” “fix,” or “change” unless paired with more specific details. The commit message should be understandable even outside the context of the code.
808+
- **Bad Example**: `Fix bug`
809+
- **Good Example**: `Fix null pointer exception in payment gateway`
810+
811+
### 7. **Use Multiple Commits for Logical Changes**
812+
- If you're making multiple unrelated changes, split them into separate commits. This makes it easier to understand and revert specific changes if necessary.
813+
- **Example**:
814+
```
815+
Refactor user controller for readability
816+
Update user email validation logic
817+
```
818+
819+
### 8. **Avoid Capitalizing File Names or Code References**
820+
- The commit message should focus on describing the change, not listing the files or functions affected.
821+
- **Example**:
822+
```
823+
Remove deprecated API endpoints
824+
```
825+
826+
### 9. **Avoid WIP (Work in Progress) Commits**
827+
- Commits should represent a coherent change or feature. Avoid pushing “Work in Progress” commits to the main branch. Use branches to manage WIP code.
828+
- **Example**:
829+
```
830+
Add unit tests for user registration feature
831+
```
832+
756833
# Wordpress
757834
## Hooks and filters
758835

0 commit comments

Comments
 (0)