git rebase master 然后 push origin 分支导致非快进错误答案

【问题标题】：git rebase master then push origin branch results in non-fast-forward errorgit rebase master 然后 push origin 分支导致非快进错误
【发布时间】：2012-02-15 11:08:44
【问题描述】：

我正在尝试在我的 featureA 分支上工作，同时使其与 master 分支保持同步。

这里是场景

git clone ssh://xxx/repo

git checkout -b featureA

$ git add file.txt

$ git commit -m 'adding file' 

$ git push origin featureA

同时，一些新的提交被推送到原始主机

git checkout master

git pull origin master

git checkout featureA

git rebase master

git push origin feature A
To ssh://xxx/repo
 ! [rejected]        featureA -> featureA (non-fast-forward)
error: failed to push some refs to 'ssh://xxx/repo'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again.  See the
'Note about fast-forwards' section of 'git push --help' for details.

如何在不强制服务器接受的情况下进行 rebase？

【问题讨论】：

你不能变基……变基会改变历史，你必须强制推动

标签： git branch rebase fast-forward

【解决方案1】：

对您的问题的简短回答：您可以通过将 master 重新定位到 featureA（但不要推送）来执行相反的操作，然后将 featureA 重置到该点。

这实际上是从 master 中挑选提交到 featureA 上，缺点是你最终会在两个分支上重复提交。它会解决你眼前的问题（如果这是你的意图），但从长远来看，你不应该重新定位已经推送到远程分支的提交。在您的场景中，最好的解决方案实际上是合并。

【讨论】：

【解决方案2】：

变基后你不能推送。提交现在具有不同的 SHA1，因为它们的历史不同。如果更新的 ref 不包含其祖先中的旧 ref，这是一个潜在的有害操作，git 不会允许它。

如果您不想强制，您唯一的替代方法是合并。

如果你独自工作并且不需要其他人提交到这个分支，那么强制并不是那么糟糕。

【讨论】：

谢谢@亚当！所以在我的情况下，我是否继续与 master 合并以使我的 featureA 与 master 保持最新，然后将更改推送到我的远程 featureA 分支以确保它们在我们的服务器上的安全？然后当我准备在将来某个时候将 featureA 合并到 master 时，我切换到 master 并执行 git merge featureA?
是的。您只会使用git checkout master && git merge feature 将您的功能合并到 master 中。日复一日，尽可能频繁地合并。
好的。对我的日常开发人员来说，当我按照git checkout featureA && git merge master && git push origin featureA 将master 合并到featureA 以跟上master 时，我将创建master 已经拥有的重复提交，这对吗？当有一天我按照git checkout master && git merge featureA 合并 master 和 featureA 时，这个重复的问题会特别浮出水面，对吗？
是的，你是对的。当然你会在那之前取回。