问题描述
我有一个本地 master 分支，跟踪 origin/master，它在某个时候从（假设）upstream/stable 分叉出来。我可以在更改可用时从 upstream/stable 拉取/合并，然后将这些更改发送到 origin/master。一切都很好。
现在，我添加了一个与 upstream/stable 中的文件无关的文件，突然我的分支无法快速转发。
我可以从 upstream/stable 合并（导致恼人的合并提交）并推送到 origin/master，但我怀疑，鉴于合并提交，我的本地 master 分支仍然不会之后可以从 upstream 开始。 即使有时我没有对 master 进行任何进一步的本地提交（但仍然希望不断从 origin 更新 upstream）。
再见upstream和origin之间的轻松穿梭；你好讨厌的祖先结构（我已经看到在树视图中重复合并的样子）和无用的合并提交。
我什至不知道如何试验这个，因为我没有看到从 upstream/stable 合并提交的方法，只能一直到它的提示。
我知道 merge --rebase，但当然会重写本地历史记录，当本地 master 不断同步到 origin/master 时，这不起作用。
怎么办？
解决方法
如果您的分支包含另一个分支没有的更改，则永远不能将您的分支快进到另一个分支[1]。无论您的更改是在同一个文件中还是在不同的文件中，都没有关系；改变就是改变。
有些人（你听起来像是其中之一）将合并提交的仇恨置于所有其他问题之上；对他们来说，有git rebase[2]。每次您从上游获得新更改时，您都可以将您的本地 master 重新设置在它们的基础上，而不是将它们合并。基本上，您的 master 将在任何时间点看起来就像您已经快进一样整个上游分支，然后然后在它之上进行本地更改。没有合并提交。但是：
这意味着，正如您所指出的，您的 master 分支以非快进方式移动。这与 git 中的正常意图相反，因此这意味着在每次变基后，您必须强制将 master 推送到 origin/master。如果您的存储库是共享的，您将必须与所有其他用户协调这些强制推送中的每一个，否则在尝试修复导致的错误时，他们有可能撤消您的更改。您可以在 git rebase 文档中“从上游变基恢复”下阅读有关此问题的更多信息。 https://git-scm.com/docs/git-rebase
[1] git 中的快进意味着您不必合并，而是将您的分支移动到与另一个分支相同的提交因为无论如何它都会与合并具有相同的结果。如果你的分支有变化，那么结果就不一样了，快进根本不可能。
[2] 我应该注意到 git rebase 有很多很好的用法；我并不是说它只对那些我认为历史管理优先级不高的人有用；但它是该阵营中的人们可以用来获取他们认为应该拥有的简单历史的主要工具。