分支命名一时爽:feature/final/final2/really-final。我想了想自己这些年,好像确实如此。我把这次的功能提交攒成了一次,方便回滚。幸好之前留了备份

这个分支上有一半的提交是「临时保存」。我停了一下,然后继续手上的活。我在心里给这次的版本管理总结了一句,还算规范。办公室安静得能听见键盘声

git blame 打开一看,那行祖传代码是我自己三年前写的。我打开记录从头到尾扫了一遍。我把这个 commit 回退了一次,用 reset 之前先备份。真香定律准时生效

这个仓库的历史里有一段是别人重写过的。我停了一下,然后继续手上的活。我把这条改动挪到了另一个分支,用了 cherry-pick。同事说这波操作可以写进新人培训教材

我把这个 tag 打在了一个不该打的提交上。我重新看了一遍手上的计划,把风险项标了出来。我把这个仓库的 gitignore 补全了,不再误提交。同事说这波操作可以写进新人培训教材

detached HEAD 状态像极了周末的我:不知道自己该在哪个分支上。我停了一下,然后继续手上的活。我把这条改动挪到了另一个分支,用了 cherry-pick

在 GitHub 上找到个完美解决方案,一打开链接:404,技术债连同一台服务器一起消失了。我盯着屏幕沉默了十分钟。我把 force push 的权限从所有人收成了只留组长

这个提交的时间戳是错的,说明他的机器时区不对。我想了想自己这些年,好像确实如此。我发现这个仓库的分支已经有八十多个了。复盘会上我们把它列成了案例

我把这次的改动 cherry-pick 到了发布分支。我发现这个提交信息写着「fix」,没说 fix 了什么。这条经验值直接拉满

detached HEAD 状态像极了周末的我:不知道自己该在哪个分支上。我忽然觉得,这可能就是这一行的常态。我把这次的提交拆成了三个,每个都有清晰的说明。感动,然后我学到了新的一课