我最近多次报道多个团队报告说，在与GitHub.com上的原始回购合并后，某些变更正在丢失。团队成员都使用SourceTree作为他们的git客户端。
我发现的共同主题是，似乎repo认为该文件在合并之前似乎在分支上有X个提交，然后在合并之后提交X-Y。通过查看分支的提交日志，提交仍然存在，但由于某种原因，它们不会应用于相关文件。在源代码树中，这是相同的，但如果你＆＃34;关注重命名的文件＆＃34;它带来了所有的提交。文件名或文件夹结构绝对没有变化。
这可能会发生什么？
https://www.dropbox.com/s/zrcb9tw2ptpb3b0/FileHistory_Commit.png?dl=0 https://www.dropbox.com/s/uc5v5d2bfztoicn/FileHistory_Develop.png?dl=0
答案 0 :(得分：3)
重要的是要记住，git提交不依赖于特定文件，并且它们不是由diffs定义的;每个提交只是整个存储库的快照。因此，当您查看文件的“历史记录”时，由您使用的工具决定哪个提交与该文件“关联”。这通常以显而易见的方式完成：如果提交的文件版本与提交的父文件版本不同，则该提交将包含在文件的历史记录中。
当事情变得复杂时，提交具有多个父项，即在合并中。通常情况下，如果存在只有父项之一的差异，则不希望在文件的历史记录中看到这些内容。要了解原因，请考虑在分支中进行更改X的常见情况，在提交A中提交，然后在使用提交G将该分支合并到主服务器中。如果查看G和它的主要父级之间的差异，会看到改变X.但这不是X“真正”引入的地方;发生在提交A中。因此，当查看文件的日志时，您不希望看到提交G，您只想查看提交A.例外情况是解决冲突时;在这种情况下，合并本身会真正引入变更。与主要的和次要父母相比，这可以通过文件中的差异来表示。当您单击“关注重命名的文件”时，SourceTree似乎包含合并提交，即使它与重命名的文件无关。
现在，当正确执行合并时，这一切都很好。但是，在你的情况下，你有一些拙劣的合并 - 这就是为什么提交丢失的原因。你的回购是私有的，所以我不能看它，并准确地告诉你哪些合并是拙劣的，如何，但这可能发生了什么。开发人员执行了git pull导致合并冲突，这阻止了通常在提取/合并时发生的自动提交。除了冲突的文件，开发人员还看到了他们没有进行的临时区域的更改。他们认为他们不想提交随机更改，因此他们解除了这些更改，修复了他们的合并冲突并提交了。
他们解开的那些变化现在已经“丢失”了。提交合并时，您承诺所提交的快照包含两个父项可以访问的所有更改。这意味着当你使用它的主父进行正确合并的差异时（这是开发人员在SourceTree列出“已更改文件”时看到的内容），你应该看到辅助所带来的所有更改家长。
所以底线是这样的：当你处于合并的中间并且你看到你没有突然出现的变化时，你必须提交这些更改，或者中止合并。
