Frequent code commits can be tedious but essential. Hence, it is vital to communicate the intent of changes effectively, so that team members looking at your code review understand the implications of those changes and review them adequately. These practices ultimately save time and improve communication in teams.
Here are some of the design principles and guidelines that I have used to improve my workflow. I use them as a guiding light to ensure that any change to the existing commit workflow is effective and efficient. I am using Git as the version control system. However, these principles can be applied to any other version control tool.
Design Principles
It is essential to follow some design principles so that you can decide when a change introduced is reasonable as compared to over-engineering or under-engineering. It enables you to check the return on investment of the change.
I want to use the same git workflow as much as possible, on different projects
My pull requests should be easy to review and debug
Have an easy way to set up my workflow and configure
The commit message should communicate the intent of the change and not what the code does.
Suggestions
Use git diff --check, which identifies any possible whitespace errors and lists them for you. You can add it as a git hook.
Commit messages should be around 50 to 60 characters long, at max, similar to how one limits 120 characters per line when writing code.
Make separate commits for logically separate changes.
Use imperative tone for your commit messages. Example: Make IndexController check for token over Made changes to ensure IndexController checks for the token. It is more concise, and the intent of the change is understood right away.
Use the .gitconfig file to set up the required info. It will make the commit more readable and secure. This depends on the use case, here are some examples that would live in the .gitconfig: – GPG signature, – Author info.
