为什么不合并？

Question

当我变基时，并且有我要解决的冲突，我收到以下消息：

提示：由于当前分支的提示位于后面，因此更新被拒绝

我们有2个分支机构：

master是我们的基地
feature/fix-input-height（要合并到母版中的新功能）

我正在通过重新调配master来本地解决冲突的准备工作，feature/fix-input-height

git checkout master
git pull origin master

git checkout feature/fix-input-height
git pull origin feature/fix-input-height

git rebase master

出现冲突
我解决了
然后尝试推送新功能分支

git push origin feature/fix-input-height

并再次显示该拒绝的错误消息：

提示：由于当前分支的提示位于后面，因此更新被拒绝

stackoverflow上的每个人都建议：

git push origin -f feature/fix-input-height

但是强行推动感觉不对

Answer 1

Rebase通过复制提交来工作。首先，例如：

...--o--o--o   <-- master
      \
       A--B--C   <-- feature/fix-input-height (HEAD)

最后得到：

             A'-B'-C'  <-- feature/fix-input-height
            /
...--o--o--o   <-- master
      \
       A--B--C   [previous feature/fix-input-height, now abandoned]

但是 other 存储库（不是您的存储库，您要求Git git push进行存储）仍然具有原始提交。您不再需要那些提交。您可以使用新的和改进的，但是他们不知道。他们只知道您要他们扔掉三个非常好的提交。

所以他们说不，我不会扔掉那些东西。除非您至少使用强制命令而不是礼貌的请求，否则不要这么做。

这就是为什么您需要--force的原因，或者（尽管人们使用的次数不多，更好）--force-with-lease。您可以通过两种方式告诉他们：是的，我的意思是您应该放弃提交。两者之间的区别是--force只是说：放弃您的提交！ 使用--force-with-lease表示：我认为您的feature/fix-input-height名称会提交C。如果是这样：丢弃那些提交！ 如果有人添加了您没有的提交D，因此没有包含在您的基准库中，则会失败。

Answer 2

Torek's answer无疑是这里最有见地的答案，但是考虑到您的担忧和此后添加的评论，您的问题比技术上的问题更具政治性，您对此感到担心是正确的。

这里的主要关注点应该是«其他人正在研究 feature / fix-input-height 还是一个私有分支？ »

如果该“功能”分支是共享的，则您不应重新设置基准，因为其他人仍会尝试将更改应用于先前的引用。如果它是完全私有的（这是分支机构的目的之一），则可以自由移动它。

但是，为了使Git满意并避免您的同事手动重置分支的本地副本，我可能要做的是保留从旧版本到新版本的传递路径。那是：

将分支合并到 master 之上，但是在解决冲突时仅选择左侧修改，这实际上会丢弃功能分支中的所有内容，而保持 master 不变。但这仍然会引入合并点；
在新的 feature 分支顶部重播您实际要移动的所有提交。

Answer 3

为什么不合并？

如果您经常使用--force感到不对劲，也许您需要切换到快进工作流程：推送提交永远不会改变的工作流程。

此工作流程要求永远不要使用任何历史记录重写命令，例如rebase。

要将主更改带入分支时，只需执行以下操作：

git checkout master # Go on your local master branch
git pull            # Make sure is up to date
git checkout -      # Go back to the previous branch (you can use git checkout mybranch instead)
git merge master    # Merge master into your branch
git push            # Push the fast-forward changes to the repository

这绝不会触发non-fast-forward错误或要求--force标志，因为您使用这些命令的唯一操作就是添加提交，而不重写它们。

如果您担心所有这些合并将使您的git log输出混乱，请记住，有一个添加选项--no-merges对于快速前进的工作流来说做得很好。

Answer 4

这是我的想法，如果我错了，有人纠正我。

如果你非常讨厌 --force，我想你可以从你的功能分支创建额外的分支，它只会为你提供重新定位和解决冲突的服务。例如git checkout -b feature/fix-input-height-rebase。

现在您可以执行 git rebase master，解决冲突并推送：git push --set-upstream origin feature/fix-input-height-rebase。

我看到这种方法的唯一问题（或烦恼）是您必须放弃之前的拉取请求，并创建另一个以 rebase 分支作为源分支和 master 作为目标分支的拉取请求。

Git重新设定基准，修复冲突，然后拒绝推送

4 个答案:

为什么不合并？