Git Commits - Tips for organised Commit Structures

Git is the most famous SCM (Source Control Management). It’s an amazing and powerful tool for versioning code. In this post, we’ll is to explain how to keep your commit messages organised.

 Introduction

Following the best practices of Git, you need to keep a history of your application so that when a developer submits a Pull Request for the team to evaluate, besides the readable, testable and maintainable code, there’s also organised the commit messages. Nowadays it’s not rare you see developers writing unreadable message just to finish a task quickly. The problem with this is that when you want to write a release note document or track all change logs for a specific release it become an almost impossible task.

Here is a scenario when the development team doesn’t take the time and attention to have organised commit messages:

```sh

73cbe7d7 (HEAD -> develop) done

e4e300b1 finally I finished it

9d46227b clean up

c2242ce6 fix an issue

```

Looking at the log message above, it is impossible to track what happened and any changes that were made. That’s why it’s important for organised teams to have standards when it comes to writing commit messages. One option is to use conventional commits (https://www.conventionalcommits.org/en/v1.0.0). It’s the most popular and standard way to write commit messages and the result is clear for whoever reads the logs:

```sh

73cbe7d7 (HEAD -> develop) docs: update readme file

e4e300b1 style(home): change color for header

9d46227b chore: update jest tool version

c2242ce6 fix(signup): adjust signup validation

```

Commits structure

Basically, a commit message follows a simple structure: <commit_type>(<context>): <message>

commit_type: uses predefined words to specify what kind of change was done. Here is a short list of the most common terminology:

• fix: used for identifying fixed  errors or solved bugs

• chore: doesn’t have any impact in the application and is more related to CI and CD or any changes that will keep the application working

• docs: used for any update in the documentation

• refactor: used for refactoring some part of the code

• test: related to writing or updated tests

context: used to specify where the changes was applied. It is not required but it makes it easier to know where changes were made.

message: is the message describing what was done.

Squash Process

Squash is a process to merge multiple commits in one single commit. It’s a way to simplify and remove useless messages. For example, it’s common for a developer to have more than one commit within the same message which can look like something like this:

```sh

73cbe7d7 (HEAD -> develop) fix: adjust header

e4e300b1 fix: adjust header

e4e300b1 fix: adjust header

```

 There’s nothing wrong with this, but when you open the Pull Request to keep the commit messages organised, you can use the command git rebase -i HEAD~<number of commits>. This command will show a list of commits that you want to squash, drop, reword and select, in order to unify everything and help your team evaluate and understand your work and any changes you’ve made.

Conclusion

Git is an excellent and very powerful tool, but as developers it’s important to understand how to use git or any SCM more than git pull/push. It makes your work more professional and improves your work environment. Keep in mind that this should become another step in your workflow so that your whole team can gain from this improvement. Because you can see what was done, you can provide a release note and show your customer and managers what is being launched.

Writen by Lucas Rodrigues