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:
- the distributed model, which promotes collaboration among peers
- how fast it is to generate diff and compare changes in the history
- how easy and cheap is branching and merging
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
master 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
git branch -b <branch_name>. The command
git branch -a lists all the available branches, and you can navigate among them using
git checkout <branch_name>. A cool trick is to use
git checkout - to switch back to the previous branch.
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.
git blame <file_name> to list line by line:
- the last commit that changed it
- the author of the commit
- the timestamp of the commit
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
git log, 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
git log or
One of the magic tricks git performs is the ability to rewrite log history. You can do it in many ways, but
git rebase -i 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.
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
master, 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
git push --force. 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. Avoid doing it to any published branches. Don’t hesitate to do it in your local branch, though.
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
git fetch --prune. It doesn’t require you to checkout to the upstream branch to update it. I love it.
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
git help -a, you can check the most useful ones.
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.
The post 7 Git Best Practices to Start Using in Your Next Commit appeared first on SourceLevel.