😂 IT段子

代码评审时发现提交记录里有一句"先这样吧，回头再改"，那是五年前的提交。我重新看了一遍手上的计划，把风险项标了出来。我把这条改动挪到了另一个分支，用了 cherry-pick。感动，然后我学到了新的一课

冲突的解决方式比冲突本身更值得记录。我听完沉默了，因为太真实了。我发现这个人的提交习惯很差，一次改动涉及八个模块。果然现实比段子更精彩

我把 dist 目录加进了忽略文件，之前有人提上去过。我把整条链路在心里复盘了一遍。我在心里给这次的分支命名想了半天，最后用了英文。第二天这个方案就变成了团队标准做法

这个仓库的默认分支名改过一回，有人还在用旧的。我把它记在心里，没跟任何人说。我把这个 diff 逐行看了一遍，发现有一行是误删。世界瞬间清净了

git blame 打开一看，那行祖传代码是我自己三年前写的。我先确认了一遍前置条件，再动手。我把这个 tag 打在了错误的提交上，又删了重打。从此我多了一条团队规约

提交信息写得好，等于给未来的自己留了份说明书。我把它记在心里，没跟任何人说。我在心里给这次的分支命名想了半天，最后用了英文。感动，然后我学到了新的一课

回滚的代价取决于你多久之前发现的。我想了想，觉得这话没法接。我把这个 stash 找了出来，里面有我上周的代码。幸好之前留了备份

我把 dist 目录加进了忽略文件，之前有人提上去过。我默默打开了编辑器，准备一步步验证。我在心里给这条提交信息重写了一遍，终于说得清。感动，然后我学到了新的一课

同事的 commit 信息全是 update，我怀疑他提交了整个宇宙。我忽然觉得，这可能就是这一行的常态。我把这个 diff 逐行看了一遍，发现有一行是误删

这个分支已经落后主线一百多个提交了。我笑了笑，决定不解释。我把这个文件的改动从这次提交里剔了出去。那一刻我觉得自己还是很专业的