功能分支重新分配后，Git推送被拒绝 [英] Git push rejected after feature branch rebase

问题描述

我有一个 master 分支和特性分支。我在 master 上做了一些工作，其中一些在特性上，然后在 master 。我最终得到了这样的东西（字典顺序意味着提交的顺序）： ---- F - G（主）
\
D - E（功能）

我对 git push origin master 没有任何问题，以便远程更新 master ，也没有问题使用 git push origin特性（当特性时），以维护我的特性的远程备份工作。到目前为止，我们很好。

但是现在我想在<$ c的顶部重新放置功能 $ c> F - G 提交到master，所以我 git checkout feature 和 git rebase master 。还好。现在我们有：

  A  -  B  -  C ------ F  -  G（主）
 
 D' -  E'（功能）
  

问题：当我要备份新的重新发布的功能时，使用 git push origin feature ，该推送被拒绝，因为该树由于重新更换而发生更改。这只能通过 git push --force来源特性。

来解决。我讨厌使用 - force ，但不确定是否需要它。那么，我需要它吗？是否重新绑定必然意味着下一个 push 应该是 - force ful？

此功能分支不与任何其他开发人员共享，因此使用强制推送功能 de facto 没有问题，我不打算丢失任何数据，问题就更加概念化了。

解决方案

问题在于 git push 假定远程分支可以被快速转发到你的本地分支，也就是说，本地和远程分支之间的所有差异都在本地有一些新的提交，如下所示：

  Z  -  X  -  R < -  origin / some-branch（可以快进到Y commit）
 \ 
 T  -  Y < - 分支
  

执行 git rebase 提交D和E应用于新的基础并创建新的提交。这意味着你有这样的事情之后，你有这样的事情：

  A  -  B  -  C ------ F-- G-D'-E'< - 特征分支
 \ 
 D -E < - 原产地/特征分支
  

在这种情况下，远程分支不能被快速转发到本地。虽然，理论上本地分支可以合并到远程（显然你并不需要它），但是作为 git push 只执行快速合并它抛出错误。
$ b

而 --force 选项的作用是忽略远程分支的状态并将其设置为提交正在推进它。所以 git push --force原始特性分支简单地用本地 origin / feature-branch > feature-branch 。

在我看来，在 master 和强制将它们推回到远程存储库是可以的，只要你是在该分支上工作的唯一人员。

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

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)

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.

But now I wanna 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)

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.

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.

解决方案

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

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

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.

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.

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屋！