Software Developer, JRPG Player - CTO at SourceLevel.io
Every software has best practices. Git is not different. It has become the most used versioning system in the last years. Many companies adopted git because of its features. If you wonder why git is so powerful, here are some of the advantages over other versioning systems, like Subversion:
Git popularity over the years
Due to the fact git is meant to work in a decentralized way, it’s a bit more complicated. However, once you understand how git works, it’s crucial to follow good practices. Otherwise, it’s easy to make a mess or misuse it.
Remember, with great power comes great responsibilities. That’s why adopting best practices is crucial. Here’s a list of 7 git best practices you can start using in your next commit.
One of the features of decentralization is cheap branching. Pushing code straight to the
branch doesn’t promote collaboration. Git made simple comparing code between two branches, which can ignite healthy discussions, improve codebase quality, and spread the knowledge among developers. This practice has the name of Code Review.
To create a branch, run
. The command
git branch -b <branch_name>
lists all the available branches, and you can navigate among them using
git branch -a
. A cool trick is to use
git checkout <branch_name>
to switch back to the previous branch.
git checkout -
You should at least set your name and email address correctly. As commits are communications tools, knowing who made a specific change can help you in the future.
to list line by line:
git blame <file_name>
Don’t use it to blame someone, though. It won’t solve any problem. Therefore, you can ask the author about business contexts or technical motivations around that line of code. It may accelerate a bug fix, or trace from which commit that bug is present in the codebase.
As stated before, commits are communication tools. So, take your time to write a descriptive and meaningful commit message. Your future self and your team workers will thank you a lot.
Through the command
, you can navigate through codebase’s history. They should tell you a story. Committing vague and abstract messages like “Bugfix”, or “Refactoring auth” may be a problem sooner than you think.
I enjoy writing a headline for the commit in the first line. Then, like it is an article, I would write essential pieces of information. I strongly recommend Chris Beams’s article on how to write a git message.
Do you know what S from SOLID stands for? Yeah, Single Responsibility Principle. You can apply this principle for commits, not only to the code. You should commit the least amount of lines that make sense together.
This practice helps when digging into the codebase, like when using
One of the magic tricks git performs is the ability to rewrite log history. You can do it in many ways, but
is the one I most use. With this command, It’s possible to switch commits order, remove a commit, squash two or more commits, or edit, for instance.
git rebase -i
It’s particularly useful to run it before opening a pull request. It allows developers to “clean up” the mess and organize commits before submitting to review. If you follow the practice 3 and 4, then the list of commits should look very similar to a task list. It should reveal the rationale you had, telling the story of how you end up with that final code.
However, using git rebase in published branches, like the
, may generate lots of conflicts for the other contributors, which wastes lots of work can and hours of debugging when rebasing is frequent.
When you rewrite the history, you need to push with
. To prevent a disaster, I always make sure to explicit the target branch. It avoids rewriting incorrect target branch’s history and an unnecessary headache to recover it. Do it to any published branches. Don’t hesitate to do it in your local branch, though.
git push --force
It’s crucial always to keep your branch rebase with the latest code. Writing new code upon obsolete one is useless. It is as meaningless as fixing a bug that may already be fixed.
You should rebase your working branch frequently to prevent bugs, rework, and the tedious job of resolving conflicts with the upstream branch. You can do it easily by running these commands:
git checkout <upstream_branch>
git checkout -
git rebase <upstream_branch>
A cool trick is using
. It doesn’t require you to checkout to the upstream branch to update it. I love it.
git fetch --prune
As I said, git is powerful. There are tons of commands. You can learn new tricks reading git docs on the web or using the man pages. By running
, you can check the most useful ones.
git help -a
Here is a list of the ones I use very often:
The list of 7 git best practices is not definitive. However, I think it’s very comprehensive and doesn’t depend on anyone else to adopt them. You can apply them immediately in your next commit.
I hope you enjoyed the content. Thanks for reading.
Previously published at https://sourcelevel.io/blog/7-git-best-practices-to-start-using-in-your-next-commit
Level up your reading game by joining Hacker Noon now!