Git:由于看似随机的合并,变化不断丢失

Question

我有一种感觉,这将是一个明显的答案,但我似乎无法解决这个问题.

似乎发生的事情是我提交/推送一些更改到服务器,我的副本上的一切似乎都很好.

然后另一个开发人员从同一个分支机构(从据我知道的那样看到我的更改)从服务器中撤出,进行一些修改,将它们提交到自己的本地副本然后最终将其推回到服务器.

在执行此操作的过程中,我的更改会丢失,因为它们的推送(326c8fd0 ...)会导致合并大量删除/添加行,将存储库重置为更旧的版本.即使使用存储库的新副本,现在已经发生了几次.

下面突出显示的行(8def6e9 ..)是我提交的,下面的提交应该在同一个分支上,假设其他开发人员撤消了更改.合并发生在326c8fd0,最终错误地重置存储库,丢失以前的更改.

我错过了一个非常明显的原因吗？我们都在使用TortoiseGit.

很抱歉可能含糊不清的解释.

Answer 1

在您的示例中,有人正在合并f36908d(第一个父项;合并时的HEAD)和8def6e9(第二个父项;可能是合并时原点分支的顶点)以生成326c8fd0.

如果合并提交(326c8fd0)缺少关于其任一父项的重要内容(f36908d和8def6e9;你说它缺少后者的部分),那么创建合并提交的人可能正在以不合适的方式执行合并时尚.

此人可能正在使用ours合并策略(merge/pull with -s ours/ --strategy=ours),ours默认递归合并策略的选项(与-X ours/ 合并或拉取--strategy-option=ours),或者他们可能只是在手动解决合并冲突时做出错误的决定.

该ours策略完全忽略了历史上所有父母的内容变化,但第一个.您通常可以识别这种类型的合并,因为合并提交及其第一个父级(即它们的更改)将具有相同的树(即,git diff f36908d 326c8fd0将显示没有差异).

该ours合并策略选项也将忽略从第二父(即更改)的历史变化,但只有那些在第一父(即其变化)的历史所做的更改冲突.在这种情况下,来自第二个父级的一些更改可能会使其成为结果,但其他更改可能会完全丢弃.

另一种可能的替代方案是,他们只是在解决默认合并期间生成的冲突时做出错误的决定.

无论哪种方式,有人可能不得不与进行合并的用户交谈以确切了解他们做了什么,以及为什么他们这样做以便可以设计策略以防止将来出现问题.

要恢复,您可以自己重做合并,然后将结果合并到历史记录的当前提示中:

git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git checkout develop
git merge remerge
# maybe resolve more conflicts

# eventually: git branch -d remerge

或者,如果您可以重写历史记录:

git checkout -b remerge f36908d
git merge 8def6e9
# resolve conflicts and commit
git rebase --onto remerge 326c8fd0 develop
# maybe more conflicts to resolve at each rebased commit