Table of Contents
In the wonderful computing world of software or web development, one of the must-haves of every developer working on a project would be version controlling. Version control systems are very popular, with one major one being Git. It provides an efficient way for developers to track changes and go back to previous states and work in a team on your projects. However, as its working is only proven effective if the commits are managed properly, it does not work in isolation. In this post, we will go through those good and bad commits, explaining best practices for a clear, descriptive, and useful commit history.
What is a git commit?
Basically, a Git commit is a reference to your code at one point in time. It changes the recording with metadata, which includes an author, timestamp, and commit message. They are used to save progress, say what changes one has made, and merge developed pieces with others’ work.
Bad Practices Vs Best Practices
Single Statement
A commit shall be mono states. In other words, it has to represent one and only one logical change. Do not mix multiple independent changes in one commit.
Best Practices 👍
git commit -m "add user crud"Wrong Practices 👎
git commit -m "add user authentication and fixed dashboard"Descriptive Commit Message
It should clearly describe what a commit does and why the change was made, providing enough context for others (and your future self) to understand without reading the code.
Best Practices 👍
git commit -m "fixed Navbar buttons responsive font size"Wrong Practices 👎
git commit -m "fixed navbar"Read also : Write Effective Css Media Query
Conventional Commit
You can use the standard commit guidelines to clean up your Git history and make it consistent and a pleasure to read. They mostly boil down to interpretations in the form of type (feat, fix, chore, refactor, docs), and short summary, plus occasionally a long explanation or REF to other relative issues.
git commit -m "feat(auth): added JWT-based api authentication"
git commit -m "fix(login): resolved race condition in login steps"Test The Code
In the development phase as developer if you do testing, verification, and proper execution of code changes. That is key to become successful software developer. By integrating these practices into your workflow, you not only ensure code quality and reliability but also contribute to meeting project deadlines and delivering value to your project.
Other Tips
Commit Often, but Not Too Often:
- Basically, the frequency of committing should be such that it creates a balance between doing it too much and not enough. Every commit should have meaningful changes. Never push unrelated changes in a single commit.
- Commit messages describe what the commit does and why you made the change.
- Every new feature, bug fixing, and experiments need to be put in feature branches. Raise Pull Requests for those branches, and the project manager or admin will review your code and merge it into the main branch.
- A project owner, leader, admin, or whoever is going through the code can review and squash small or fixup commits into units of logic before merging a branch. This will keep the history linear of commits.
- Continuous integration tools test your code automatically with every commit to make sure your changes are verified and risk-free from bugs.
- Install Husky It’s a library, and using one such as Husky improves your Git skills. If the rules configured in husky are violated, it won’t let commit.
