【发布时间】：2015-02-13 03:57:15
【问题描述】：
以下是一个假设场景，旨在更好地了解变基的危险
用户 A 进行了 2 次提交。他首先使用单词“Hello”将文本文件添加（暂存）到根目录，提交它，然后使用单词“world”将另一个文件添加到同一根目录，然后提交该文件。因此，他的最终提交对应于具有 2 个文件的根目录。一个只有一个单词“Hello”，另一个只有一个单词“World”
用户 B 做了同样的事情，并在他的 git root 项目中得到了相同的 2 个文件，只是他以相反的顺序执行：他首先添加带有单词“world”的文件，提交它，然后添加带有单词“hello”的文件并提交它。
最后，假设用户 A 将他的项目推送到远程存储库，然后用户 B 创建了一个跟踪分支并获取了用户 A 推送的项目作为分支。鉴于这种情况，我的问题——实际上试图模拟变基并磨练我对变基的危险的理解——是用户 B 是否需要与与用户 A 推送到远程的任何关联的分支合并仓库？
根据我的阅读和理解，用户 A 和用户 B 的 sha 哈希相对于他们的最终提交将是不同的，因此需要合并，假设他们都希望在知道他们是同步的情况下继续他们的“开发”工作.我说的对吗？
【问题讨论】：
-
我不明白你的问题是如何模拟变基的
-
假设您从公共远程克隆了 master 分支。此分支表示 2 个分支的合并。您在 master 上进行提交并尝试推送它；这样做后，您会意识到其他一些用户克隆了您所做的相同主分支，重新设置它的基础，然后执行 PUSH。因此，在其他用户的 PUSH 之后，假设没有添加进一步的 wirk，表示您克隆的最终快照相同，但提交顺序不同（即线性顺序）。我上面的问题与推送重新定位的分支后远程主分支的状况有关。
-
它与您开始克隆的快照具有相同的快照。因此，您的额外工作（上述额外提交）不能只是一个快进提交，即使您的工作与您克隆时确实代表 master 的快照相关，并且因为它现在在远程中。您将需要与已经退出您想要 ti 推送的当前分支中的 COMMITS 进行合并，因为 git 不会通过快照比较分支，而是通过包含快照的哈希以及导致该快照的路径来比较分支
-
当然，但是倒序的事情真的与它无关。如果他以相同的顺序进行更改，您将获得完全相同的结果。如果您在 5 分钟后自己重新提交，您将得到完全相同的结果。等等。
-
通过以下 torek 的帐户，SHA-1 在这两种情况下是不同的——这就是我问的。你说得对，我们将有相同的最终结果，但是这两个最终结果将具有不同的哈希值来代表最终提交。如果我们的目标是同步我在这个线程顶部提到的 2 个分支，这将需要非快进合并。