Make your git commit history clean with three lines of code

Preface

The author has recently been leading the architecture migration work of a project. Due to the heavy historical burden of the migration project and the large number of personnel collaborations, the migration process inevitably involves multiple branches, In the case of multiple commits, as time goes by, the git submission record will become chaotic. Let's just take a graphical git submission history to give everyone a feel.

Various branches fight like crazy in a harem, like concubines competing for favor. The reason for this situation is mainly due to the abuse of the git merge command and the lack of subsequent understanding costs. of. Programmers working in large factories today frequently accept changes. Once they are not considered carefully at the beginning, a large number of meaningless commit logs will inevitably appear. Coupled with the promotion of the "agile" concept, the rapid iteration of products online changes. After becoming the core indicators, these meaningless commit logs were "processed next time" and became chaotic over time.

When we look at some open source warehouses, we will find that their commit records are very neat. In fact, this is not because the programmers in the community are more capable, but because they do not have the whipping of KPI sticks when submitting code. I will spend time organizing my commit log before. And this is the protagonist of this article-"Git Rebase".

git rebase and git merge

git rebase, translated as "rebase" in Chinese, is usually used for branch merging. Since branch merging is mentioned, the git merge command must be indispensable.

I believe that every novice programmer will hear the words "xxx, please merge this branch" when he first enters the workplace. So here’s the problem, if you have 6 programmers working together, you will have 6 programmers’ branches. If you use merge, your code history tree will have six branches intertwined with this main branch. .

The above picture is a flow diagram of the git merge operation. The Merge command will retain the historical time of all commits. Everyone's code submissions are varied. Although these times don't mean anything to the program itself. But the original intention of the merge command is to keep these times from being modified. As a result, a network history structure based on merge time is formed. Each branch will continue to retain its own code records, and only the merge history will be retained on the main branch. Sub-branches may be deleted at any time. After the sub-molecule is deleted, the record you can see is the merge of a certain branch into a certain branch. This historical account is basically meaningless.

And git rebase is translated as "rebase" in Chinese, and this base refers to the baseline. How to understand this benchmark? Let’s take a look at the image below.

We can see that the base branch of the feature branch has changed after rebasing and became the latest master. This is called "rebasing".

It can be clearly seen from the above two pictures that the biggest difference between these two ways of merging branches is that the merged branch will retain the operation records of the two branches, which is in the git commit log tree will be saved in a cross format. The branch after rebase will be based on the latest master branch, so there will be no forks and it will be a clean straight line from beginning to end.

The detailed usage of git rebase and git merge is beyond the scope of this article. For details, you can refer to other information on the Internet.

During the rebase process, we usually need to make commit modifications, and this also provides an option for us to organize git records.

Keep the recent records tidy

Assume we have a warehouse, and I have performed 4 commits in this warehouse. View the commit records through the git reflog command as follows .

If we want to merge the commits of Commit-3, Commit-2 and Commit-1 into one commit (assuming that some pom files were changed in a certain commit), we You can directly execute the following command

git rebase -i HEAD~3

-i refers to --interactive, HEAD~3 refers to the last three commits.

Of course, we can also directly specify the ID of the latest Commit we want to keep. In the above example, it is the ID of Commit-0, so we can also write it as

git rebase -i d2b9b78

After executing this command, we will enter the following interface:

这个界面是一个Vim界面，我们可以在这个界面中查看、编辑变更记录。有关Vim的操作，可以看我之前写的文章和录制的视频《和Vim的初次见面》

在看前三行之前，我们先来看一下第5行的命令加深一下我们对git rebase的认识。

翻译过来就是，将d2b9b78..0e65e22这几个分支变基到d2b9b78这个分支，也就是将Commit-3/2/1/0这几次变更合并到Commit-0上。

回到前面三行，这三行表示的是我们需要操作的三个 Commit，每行最前面的是对该 Commit 操作的 Command。而每个命令指的是什么，命令行里都已经详细的告诉我们了。

• pick：使用该commit
• squash：使用该 Commit，但会被合并到前一个 Commit 当中
• fixup：就像 squash 那样，但会抛弃这个 Commit 的 Commit message

因此我们可以直接改成下面这样

这里使用fixup，而不是squash的主要原因是squash会让你再输入一遍commit的log，图省事的话，可以无脑选择fixup模式。

然后执行:wq退出vim编辑器，我们可以看到控制台已经输出Successful了。

这个时候我们再来看下log 记录，执行git log --oneline

于是最近三次的提交记录就被合并成一条提交记录了。

保持中间某些记录整洁

那如果不是最后的几个commit合并，而是中间连续的几个Commit记录，可以用上述方法整理合并吗？答案是可以的，只不过需要注意一下。

我们重新创建一个新的仓库

如果这次我们想将"third commit"和"second commit"合并为一个提交，其实和上面的方式一样，我们只需执行git rebase -i HEAD~3，然后将中间的提交改成fixup/squash模式即可，如下图所示：

之所以是HEAD~3，是因为我们要做的变更是基于first commit做的，因此我们也可以写成git rebase -i a1f3929

我们来看下更改完的commit log，如下图所示：

是不是就干掉了third commit了。

三行代码让git提交记录保持整洁

上面我们都是在本地的git仓库中进行的commit记录整理，但是在实际的开发过程中，我们基本上都是写完就直接push到远程仓库了，那应该如何让远程的开发分支也保持记录的整洁呢？

第一种做法是在push代码前就做在本地整理好自己的代码，但是这种做法并不适用于那种本地无法部署，需要部署到远程环境才能调试的场景。

这时我们只需要执行git push -f命令，将自己的修改同步到远程分支即可。

-f是force强制的意思，之所以要强制推送是因为本地分支的变更和远程分支出现了分歧，需要用本地的变更覆盖远程的。

而远程分支更新后，如果其他人也在这条分支上更改的话，还需要执行一个git pull命令来同步远程分支。

这里我们来总结下让git提交记录保持整洁的三行代码。

git rebase -i xxx
git push -f
git pull

❗️❗️❗️Tips：由于rebase和push -f是有些危险的操作，因此只建议在自己的分支上执行哦。

推荐学习：《Git视频教程》