把 lazygit 说成「零门槛」这一点,我稍微想较较真。它真正消掉的其实是 recall 的负担——不用在脑子里背 git rebase -i 那串交互流程——但 recognition 替代不了对 Git 数据模型的理解,这俩经常被混为一谈。可用性工程里有个经典说法叫 recognition rather than recall(Nielsen 十大启发式第六条),lazygit 做得漂亮的地方就在这:把命令映射成可见的菜单和按键。可「上下挪一挪、把几个提交合一块」这个动作本身是有语义代价的,界面并不会替你想清楚 squash 和 fixup 的区别,更不会提醒你——要 squash 的提交如果已经 push 到共享分支,下一步就得 force push,而重写别人正在用的历史是有真实风险的。一个完全不懂 rebase 语义的人,在 lazygit 里照样能一键把历史搅得更乱。
解冲突那段也类似。「箭头选一边就成」只在两边改动完全 disjoint 时成立;真遇上同一段代码两边都动了的重叠冲突,lazygit 顶多把冲突块高亮、方便跳转,最终取舍还是得自己判断,它不会、也不该替你拍板。
严格来说
翻 PR 那条我补一句:得先在机器上配好 gh 或者对应的 gitlab token,不是开箱即用,第一次折腾授权还挺费劲的。
我自己是个人小项目全程 lazygit,但凡碰到跟人协作的分支,动历史之前先在脑子里过一遍哪些 commit 已经出去了。工具顺手是真顺手,只是顺手容易让人低估改动的重量。你那几个乱提交后来 squash 的时候,有没有撞上已经 push 得 force 的情况?