Using Git in your projects is a good solution regardless of whether the subject is front-end or back-end. However, as with any good tool, Git offers a huge number of options and features that can be used well or badly.
With that in mind, we created this post with 6 Git best practices so you can learn more about the subject. Check it out!
1. Use the imperative mood
By convention, Git always uses the imperative mood in its message patterns. That means when you use a merge or a revert, those actions follow that command form, and for that reason, when writing commit subjects, it is useful to follow the same rule.
A good tip to make commit creation easier is to validate them using the phrase “If applied, this commit will”. See an example below:
$ git log --oneline -4
d759236 Change config to upload
ae6a172 Merge branch "assync-spam-job" into "master"
ef10959 Disable worker for spam learn.
4210b8c Merge branch "sentry-error-spam" into "master"
In this case, the phrase would be: “If applied, this commit will Change config to upload”. At first, it may seem harder to write commits this way because it is less usual. However, after a short time, the action becomes much easier.
2. Be direct and explanatory in your commits
It is really faster to make a commit using the syntax “git commit -m” and passing a brief message about what was done. However, this rule causes you to lose the original idea of the commit, which is to be a page in the history of your project, not just a one-line summary.
In that case, your commit would look like this:
git commit -m “Adjust images on upload”
With this message, a reader cannot understand why the change was made. Try to summarize what was done in the first line with some detail, then skip a line and describe exactly what was done, if possible including a link or reference to the task that started the change.
Example:
git commit -m "Applying auto-adjust images on upload to avoid distorting"
Users was uploading images to their profile but it was distorting the pics, now the pics are auto-adjusting.
This way, in addition to making your action more complete, it is still possible to create a summary and a body for your commit without making the Git history harder to read.
3. Consider including the link to your story card in the commit
Including the card link in the commit makes it easier to find a more complete reference for the reasons behind that story. This also makes it possible to show examples and, if needed, important technical details.
4. Limit the commit subject to 50 characters
The number 50 is a baseline so the subject can be read in full in any interface. However, this rule does not need to be followed to the letter.
Consider following a standard between items 2 and 3: use the first 50 characters for a summary of what was done and that will be visible in any interface, while the next lines can contain a more detailed message.
5. Capitalize the subject of your commit
Finally, capitalizing the subject of your commit is important so it can be found more easily in searches. See examples below.
Without capitalization:
$ git log --oneline -5
d2cad72 change config app to run
d759236 change config to upload
ae6a172 Merge branch "assync-spam-job" into "master"
ef10959 disable worker for spam learn.
4210b8c Merge branch "sentry-error-spam" into "master"
With capitalization:
$ git log --oneline -5
d2cad72 Change config app to run
d759236 Change Config to upload
ae6a172 Merge branch "assync-spam-job" into "master"
ef10959 Disable worker for spam learn.
4210b8c Merge branch "sentry-error-spam" into "master"
6. Never store binary files in your project
Despite being a very powerful tool, Git was designed for text files, especially to track changes in files such as code.
We usually find tools that make it easy to visualize the project via an image or generated PDF and we are tempted to store that documentation in Git alongside the project. However, these documents are not versioned by Git in the same way as text files, and that can make the project double in size with each update to those files.
So be careful and prefer passing guidance through a README, avoiding storing these documents in the project itself.
So, did you like the Git best practices we shared in this post? Do you have any questions or would you like to share your opinion? Then leave a comment!
Originally published on the Blog Locaweb.