如何做一份干净的Git提交记录
背景
毕业工作有一些年头了,之前在写工作代码或者给开源项目贡献的时候,提交代码都不是很规范,甚至可以说十分的随意,想到什么就提交什么,根本没有管理提交记录的概念或者想法(当你身边的人都不怎么在意的时候,你也很难在意的)。工作了一段时间之后,对代码提交规范的要求高了不少,因为我发现,当我把这件事情做好的时候,会让工作变得顺畅一些。有一天解决倒腾git解决了一些问题,就想到把这些东西沉淀下来,分享出去。所以写下了这篇文章。倒也不是多么高大上的代码技巧或者炫技,只是分享之前遇到的一些git commit问题,和分享一些见解。
cases and thoughts
1. 处理业务开发代码和测试联调代码
想象一下这样一个场景:有一个需求开发完了,准备和其他同事联调这个需求。谨慎起见,联调期间希望可以观测到这个需求运行过程中的大部分细节。比如上下游的输入输出是什么样的,运行到某段代码他的表现应该是什么样的。如果没有测试到位,就上线了,一不小心造成了什么事故,问题可就大了。另外,如果在测试过程中遇到了肉眼看不出来的bug,这时候也需要打一些日志去分析。
这个时候问题就来了,调试日志代码一般情况下是不能上线的,毕竟一个系统在关键的地方打上日志方便线上排查bug就好,到处打日志估计服务器也很难顶得住。这个时候怎么办呢?我会通过下面的例子来演示下面解决的方法。
首先我们假设有一个仓库。叫做git-experiment.并且当前有一个提交,是一个名为Feature-1的需求的相关开发改动。通过查看git提交日志我们可以看到:
下面让我们看看具体怎么解决这个问题。
1.1 直接在这个分支上写,merge进master之前去掉这些提交记录
第一个做法其实比较好理解,就直接在原来的分支上加嘛,测试完了把这些关于测试的提交记录去掉就好。下面这幅图模拟的情景是:
- 加上了打印log逻辑。
- 在测试中发现了问题,又添加了一个commit来修复这个bug。
测试结束,这个时候我们看到上面这样一份提交记录,应该怎么办呢,用git revert?是不太行的喔,因为revert会生成一个新的提交记录。像下面这样子。
这样子虽然代码没了,但是这份提交记录看起来就会很奇怪。很明显,在这个场景中,我们实际上只需要关于Feature-1代码改动和关于bug fix的代码改动。这个时候推荐用git rebase。比如在上面这个case中,可以运行:
git rebase -i HEAD~2
这时候我们将看到下面这个景象,这些你挑选好的commit会倒序排列在你面前让你操作。
d代表要放弃这个commit,pick代表保留。确认好你的操作之后退出。可能会遇到代码冲突,解决冲突之后可以执行git rebase --continue。完事之后我们可以看到。
Perfect,这就是我们想要的。但是,这个方法的缺点就是在原来的分支上引入了新的不确定性,并且在去除日志代码的时候,最好期待没有冲突出现,如果出现了冲突,一个不小心把业务需求的代码搞掉了,那就美滋滋了。这种做法相当于把所有的风险都集中在一个分支上面。
1.2 切换一个分支,在新分支上写测试相关的代码
这里介绍第二种方法。我们可以在原来的基础上切换出一个新的分支来,专门用来做测试相关的工作,原有的分支专注在业务开发和bug fix。
然后给这个分支加上测试相关的日志打印代码。
这时候可以看一下这个分支上面的提交日志。
这时候我们就可以拿这个分支去部署,然后和别人联调测试了。如果在测试过程中发现了bug,需要修复怎么办?这个好办,在原来的分支上做bug fix,然后测试分支cherry-pick bug fix的commit就好了。让我们来看看。
commit bug fix的代码后,切换到测试分支,cherry pick这个commit。
有冲突解决冲突。弄完之后让我们来看看这个分支的log。
这样你就可以继续用这个分支做bug fix之后的测试啦。这样做的好处就是,你的开发分支始终是安全且干净的。冲突都在测试分支解决。
2. 让每一个commit都有意义
相信大家都听过这样的一句话,"代码是写给人看的,其次它能在电脑上跑起来。"。无论是工作还是开源项目。如果你写的代码会给别人仔细的review,那么让别人知道你的代码代表什么,要做什么,就显得尤为关键。不要因为做这个需要时间就不去做,如果别人没看懂你的commit或者需要你修改一下commit信息,这些现在省下来的时间后面还是会还回去的。就比如上面这个例子的最终状态是这样的:
实际上,我个人认为这两个commit应该合并成一个,其实看代码的人看到这个bug fix的commit还会好奇这个提交的上下文是什么,可能脑海里会涌现出这样一个问题:bug是什么?不要让别人想太多,如果他很困惑,他就会来问你。最好可以通过commit信息告诉他你做了什么。
说到这里你就会想了,我把所有代码都弄成一个commit,再给上比较好的commit信息是不是就好了。看情况吧,如果一个需求你写了好多代码,上千行这样子。这时候我认为应该拆分一下commit,比如这个时候你可以拆分成好几个小的commit,再分别给提供commit信息。看代码的人可以通过你的commit信息拆解你的需求,细分到每一个小需求去审视你的代码,这也节约了他人的时间。
总结
上面是在我在工作中遇到的一些关于代码提交的问题和想法, 在这里分享给到大家。希望对大家有所帮助。
来源:juejin.cn/post/7255967761804951589