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
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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)
Do you mean "Git commits"? Not sure why you're referencing GitHub every time
Yes, those are general tips for Git, not specifically GitHub.
I updated the article with the fixes :)
You forgot the donts:)
Just added them, thanks :)
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?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":
Squashing commits at the end of a PR >>> git rebase dark magic