Git与远程合并后文件丢失的变化(SourceTree,GitHub)

Question

我刚刚在多个团队中多次报告过,在与GitHub.com上的原始回购合并后,某些变化正在丢失.团队成员都使用SourceTree作为他们的git客户端.

我发现的共同主题是,似乎repo认为该文件在合并之前似乎在分支上有X个提交,然后在合并之后提交XY.通过查看分支的提交日志,提交仍然存在,但由于某种原因,它们不会应用于相关文件.在源代码树中,这是相同的,但如果您"关注重命名的文件",它会引入所有提交.文件名或文件夹结构绝对没有变化.

这可能会发生什么？

https://www.dropbox.com/s/zrcb9tw2ptpb3b0/FileHistory_Commit.png?dl=0 https://www.dropbox.com/s/uc5v5d2bfztoicn/FileHistory_Develop.png?dl=0

Answer 1

重要的是要记住，git 提交不与特定文件绑定，并且它们不是由差异定义的；每次提交只是整个存储库的快照。因此，当您查看文件的“历史记录”时，由您使用的工具来决定哪些提交与该文件“关联”。这通常以明显的方式完成：如果提交的文件版本与提交的父文件版本不同，则该提交将包含在文件的历史记录中。

事情变得复杂的是当一个提交有多个父级时，即在合并中。通常，如果仅与父文件之一存在差异，您不希望在文件历史记录中看到这些内容。要了解原因，请考虑以下常见情况：在分支中进行更改 X，在提交 A 中提交它，然后使用提交 G 将该分支合并到主分支中。如果您查看 G 与其主要父级之间的差异，您会发现将会看到变化 X。但这并不是 X “真正”引入的地方；这发生在提交 A 中。因此，当查看文件的日志时，您不会想看到提交 G，您只想看到提交 A。例外情况是当冲突已解决时；在这种情况下，合并本身就会真正引入变化。这可以通过与主文件和主文件相比在文件中存在差异来表明。。当您单击“跟随重命名的文件”时，SourceTree 似乎包含合并提交，即使它与重命名的文件无关。

现在，当合并正确执行时，一切都很好。然而，就您而言，您有一些拙劣的合并 - 这就是提交丢失的原因。您的存储库是私有的，因此我无法查看它并准确地告诉您哪些合并被破坏以及如何被破坏，但以下是可能发生的情况。开发人员做了一个git pull导致合并冲突的事情，这阻止了通常在拉取/合并时发生的自动提交。除了冲突的文件之外，开发人员还看到了他们未进行的暂存区域的更改。他们认为他们不想提交随机更改，因此他们撤消了这些更改，修复了合并冲突，然后提交了。

正是他们所取消的那些改变现在已经“丢失”了。当您提交合并时，您就承诺您正在提交的快照包含父级双方均可访问的所有更改。这意味着，当您与其主要父级进行正确合并的差异时（这是开发人员在 SourceTree 列出“更改的文件”时看到的内容），您应该看到次要父级带来的所有更改。

所以底线是这样的：当您处于合并过程中并且看到突然出现的未进行的更改时，您必须提交这些更改，或者中止合并。