功能分支rebase后Git推送被拒绝

Question

好吧,我认为这是一个简单的git场景,我错过了什么？

我有一个master分支和一个feature分支.我做了一些工作master,一些工作,feature然后再做一些工作master.我最终得到这样的东西(词典顺序暗示了提交的顺序):

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

我没有问题要git push origin master保持远程master更新,也没有git push origin feature(当打开时feature)为我的feature工作维护远程备份.到目前为止,我们很好.

但现在我想在主人feature的F--G提交之上重新定义,所以我git checkout feature和git rebase master.还好.现在我们有:

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

问题:当我想要备份新的rebased feature分支时git push origin feature,推送被拒绝,因为树由于变基而发生了变化.这只能通过解决git push --force origin feature.

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

这个功能分支不与任何其他开发者共享,所以我事实上没有问题,推力,我不会丢失任何数据,问题更具概念性.

Answer 1

问题是git push假设远程分支可以快速转发到本地分支,即本地和远程分支之间的所有区别在本地有一些新的提交,如下所示:

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

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

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

在那种情况下,远程分支无法快速转发到本地.虽然,理论上本地分支可以合并到远程(显然你在这种情况下你不需要它),但是git push只执行快进合并它会引发错误.

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

在我看来,master只要您是唯一一个在该分支上工作的人,就可以将功能分支和强制推送回远程存储库.

Answer 2

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

--force-with-lease

为什么？因为它检查远程分支的更改,这绝对是个好主意.让我们想象一下,詹姆斯和丽莎正在研究同一个功能分支,丽莎已经推动了提交.詹姆斯现在重新调整他的当地分支,并在试图推动时被拒绝.当然,詹姆斯认为这是因为改变并使用--force并且会改写所有Lisa的变化.如果詹姆斯曾经使用过--force-with-lease,那么他会收到一个警告,告知其他人已做过提交.我不明白为什么有人会在推销一个rebase之后使用--force而不是--force-with-lease.

Answer 3

我会用"checkout -b"代替它,它更容易理解.

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

当您删除时,阻止推入包含不同SHA ID的现有分支.在这种情况下,我只删除远程分支.

Answer 4

对此的一个解决方案是执行msysGit的rebasing合并脚本所做的事情- 在rebase之后,在旧的head中feature合并-s ours.你最终得到了提交图:

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

...而你的推动feature将是一个快速前进.

换句话说,你可以这样做:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(未经测试,但我认为这是正确的......)

Answer 5

可能是也可能不是这个分支上只有一个开发人员,现在(在rebase之后)不与原点/特征内联.

因此我建议使用以下顺序:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

是的,新的分支,这应该解决这个没有--force,我认为通常是一个主要的git缺点.

Answer 6

我避免强制推送的方法是创建一个新分支并继续在新分支上工作,并在一些稳定之后,删除已重新分支的旧分支:

• 在本地重新签出已签出的分支
• 从重新分支分支到新分支
• 将该分支作为新分支推送到远程.并删除远程旧分支

Answer 7

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

Rebase和共享存储库通常不相处.这是重写历史.如果其他人正在使用该分支或从该分支分支,那么rebase将是非常不愉快的.

一般而言,rebase适用于本地分支机构管理.远程分支管理最适合使用显式合并(--no-ff).

我们还避免将master合并到功能分支中.相反,我们使用新的分支名称(例如添加版本后缀)重新掌握.这避免了共享存储库中的重新定位问题.

Answer 8

分支git merge master上有什么问题feature？这将保留您的工作,同时将其与主线分支分开.

A--B--C------F--G
       \         \
        D--E------H

编辑:啊抱歉没有看到你的问题陈述.当你表演时你将需要武力rebase.修改历史记录的所有命令都需要--force参数.这是一个可以防止您丢失工作的故障保险(旧的D并且E会丢失).

所以你执行了一个git rebase使树看起来像(虽然部分隐藏为D并且E不再在命名分支中):

A--B--C------F--G
       \         \
        D--E      D'--E'

所以,当你试图推动你的新feature分支(包括D'和E'在其中)时,你会失去D和E.

Answer 9

以下对我有用：

git push -f origin branch_name

它不会删除我的任何代码。

但是，如果您想避免这种情况，可以执行以下操作：

git checkout master
git pull --rebase
git checkout -b new_branch_name

然后你可以挑选所有提交到新分支的内容。 git cherry-pick COMMIT ID 然后推送你的新分支。

Answer 10

对我来说，以下简单的步骤有效：

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

完成上述所有操作后，我们也可以通过以下命令删除 myFeature 分支：

git push origin --delete myFeature