在使用 git 时的一些尴尬场景里的修复方案

[Livid]

https://ohshitgit.com

还有一个简体中文的翻译版本：

https://ohshitgit.com/zh

[Binb]

@ClericPy 为什么禁止，难道开发不是在自己分支上。

[ClericPy]

@Binb 早些年 code review 不健全的时候, 那个 amend 还有 cherrypick 老有人乱提, 结果把正在开发的人弄蒙了, 不过现在也无所谓了, 新公司特么的连 git 都不让用, 我已经佛了

[Binb]

@ClericPy 那确实，多人开发分支不能做 ammend 、rebase 等重写 commit id 的操作，真会把人搞懵逼确实难。我都是给自己用，提 mr 前整理自己分支，方便 review ，也方便回退

[Huelse]

@AloneHero #17 git graph

[ClericPy]

@Binb rebase 得做... 不然不好看, 不过只能 rebase 到主上去. 唉一言难尽

[wdssmq]

水水的书签收藏
https://wdssmq.github.io/bookmarks/#/

想把这个教程加进我的书签收藏夹里，而我的书签是用 git 管理的，然后中间就了出现了因为我自己使用姿势的坑 - -

累觉不爱。。

[Rache1]

温馨提示，如果你在多人协作的环境里面，在需要使用到强制推送 (--force) 时，你应该优先使用 --force-with-lease 来代替。

直接使用 --force 时，如果其他协作成员已经推送了新的提交，就会导致这段内容丢失，而使用 --force-with-lease 的时遇到这种情况，就会拒绝你的推送，避免一发自信的 --force 把别人内容搞掉了。

[sickoo]

删是肯定得删的，只是看早晚

[aaronlam]

@Rache1 这个很有用，之前就有自信的同事直接 force 一把梭，然后出事了

[oyp]

我问一下，这个 Git 是工作了才会接触到吗，公司会教吗？为什么学校老师从来不说

[msg7086]

@oyp 学校一般不教具体的工具。
放在国外大学，很多课上要用到语言都不一定教。比如我们有一门课要用 Python ，老师默认你上课前自己学完。

更何况学校有教学大纲，这东西不能随便变化。软件工具技术都是在飞速发展的，学校跟不上那么快的变化速度。

[msg7086]

@oyp （低情商：老师也不懂。）

[msg7086]

@LeeReamond 只花了几天时间搞出来的设计，你指望设计成啥样……
所以才有后面无穷无尽的 alias 和各式各样的 GUI 把这些奇奇怪怪的 CLI 整理成结构化的功能。

[Doracis]

有一个小白问题想问问大家, 就是我想修改已提交的信息, 在使用 git rebase -i HEAD~3 这个指令的时候, 出来的 commit 记录有 19 条, (这里就有点迷糊了) 然后 在修改的记录 前面改成 edit , 回车之后提示我当前的修改点是上一个, 总之就是不能修改 提示我用 git commoit --allow-empty 或者 git reset, 这个情况大家遇到过么

[GeruzoniAnsasu]

@Doracis rebase 到 3 个 commit 前出来 19 条没遇到过，但猜想是你 rebase 的目标经过了一个 merge commit ，导致历史混乱。应该先把 merge 后的 commit 暂存（ cherry-pick 到临时分支或者 stash 起来），reset 掉 merge commit ，然后再重新 merge ，再 pick 回暂存的东西

提示 allow empty 常见场景是你从 A 分支分岔开发 B 的时候发现有个 A 的 bug 要修，然后你在 B 上提交了一个 a(1)，并且把这个 bug 告诉了其他人，它们也在 A 上提交了一个 a(2)，当你要 rebaseA 把 B 的历史接到 A 后面时 a(1) 就是个空修改，因此可以直接舍弃掉。还有一种常见是 a(1)和 a(2)发生了冲突，你解决完冲突临时 commit 的修改与 a(2)相同，临时 commit 就变成了空的，也可以跳过