It's boring to write commit, but even more boring is not knowing where that change happened.
Many of you may have already uploaded at least one commit to a github repository, but as not every junior is committed to open source to take inspiration as they do, maybe you've made commits without any pattern in the message. totally normal.
In my case I also do this from time to time, in the projects I want to commit quickly. Now in a project with several devs it's much easier by the title of your commit to know what it's about, standardizing this first interaction with the new code then becomes a must-have.
Is there an industry standard?
Look, each team chooses how they do it, there are people who use cute icons, there are people who go through the previous projects they worked on, but I use and recommend ConventionalCommits.org, based on that structure you're ready to send code to the whole world.
The structure is very simple, as follows:
[optional scope]: description
Just looking at this cake recipe may seem abstract to some, so let's put it in real examples:
Commit with new feature.
- feat: "Add payment methods to xyzUseCase"
Commit with bug fix.
I've never seen a developer not have doubts about this one, because in our minds we thought it should be like this "fix: "fix the something..." But the proper way would be:
- fix: "Correct the foo class method"
Documentation commit.
- docs: (changes to the documentation)
Another interesting examples.
- style: (formatting, missing semi colons, etc; no production code change)
- refactor: (refactoring production code, eg. renaming a variable)
- test: (adding missing tests, refactoring tests; no production code change)
- chore: (updating grunt tasks etc; no production code change)
That's it for today, I hope you adopt these more organized commits, after automating this routine in your development process, it becomes easier to organize your day-to-day.
Top comments (0)