将上游更改合并到共享分支时，如何使 git 历史反映开发现实？

Question

我与其他一些开发人员一起在一个流行的公共 git 存储库的分支上工作。我们需要定期将上游更改合并到我们的分叉中。我怎样才能做到这一点并使历史反映发展现实？例如，在我合并上游更改后，我希望我们的一位开发人员能够轻松地同步到我们分支上的某个位置，该位置准确反映了 N 个月前我们的开发团队发送提交和执行测试时的世界状态，所以我们可以例如运行相同的测试并期望得到与 N 个月前相同的结果，例如轻松地对历史进行二进制搜索，以缩小引入后期发现的错误的范围。

我尝试过的一些事情：

1. 似乎默认的 git merge 最终会根据提交的日期将上游更改与我们自己的更改交错，这使得几乎不可能同步到世界的真实状态，因为它发生了在我们开发的时候。

2. 通过使用 --squash 合并，git 历史正确地反映了开发现实（在上游更改合并之前和之后容易同步，并且最终与 N 个月前发生的实际状态相同），但是似乎 --squash 告诉 git 忘记所有单独的提交，由于巨大的冲突，这使得将来合并新的上游更改变得极其困难。

3. 我也试过 --no-ff 但这似乎根本没有帮助。仍然将上游历史与我们的历史交织在一起。

我是否正在尝试做一些 git 从未打算做的事情？一种可行的策略是经常合并上游的变化（比如每天或每周），这样上游和我们之间的开发现实就非常相似。但是现在我们已经几个月没有合并上游，如果有一种方法可以基本上实现良好的 --squash 行为，但又不放弃 git 对单个提交的了解，那就太好了。我考虑手动进行许多较小的 --squash 合并，例如上游历史的每一周。我猜这将更容易合并未来的上游更改，但这非常痛苦。有什么强有力的理由这样做或不这样做吗？有更好的想法吗？

哦，实际上还有一个想法：也许我可以将上游的更改重新定位到我们的分支上，如果我理解正确，这将实现我想要的“反映开发现实的状态”（有人可以确认这是真的吗？），但是我'仍然想稍微压缩一下，以便我的团队的提交数量大大减少，不会被上游提交所淹没，这使得检查和理解我们的分支历史变得更加困难。在这种情况下，rebase+squash 是否有意义，或者与纯 squash 相比没有真正的优势？

Answer 1

使用变基工作流程可能是您在此处寻找的内容。要了解变基的工作原理，请考虑以下简单的分支图：

remote: A -- B
               \
local:           C

这里，我们从一个本地分支开始，从远程分支，添加了一些新的提交C，但还没有推送。当然，实际上，您团队中的其他人可能会将他们自己的新提交推送到远程，所以我们也这样做：

remote: A -- B -- D
               \
local:           C

现在明白您不能简单地将本地分支推送到远程。解决此问题的一种方法是将远程合并到您的本地分支中。但这会创建一个合并提交，给你留下一个非线性的历史，随着时间的推移，可能会变得难以阅读。这里有一个替代方案；你可以使用git rebase。如果您运行以下命令：

git fetch origin
git rebase yourBranch origin/yourBranch

那么您将得到以下分支图：

remote: A -- B -- D
                    \
local:                C'

换句话说，您的本地分支将是完全线性的，并且您只需执行一个简单的git push 即可将您的更改集成到远程。这样的推送实际上只是快进遥控器，放下你的新提交。

如果您能找到遵循变基工作流程的方法，那么您的远程分支将始终是线性的，并且在某种程度上，您将及时回到开发过程中的任何确切点。