情境：
我已经分支了主分支（我们称之为新的“分支-a”），我有代码我已经承诺分支-a但是没有将它合并到master中。现在，同事已经分支了branch-a来建立我的工作（我们称之为“branch-b”）并提交他的工作，将其推送到GitHub。 GitHub将他的PR显示为我的所有更改（branch-a）和他的更改（branch-b）作为新文件/提交。
问题：
我的同事分支机构是否有可能只显示他所做的更改？他可以等到我合并我的代码，然后我们知道没问题。但只是好奇这是否有可能在PR中显示差异。
答案 0 :(得分：1)
我的同事分支是否有可能只显示他所做的更改？
没有。例如，考虑一下如果添加一个全新的文件会发生什么 - 让我们调用它alphapilgrim.txt - 然后他修改了该文件。如果没有该文件的存在，他的改变会是什么？
更深入的是，Git本身将每个提交存储为快照：整个源的新的，完整的，单独的副本。在幕后，文件实际上从一个快照共享到另一个快照，但至少在逻辑概述中，每个快照完全独立于任何先前或后续快照 - 只有一个例外：每个快照也引用“真实名称” （哈希ID），其父快照。
每个快照的真实名称hash-ID绝对完全100％保证对该快照是唯一的，但在该快照的所有相同副本中是相同的。事实上，对于所有Git对象都是如此，包括“blob”（文件存储）对象。 1 这个想法是Git操作的核心，无论是在内部（在提交等内）还是在外部（提取和推送提交和提出拉动请求。）
因此，pull请求会发生的事情是，您（请求ee）将您的存储库和特定提交的权限移交给您。该提交具有唯一的哈希ID，允许Git访问其父提交。父有一个唯一的哈希ID，它允许Git访问提交的父级 - 你的PR的祖父，就像它一样。祖父母有一个唯一的哈希ID，可以让Git访问......好吧，希望你能在这里得到这个想法。 :-)这个过程一直重复，直到它到达了他们已经拥有的提交，并且他们知道他们拥有它，因为，他们拥有它：他们有一个提交ID。
因此，为了制作一个不依赖你的承诺的公关，你的同事（先生或Co女士，也许？ - 你说“他”;我会打电话给他“M.Co”）必须替换/重写他当前的一系列提交，这些提交会返回到您的提交，这些提交将返回到所有提交的提交。 M.Co可以创建一个类似于M.Co原始提交的 new 系列提交，除了它们从共享库中分支出来。 2
将一系列提交复制到新基础的主要Git命令是git rebase。复制这些提交后，它会将当前指向最后一个提交的分支 name 更改为指向最后一个副本。一旦M.Co重新提交了他的提交，他/她就可以向他们提出新的请求。现在，pull-ee将获取最新的提交，查看其父ID，查看父级的父级，依此类推，直到达到共享提交 - 并且追逐此链将找不到任何< em>你的提交。
1 有关其他信息，请参阅How would Git handle a SHA-1 collision on a blob?和Hash collision in git。有可能暴力攻击Git哈希，以及旧版本的Git ......好吧，它们并没有完全失败，但是它们确实表现得非常糟糕：你的新提交无效或者可能永远不会发生，有时候没有警告就是这种情况。现有的提交都很好，但如果你必须git reset --hard抛弃一个破碎的提交，那就不好了。除了碰撞文件之外的所有文件都是可恢复的，但只有一定的痛苦。
2 正是在这一点上，M.Co意识到他已经修改了alphapilgrim.txt并且字面上可以不以这种方式变换。当然，除非他没有做过如此糟糕的事情。但在任何一种情况下，M.Co的工作都是将他的变化调整到较旧的基础，减去你所做的任何事情，以达到他的原始提交的快照。