功能分支变基后 Git 推送被拒绝 [英] Git push rejected after feature branch rebase

问题描述

好吧，我以为这是一个简单的 git 场景，我错过了什么?

OK, I thought this was a simple git scenario, what am I missing?

我有一个 master 分支和一个 feature 分支.我在 master 上做了一些工作，在 feature 上做了一些工作，然后在 master 上做了一些工作.我最终得到了这样的结果(字典顺序意味着提交的顺序):

I have a master branch and a feature branch. I do some work on master, some on feature, and then some more on master. I end up with something like this (lexicographic order implies the order of commits):

A--B--C------F--G  (master)
           
        D--E  (feature)

我对 git push origin master 保持远程 master 更新没有问题，也没有问题 git push origin 功能(当在 feature) 来维护我的 feature 工作的远程备份.到目前为止，我们都很好.

I have no problem to git push origin master to keep the remote master updated, nor with git push origin feature (when on feature) to maintain a remote backup for my feature work. Up until now, we're good.

但现在我想在 F--G 提交的基础上重新设置 feature 在 master 上的提交，所以我 git checkout feature 和 <代码>git rebase master.还好.现在我们有:

But now I want to rebase feature on top of the F--G commits on master, so I git checkout feature and git rebase master. Still good. Now we have:

A--B--C------F--G  (master)
                 
                  D'--E'  (feature)

问题:当我想备份带有git push origin feature分支的新的rebased feature时，推送被拒绝 因为树已经由于变基而改变了.这只能通过 git push --force origin 功能 来解决.

Problem: the moment I want to backup the new rebased feature branched with git push origin feature, the push is rejected since the tree has changed due to the rebasing. This can only be solved with git push --force origin feature.

我讨厌使用 --force 而不确定我是否需要它.那么，我需要吗?重新定位是否必然意味着下一个push应该是--forceful?

I hate using --force without being sure I need it. So, do I need it? Does the rebasing necessarily imply that the next push should be --forceful?

此功能分支不与任何其他开发人员共享，因此我对强制推送事实上没有问题，我不会丢失任何数据，问题更具概念性.

This feature branch is not shared with any other devs, so I have no problem de facto with the force push, I'm not going to lose any data, the question is more conceptual.

推荐答案

问题在于 git push 假设远程分支可以快进到你的本地分支，这就是所有的不同本地和远程分支之间是在本地，最后有一些新的提交，如下所示:

The problem is that git push assumes that remote branch can be fast-forwarded to your local branch, that is that all the difference between local and remote branches is in local having some new commits at the end like that:

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

当您执行 git rebase 提交时，D 和 E 将应用于新的基础并创建新的提交.这意味着在 rebase 之后你会有类似的东西:

When you perform git rebase commits D and E are applied to new base and new commits are created. That means after rebase you have something like that:

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

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

In that situation remote branch can't be fast-forwarded to local. Though, theoretically local branch can be merged into remote (obviously you don't need it in that case), but as git push performs only fast-forward merges it throws and error.

而 --force 选项所做的只是忽略远程分支的状态并将其设置为您正在推送的提交.所以 git push --force origin feature-branch 只需用本地 feature-branch 覆盖 origin/feature-branch.

And what --force option does is just ignoring state of remote branch and setting it to the commit you're pushing into it. So git push --force origin feature-branch simply overrides origin/feature-branch with local feature-branch.

在我看来，只要您是唯一在该分支上工作的人，就可以在 master 上重新设置功能分支并将它们强制推送回远程存储库.

In my opinion, rebasing feature branches on master and force-pushing them back to remote repository is OK as long as you're the only one who works on that branch.

这篇关于功能分支变基后 Git 推送被拒绝的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！