在添加不相关的文件后，是否使git branch ffwd能够再次启用？

我有一个本地

master

分支，跟踪

origin/master

，它在某个点从上游/稳定的

分叉。当更改可用时，我可以从
上游/stable
拉入/合并，然后将这些更改发送到
origin/master
。一切都很好

现在，我添加了一个单独的文件，与
上游/stable
中的文件无关，突然我的分支无法快速转发

我可以从
上游/stable
（导致恼人的合并提交）合并并推送到
源站/master
，但我怀疑，由于合并提交，我的本地
主站
分支之后仍然无法从
上游
进行ffwd。即使在我没有对
master
进行任何进一步的本地提交时（但仍然希望从
上游不断更新
origin
）

再见，在
上游
和
起点
之间轻松穿梭；hello讨厌的祖先结构（我已经看到了树视图中重复合并的样子）和无用的合并提交

我甚至不知道如何进行实验，因为我看不到从
上游/stable
一个一个地合并提交的方法，只是一直到它的顶端

我知道关于
merge--rebase
，但这当然会重写本地历史，当本地
master
不断同步到
origin/master
时，这是行不通的

怎么办？
如果您的分支包含其他分支未包含的更改，则您永远无法将您的分支快速转发到其他分支[1]。不管您的更改是在相同的文件中还是在不同的文件中；改变就是改变

有些人（你听起来像他们中的一个）把对合并的徒劳的仇恨放在所有其他担忧之上；对于他们来说，有git rebase
[2]。每次您从上游获得新的更改时，您都可以在其上重新设置本地
主控
，而不是将其合并。基本上，您的
主机将在任何时间点看起来都像是您在整个上游分支上快速转发了它，然后在其上进行了本地更改。没有合并提交。但是：

这意味着，正如您所指出的，您的
主分支以非快进方式移动。这与git中的正常意图相反，因此它意味着在每次重新基准后，您必须强制将
master
推送到
origin/master
。如果您的回购协议是共享的，那么您必须与所有其他用户协调这些强制推送中的每一个，否则，在尝试修复导致的错误时，他们可能会撤消您的更改。您可以在“从上游再基地恢复”下的
git-rebase
文档中阅读有关此问题的更多信息


[1] git中的快进（Fast forward）意味着不进行合并，只需将分支移动到与另一个分支相同的提交位置，因为这将产生与合并相同的结果。如果您的分支中有更改，那么结果将不一样，并且快速转发是不可能的

[2] 我应该注意到，
git-rebase有很多很好的用途；我并不是说这只对那些我认为历史管理优先考虑不好的人有用。但这是该阵营中的人们可以用来获取他们认为应该拥有的简单化历史记录的主要工具。
我已经进行合并提交有一段时间了（我的问题是一个简化版本）。今天，我查看了
tig
中的树结构。极坏的此外，这些人工合并提交背后并不存在现实——至少对于没有干预本地更改的重复提交是不存在的。在git之前，
DARC
在可交换补丁方面曾经聪明得多，但DARC很慢，而且已经死了很长时间。