You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ git push origin :hotfix-id // deletes the remote branch
754
754
```
755
755
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.
0 commit comments