DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Omer Elbaz
Omer Elbaz

Posted on

The Dos and Don'ts of Creating Good Git Commits

The Importance of Good Git Commits

There are several reasons why good commits are important. First, commits are used to track changes to a project. This is especially important when working on a team, as it allows everyone to see what changes have been made and who made them. Good commits should be clear and concise so that they are easy to understand. Second, commits should be atomic, meaning that each commit should only contain one change. This makes it easier to revert changes if necessary. Finally, good commits should be made regularly so that the project history is easy to follow.

The Dos of Creating Good Git Commits

  1. Write clear, concise, and meaningful commit messages. This means that your commit message should be able to stand on its own and explain what changes were made in the commit. A good commit message should also be descriptive enough that someone looking through the commit history will be able to understand what happened in each commit.
  2. Group related changes together in a single commit. This will help keep your commits small and manageable. It also makes it easier to revert changes if necessary, since you can simply revert a single commit instead of having to revert multiple commits.
  3. Test your changes before committing them. This helps ensure that your changes actually work and don’t introduce any new bugs. It also allows you to catch any potential problems early on so that they can be fixed before they cause more serious issues.
  4. Make sure your commits are atomic. This means that each commit should contain a single, self-contained change. This makes it easier to revert individual changes if necessary, and it also helps keep your commits small and manageable.
  5. Use Git’s interactive rebase feature to squash commits and clean up your commit history. This allows you to combine multiple small commits into a single larger commit, which can make your commit history much cleaner and easier to understand.

The Don'ts of Creating Good Git Commits

  1. Make sure you're not committing any secrets. A secret is something that should not be publicly available, like authorization credentials (usernames, passwords, tokens, API keys etc.), environment variables or anything else you don't want other people to have access to.
  2. Make sure you don't commit any unwanted files, like OS specific files (e.g Thumbs.db on Windows and .DS_Store on macOS), or any IDE specific files (e.g .vscode on Visual Studio Code).

So, in summary, remember to keep your commit messages clear, concise, and meaningful. And avoid making unnecessary commits just for the sake of β€œbumping” the history. By following these simple guidelines, you can ensure that your Git commits are helpful and informative for both yourself and others.

Assuming you followed the dos and avoided the don'ts, you should now have good GitHub commits! Don't worry about doint all of these things right away, these are just recommendations and best-practices that may help you and your team, not strict rules or requirements.
Thanks for reading and good luck!

Star our Github repo and join the discussion in our Discord channel to help us make the BLST website the best it can be!
Test your API for free now at BLST!

Top comments (7)

Collapse
jonrandy profile image
Jon Randy

Do you mean "Git commits"? Not sure why you're referencing GitHub every time

Collapse
omerwow profile image
Omer Elbaz Author

Yes, those are general tips for Git, not specifically GitHub.
I updated the article with the fixes :)

Collapse
moonseeker profile image
Moon Seeker

You forgot the donts:)

Collapse
omerwow profile image
Omer Elbaz Author

Just added them, thanks :)

Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

There Is More Than One Way To Do It as the Perl guys say.

You describe how to do it when the commit is the unit of work.

I prefer the GitHub way where the Pull Request is the unit of work.

You still should strive for doing small focused pull requests

However the individual commits inside them don't matter much. I'm doing pr: handle comments commits all the time. When the PR gets approved, we just squash the whole thing so who cares?

Collapse
joelbonetr profile image
JoelBonetR • Edited on

Points 2 and 4 are contradictory. You either group changes in a commit or make atomic commits. Both at the same time are not possible.

About the rebase thingy you should take care with that, let me explain:

You should avoid doing Rebase on a branch that is shared. i.e. if you are not alone working on that branch and the branch exists remotely as well as locally, rebasing is not a good choice as it can cause bubble commits. Also you should not do Rebase on pushed commits, i.e. If you are working on a branch and you already pushed some commits to this branch on remote/origin.

You can find a good explanation in the ProGit Book, section titled "The Perils of Rebasing":

When you rebase stuff, you’re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours.
Collapse
jmfayard profile image
Jean-Michel Fayard πŸ‡«πŸ‡·πŸ‡©πŸ‡ͺπŸ‡¬πŸ‡§πŸ‡ͺπŸ‡ΈπŸ‡¨πŸ‡΄

Squashing commits at the end of a PR >>> git rebase dark magic

🌚 Life is too short to browse without dark mode