😂 IT段子

我在提交前会看一眼改动列表，这个习惯救过我几次。我盯着屏幕沉默了十分钟。我把这个冲突的解决方式记录了下来，下次参照。复盘会上我们把它列成了案例

冲突的解决方式比冲突本身更值得记录。我愣了两秒，然后继续敲代码。我把这个文件的改动从这次提交里剔了出去。那一刻我觉得自己还是很专业的

commit 信息写的是"修复若干问题"，半年后没人知道修的是什么问题。我想了想，觉得这话没法接。我在心里给这条提交信息重写了一遍，终于说得清。感动，然后我学到了新的一课

回滚代码的正确姿势是 revert，错误姿势是删库，我们组两种都见过。我想了想，觉得这话没法接。我把这个改动用 patch 的方式分享给了同事。好在最后有惊无险

stash 了十次，pop 的时候像在拆盲盒。我想了想，觉得这话没法接。我发现这个提交把一个不该动的文件也带上了。这条经验值直接拉满

回滚代码的正确姿势是 revert，错误姿势是删库，我们组两种都见过。我停了一下，然后继续手上的活。我把这个改动用 patch 的方式分享给了同事。从此我多了一条团队规约

git log 拉到底，发现项目的起点是一个叫 init 的提交，里面只有一句"开始吧"。这套流程走下来，我从头到尾又确认了一遍。我在心里给这条提交信息重写了一遍，终于说得清。好在最后有惊无险

这个仓库的默认分支名改过一回，有人还在用旧的。我停了一下，然后继续手上的活。我发现这个仓库的分支已经有八十多个了。这条经验值直接拉满

这个分支上有一半的提交是「临时保存」。我抬起头看了看周围，大家都一样。我把 git reflog 打开，从悬崖边上把自己捞了回来。幸好之前留了备份

我把这个 tag 打在了一个不该打的提交上。我把整条链路在心里复盘了一遍。我把这个 diff 逐行看了一遍，发现有一行是误删。从此我多了一条团队规约