问题是git push假设远程分支可以快进到你的本地分支，也就是说，本地分支和远程分支之间的所有区别都是在本地有一些新的提交，就像这样:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

当你执行git rebase commit时，D和E会被应用到新的base并创建新的提交。这意味着在调整后，你会有这样的东西:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

在这种情况下，远程分支不能快进到本地。虽然，理论上本地分支可以合并到远程分支(显然在这种情况下你不需要它)，但由于git push只执行快进合并，它会抛出一个错误。

force选项的作用是忽略remote branch的state并将它设置为你推入的commit。所以git push——force origin feature-branch只是用local feature-branch覆盖了origin/feature-branch。

在我看来，只要你是唯一在这个分支上工作的人，就可以在master的基础上重新构建特性分支，并强制将它们推回远程存储库。

我将使用“checkout -b”来代替，这样更容易理解。

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

当您删除时，您阻止在包含不同SHA ID的现有分支中推入。 在本例中，我只删除远程分支。

其他人已经回答了你的问题。如果你重新设置一个分支，你将需要强制推动该分支。

Rebase和共享存储库通常不能共存。这是在改写历史。如果其他人正在使用该分支或已经从该分支分支，那么rebase将是非常不愉快的。

一般来说，rebase对本地分支机构管理效果很好。远程分支管理最好使用显式合并(——no-ff)。

我们还避免将master合并到一个特性分支中。相反，我们将改名为master，但是使用一个新的分支名称(例如添加一个版本后缀)。这避免了在共享存储库中重基的问题。

问题是git push假设远程分支可以快进到你的本地分支，也就是说，本地分支和远程分支之间的所有区别都是在本地有一些新的提交，就像这样:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

当你执行git rebase commit时，D和E会被应用到新的base并创建新的提交。这意味着在调整后，你会有这样的东西:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

在这种情况下，远程分支不能快进到本地。虽然，理论上本地分支可以合并到远程分支(显然在这种情况下你不需要它)，但由于git push只执行快进合并，它会抛出一个错误。

force选项的作用是忽略remote branch的state并将它设置为你推入的commit。所以git push——force origin feature-branch只是用local feature-branch覆盖了origin/feature-branch。

在我看来，只要你是唯一在这个分支上工作的人，就可以在master的基础上重新构建特性分支，并强制将它们推回远程存储库。

我会这样做

rebase feature
git checkout -b feature2 origin/feature
git push -u origin feature2:feature2
Delete the old remote branch feature
git push -u origin feature:feature

现在远程将有功能(基于最新的主人)和feature2(与旧主人头)。这可以让你以后比较，如果你在旋转冲突中犯了错误。

而不是使用-f或——force开发人员应该使用

--force-with-lease

Why? Because it checks the remote branch for changes which is absolutely a good idea. Let's imagine that James and Lisa are working on the same feature branch and Lisa has pushed a commit. James now rebases his local branch and is rejected when trying to push. Of course James thinks this is due to rebase and uses --force and would rewrite all Lisa's changes. If James had used --force-with-lease he would have received a warning that there are commits done by someone else. I don't see why anyone would use --force instead of --force-with-lease when pushing after a rebase.