推送一个重新定位的分支？答案

【问题标题】：Push a rebased branch?推送一个重新定位的分支？
【发布时间】：2012-08-23 21:47:08
【问题描述】：

我这里有点情况。我 rebase 了一个 dev 分支，并尝试推送它，但它被拒绝（非快进）...既然我不知道为什么，我来找你...

我做了什么：

git checkout dev
git rebase G
# Here, I had to manually merge some files

# Result (in gitk) was :
#       A---B---C remote/dev   A'---B'---C' dev
#      /                      /
# D---E---F------------------G---H remote/master

git push remote dev

知道为什么我的推送是“非快进”并因此被拒绝吗？

【问题讨论】：

尝试拉remote/dev之前，我觉得你应该在本地合并，而不是远程（也就是说远程分支应该集成在你的，而不是你的远程分支）
@Vince：拉（合并）遥控器将合并旧历史。 OP 可能想要摆脱的历史
是的，你是对的，但合并策略是可配置的。我想@knitl 解决方案仍然有效。
@Vince：是的，它们是可配置的，但大多数（全部？）合并策略都会记录合并的两个父节点，因此旧的历史记录会记录在合并提交中。
这有多糟糕？我认为有一种方法可以知道选择了哪个，并且变基之前的代码也可能很有趣（它可能只是一个不同的用例）

标签： git git-rebase git-push

【解决方案1】：

这不是快进，因为你做了一个变基。 rebase 接受一堆提交并从中创建新的提交（可能在提交 DAG 中的不同位置）。请确保您在实际执行之前了解运行git rebase 的所有含义。无法快进就是这些影响之一。

重新定位已发布的历史记录通常被认为是一个坏主意。如果您确实必须重新设置分支并推送它，请将 -f 标志传递给 git push，或者在您的 refspec 前面加上 + (git push remote +dev)。

克隆了您的存储库并在该分支上工作的其他人将必须执行相同的变基，否则您将在下次从某个贡献者合并时合并旧历史记录。

详细说明快进：

从您的图表中很容易看到。快进基本上只会将提交附加到历史记录。每个提交都由其提交哈希唯一标识。提交哈希是根据提交内容以及提交历史计算的。这意味着根据定义，具有不同祖先/父项的提交将具有不同的哈希值。

如果您进行多次提交并将它们插入 DAG 中的不同位置，它们将描述不同的历史记录并获得新的提交哈希（提交时间也已更新，但这不是重点）。因此不可能快进，因为它不再是仅追加了。此外，在变基并推送结果后，您将无法访问旧的提交（无需使用 reflog）。

另一种思考方式：您的推送不会将提交附加到旧的 (remote/dev) 分支，而是将提交附加到其他地方 (commit G)。

【讨论】：

感谢您的详细回答。我想要的是将 F 和 G 应用于我的开发分支。根据您的说法，我知道我宁愿合并而不是变基，例如来自 dev 的git merge G。我说的对吗？
是的，没错。如果你想要 G（以及它的所有历史），你必须从你的 dev 分支运行 git merge G。