请教一下，是谁把代码合丢了

[magic3584]

请教各位大佬，是谁把代码给合丢了，如下图，黄色为 master：

我的猜测是 B 在合并的时候给合没了，但是有个疑问就是 B 合并的时候应该会有冲突的而不是 fast forward 的吧？最开始我只看 master 的提交以为是 A 合没了。

请大佬指点

1. 到底是谁给合没了
2. 这个图看着确实不知道怎么去找是谁？请问是否有更清晰的图？
3. 为什么 A 会从 B 的分支上合并到 master

[GeruzoniAnsasu]

https://www.jianshu.com/p/603186352605

严禁双向 merge. 3B 做了一个从其它分支 merge 的操作，万恶之源。


虽然


但是还是强烈建议你们设定「严禁自己分支 merge 其它分支」的规则。
要临时合并其他人的工作只允许 rebase/cherry-pick ，

严禁双向 merge.

[Helsing]

看 merge 记录

[jheroy]

git log -S [string] ./file
git log -G [regex] ./file
string 和 regex 是被删哪行的内容或者正则表达式, 看最后是谁提交的就行.

[guanhui07]

我也是 JB 家的
文件 show history 一个个 commit 看 以及重点看 merge 才能看出来

[creanme]

我也遇到过几次，同事合并代码提交上来我代码就少了一部分，但是呢看 commit 文件变动，又没改动我的代码部分。

[jimmyismagic]

master 合并设置权限，只允许 rebase fast forward 合并，一条线清清楚楚

[KaGaMiKun]

看着应该是 B 分支本来没有 A 分支文件,在 1A 后合了一次到 B

[KaGaMiKun]

看着应该是 B 分支本来没有 A 分支文件,在 1A 后合了一次到 B
可能因为冲突,没有合并到 A 的新文件,导致 B 分支上缺少了文件
并且在 3B 合并时已经处理 A->B 的冲突,所以没有出现冲突处理,导致直接覆盖了 A 分支

所以问题最初应该在 1A 后 2A 前,B 分支合并 A 分支时冲突没有处理好发生的

(不小心按到了 ctrl 发多了一楼 XD

[ypzhou]

我碰到过，他拉取不下来，有冲突，然后直接给你强制提交他本地的。

[justNoBody]

@GeruzoniAnsasu #41 引用的文章，我觉得说的不对。正如文章下面有人评论的，在多人开发的时候，如果 feature1 先行合并到了 dev 分支，feature2 在合并到 dev 分支时，遇到合并冲突是非常常见的一件事，这个时候，就需要把 dev 的代码合并到 feature2 中。

我理解 OP 这个问题，应该是合并代码的那个人搞丢的，把合并的那个节点提交找出来看看，是不是就可以定位到具体是谁合并丢了？

[Felldeadbird]

4A 和 3B 他们各自合并？ 看 log 找 commit 记录 对比一起。肯定有人解决冲突时，删掉了代码。

[SelFree]

--full-history

[bertonzh]

不知道我对这个图的理解对不对：
1. 3B 是一个 merge ，而且 3B 的 parent commit 之一是 1A ；
2. 1A 中有正常代码，但是 3B 里面没有了。

如果我的理解正确，那么毫无疑问，是 3D 这个 merge 进行的时候，产生了冲突，然后提交者瞎搞把代码搞没了。
至于 4A 完全是无辜的，因为相关的冲突已经被 3D 解决过，到 4A merge 的时候这个地方根本就没有冲突产生。

[bertonzh]

以上 #53 有 typo ，3D -> 3B

[lonenol]

猜测是 3B 在解决冲突的时候把代码搞丢了

[whatiam]

这里存在 2 个可以讨论的问题: 1. 代码是怎么被操作的? 回答: merge 的时候, 没有先 fetch and merge 远端, 导致覆盖掉了远端. 2. 为啥历史记录看不到? 因为 git 默认的 log 指令有简化历史功能, 这里可以使用 git log -p -m file.txt 进行查看完整历史. 其中 -p 表示 patch, m 表示 merge.

[GeruzoniAnsasu]

@justNoBody 双向 merge 的诡异之处在于，这东西会受时序影响。两个 feature 分支的分岔点如果一样，可能不会出问题，但如果一前一后各自分岔，那么 A=>B=>C 与 B=>A=>C 的结果可能就不一样而且不符合预期了。

你也许没明白的是，双向 merge 会发生未产生冲突就丢代码的情况。

原因是更新（ new ）的节点(A)merge 了一个旧节点(B)再 merge 回去(B') 会使 B'认为「不存在(B~B)'期间提交历史」的版本更新（ newer ），从而丢弃(B~B')。这个情况是很难预期也不好发现的。

所以实践上应该禁止 feature2 去 merge dev ，它完全可以 rebase dev 把自己接到后面，此时解决冲突相当于相当于不断发生 dev[N],dev[N+1],feature2[N+1]的三路合并，由于 base 点在 dev[N]，所以不会丢失 dev[N]后的东西（不会认为 dev[N]前的版本更新(newer)），又因为 N 必定大于 feature1 与 dev 的分岔点（ feature1 已经接到 dev 上了），所以也不会丢失 feature1 上的东西。

-----

我看很多人在说解决冲突时误删了代码，然而并不是这么回事。更要命的是搞清并向每一个人说明原理实在是太难了。所以直接制定规则是最可靠科学的办法

[tuutoo]

哪个文件的代码丢了 看这个文件的 commit log 是在哪个 commit 丢掉的.
可以只看一个文件的
找到这个 commit 了 你不就找到人了.

[shm7]

从前一次的 commit point 重新牵出来代码吧，再手工整合进去。

[Hawthorne]

如果代码没修改过不会有冲突，也可能冲突时选择了使用自己的（如果是 sourcetree 等工具也可能选错）。

如果被删的是文件，看历史是哪个提交删除的，如果是内容就先找到文件再看文件的历史。