In the amazing world of software or web development, version controlling is one must-have in every... Tagged with git, github, webdev, beginners.

Dev.to is a community platform for developers, offering resources, discussions, and networking opportunities to empower individuals in their coding journey. Developers can learn new programming languages, frameworks, and tools, engage in discussions on best practices, and share their experiences with fellow developers to enhance their skills and grow their professional network.

Good commits are crucial for maintaining a clean and understandable project history in Git. Characteristics of good commits include being atomic and focused, having descriptive messages, following conventional guidelines, being tested and verified, and being properly scoped. Conversely, bad commits are large and unfocused, have vague or misleading messages, combine unrelated changes, and contain incomplete or untested code. Best practices for good commits involve committing often but meaningfully, writing clear messages, using branches effectively, reviewing and squashing commits, and automating testing.

Good Commit ✔ VS. Bad Commit ❌: Best Practices for Git

Gradually i think we won’t need write message for your commit, it should be generated.
If you need, then just stash it on your local.

Honestly… if you work with pull requests, squash and merge then commit messages don’t really matter.

I disagree with the content of the article. From my perspective, it is pretty easy to see what has been added or changed, so repeating it in a more summarized way in the commit message is a no go for me. The most useful tip about commit messages is:
write WHY it was changed instead of WHAT was changed
It provides more information on the top of the code changes that we see.

My Git history is basically a diary of my emotional state while coding.

<h1>Good Practices for Writing Commit Messages</h1>
A good commit message should be clear, concise, and descriptive.
<h3>Summary</h3>
<ol>
<li>Use the Imperative Mood: Command-like statements.</li>
<li>Be Descriptive: Clearly describe what and why.</li>
<li>Keep it Short and Concise: Aim for under 50 characters.</li>
<li>Use Multi-line Messages: Provide more context if necessary.</li>
<li>Reference Issues/PRs: Link to relevant issues or PRs.</li>
<li>Avoid Unrelated Changes: Focus on a single purpose per commit.</li>
</ol>
<h3>Examples</h3>
<ul>
<li>
Use the Imperative Mood
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Fix null pointer exception in user login&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Fixed a bug&quot;
</code></pre>
</li>
</ul>
</li>
<li>
Be Descriptive
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Add input validation for user registration form&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Update form&quot;
</code></pre>
</li>
</ul>
</li>
<li>
Keep it Short and Concise
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Improve performance of data processing algorithm&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Made some changes to improve the speed of the data processing by optimizing the algorithm and reducing the overhead&quot;
</code></pre>
</li>
</ul>
</li>
<li>
Use Multi-line Messages for More Context
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Refactor authentication module

Improve code readability and maintainability by refactoring the authentication module. Extracted redundant code into helper functions and updated documentation.&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Refactor code&quot;
</code></pre>
</li>
</ul>
</li>
<li>
Reference Issues and Pull Requests
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Fix user profile loading issue (#123)&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Fix issue&quot;
</code></pre>
</li>
</ul>
</li>
<li>
Avoid Committing Unrelated Changes
<ul>
<li>Good Example:<pre><code class="language-sh">git commit -m &quot;Add user avatar upload functionality&quot;
</code></pre>
Separate commit:<pre><code class="language-sh">git commit -m &quot;Update user profile layout&quot;
</code></pre>
</li>
<li>Bad Example:<pre><code class="language-sh">git commit -m &quot;Add avatar upload and update profile layout&quot;
</code></pre>
</li>
</ul>
</li>
</ul>
<h1>Overall this is a good blog so kudos! 👏</h1>
Here are some reference links
<ul>
<li><a href="https://www.freecodecamp.org/news/how-to-use-git-best-practices-for-beginners/" target="_blank" rel="noopener nofollow">Best Place to learn about git</a></li>
<li><a href="https://about.gitlab.com/topics/version-control/version-control-best-practices/" target="_blank" rel="noopener nofollow">Best Practices for Version Control</a></li>
<li><a href="https://sourcelevel.io/blog/7-git-best-practices-to-start-using-in-your-next-commit" target="_blank" rel="noopener nofollow">Similar Blog</a></li>
<li><a href="https://www.geeksforgeeks.org/best-git-practices-to-follow-in-teams/" target="_blank" rel="noopener nofollow">Best Practices to follow in a team</a></li>
</ul>