Git合并可以清除更改，如何处理

Question

在合并提交创建期间。 如果没有进行任何更改并将其保留在合并提交之外。（这种情况确实会发生，并且在某人不太了解他在做什么的情况下会发生很多事情，只需盲目键入这些神秘命令即可。或者是由于在GUI git工具上单击不当。 [他们是非技术人员，我们试图教他们，但失败了。我们让他们使用git，以便他们可以轻松地更新文件并保持最新。]）然后，更改就消失了。 合并提交将没有this change is undoed msg。 它只是没有出现在合并提交中。 进行更改的提交具有有关更改的信息。 但是合并后，更改实际上被撤消，没有任何痕迹。

这太可怕了，我们不能依靠合并提交信息来告知已更改/撤消的内容。 实际上，没有简单的方法可说。

解决此问题的一种方法是将合并到master的能力限制为值得信赖的维护者。但是，作为快速发展的小型团队，这会给维护者增加负担，并使我们放慢速度。

我想知道是否有人强制执行合并提交以包含有关实际上已还原但未记录的更改的信息？

还是可以完全禁止合并操作，仅允许重新设置以确保所有更改都被明确记录？

Answer 1

傻瓜太聪明了， 没有任何自动化的源工具可以完全做到万无一失。 :-)

我认为大多数人确实应该比合并更经常地调整基础（即，我认为git pull的默认操作（在运行git fetch之后运行git fetch git merge是错误的））。 但是，这并不是解决“人员合并错误”问题的解决方案，因为基础调整正在合并！ 具体来说，要使提交“变基”，您可以复制提交，就像使用git cherry-pick 。 通常，这是小型且简单的操作，不需要任何花哨的合并工作，但有时会出错，并且最终会出现完整的合并。 因此，如果人们要错误地合并，他们也可能会错误地更改自己的基准-当您对多个提交进行基准重新设置时， 每个提交都会被复制，因此每个提交都是潜在的合并。

这意味着解决此问题的唯一方法是学习如何合并 。 我将不得不把这种指示留给其他人，但是我会注意到，相对于合并之前分支的尖端的提交，您可以看到合并带来的变化。

假设您有两个分支，例如，以下一系列提交：

...--o--*--A-----B---C   <-- master
         \
          D--E--F--G--H   <-- feature/X

当您使用git merge feature/X在master上创建一个新的合并提交M时，您将获得一个有两个父级的新提交：

...--o--*--A-----B---C--M   <-- master
         \             /
          D--E--F--G--H   <-- feature/X

就像任何提交一样，此新提交具有自己的独立源代码树。

在您的问题中，您说：

这太可怕了，我们不能依靠合并提交信息来告知已更改/撤消的内容。 实际上，没有简单的方法可说。

但是有！ 提交M （无论其实际的哈希ID是什么）都有两个父级。 这两个父母之一是“之前在分支上的东西”，即，提交C 如果您想查看从提交C到提交M更改，只需让Git告诉您 ：

git diff <hash-id-of-C> <hash-id-of-M>

该git diff的输出与任何 git diff的输出相同：这是一组指令，向您展示如何获取提交为C ，以及如何对其进行修改以使其提交为M

如果需要，您还可以让Git为您提供一组指令，以向您展示如何采用提交为H ，以及如何对其进行修改以使提交为M ：

git diff <hash-id-of-H> <hash-id-of-M>

与任何git diff ，输出是一组指令：“如何获取第一次提交中的内容并进行更改以使其成为第二次提交中的内容。”

有一个简单的方法可以看到这两个

的确， git log -p通常会显示“父提交”与“子提交”之间的差异（例如， A与B或B与C差异）在应用于合并提交时不显示任何内容。 然而：

git show -m <hash-id-of-M>

运行两个 git diff命令，每个父命令一个，并向您显示两个命令 。 将-m视为“显示合并”或什至“拆分合并（分为两个差异）”。 这-m标志是可用的git log ，以及：

git log -m -p

将每个提交一次显示为一个简单的差异（如果不是合并）或一对简单的差异（如果是一个合并，有两个父母）。

（当然，也有几种方法只能获得这两种方法之一 ，但是这个答案已经足够长了。）