功能分支重新设置后，Git推送被拒绝

好的，我以为这是一个简单的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)

问题：当我要备份以git push origin feature feature分支的新的基于重载的feature ，由于树由于重新定基而发生了更改，因此该推送被拒绝了。 这只能通过git push --force origin feature解决。

我讨厌使用--force不确定自己是否需要它。 所以，我需要吗？ 请问垫底一定意味着未来push应该是--force FUL？

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

---

#1楼

在这个分支上可能只有一种开发人员，也可能不是这种情况，即现在（在重新设置基准之后）不与原点/功能内联。

因此，我建议使用以下顺序：

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

是的，新分支，这应该在没有--force的情况下解决此问题，我认为这通常是git的主要缺点。

---

#2楼

以下对我有用：

git push -f origin branch_name

并且不会删除我的任何代码。

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

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

那么您就可以将所有提交樱桃挑选到新分支。 git cherry-pick COMMIT ID ，然后推送您的新分支。

---

#3楼

由于OP确实了解了问题，因此只寻找更好的解决方案...

作为实践呢？

• 拥有实际的功能开发分支（您永远无需重新设置基础和强制推送，因此您的同行功能开发人员不会讨厌您）。 在这里，请定期合并合并中的更改。 梅西耶（Messier）的历史 ，是的，但是生活很轻松，没有人对他的工作有所了解。

• 拥有第二个功能开发分支，其中一个功能团队成员定期将所有功能提交推送到，实际上是基于基础的，甚至是强制执行的。 因此，几乎完全是基于最近的主提交。 功能完成后，将该分支推入master顶部。

该方法可能已经有一个模式名称。

---

#4楼

我会改用“ checkout -b”，它更容易理解。

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

删除时，您可以防止推送包含不同SHA ID的现有分支。 在这种情况下，我仅删除远程分支。

---

#5楼

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

--force-with-lease

为什么？ 因为它检查远程分支的更改，这绝对是个好主意。 假设James和Lisa正在同一个功能分支上，而Lisa已推送了一次提交。 詹姆斯现在将其本地分支机构重新设基，并在尝试推送时被拒绝。 当然，詹姆斯认为这是由于改组并使用--force造成的，并将重写Lisa的所有更改。 如果詹姆斯使用了“租用强制”，他将收到警告，提示其他人进行了提交。 我看不出为什么有人在重新定级后进行推送时会使用--force而不是--force-with-lease。

---

#6楼

我避免强行推入的方法是创建一个新分支，并继续对该新分支进行工作，并在保持一定稳定性之后，删除重新建立基础的旧分支：

• 在本地重新建立已签出的分支
• 从重新建立基础的分支到新分支
• 将该分支作为新分支推送到远程。 并删除远程上的旧分支

---

#7楼

对我来说，遵循简单的步骤即可：

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

---

#8楼

feature分支上的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

---

#9楼

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

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

当您执行git rebase提交D和E应用于新的基础，并创建新的提交。 这意味着在重新设置基准之后，您将得到以下内容：

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

在这种情况下，远程分支无法快速转发到本地。 虽然，理论上可以将本地分支合并到远程（显然，在这种情况下您不需要它），但是由于git push仅执行快进合并，因此会引发错误。

--force选项的作用只是忽略远程分支的状态，并将其设置为您要推送到其中的提交。 因此git push --force origin feature-branch只是使用local feature-branch覆盖了origin/feature-branch feature-branch 。

在我看来，只要您是该分支上唯一的成员，就可以在master上对功能分支重新建立基础，然后将其强制推回到远程存储库中。

---

#10楼

一种解决方法是做msysGit的一下重订合并脚本执行-变基后，在老头合并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

（未经测试，但我认为是对的...）

---

#11楼

别人已经回答了您的问题。 如果您为分支设置了基准，则需要强制推送该分支。

变基和共享存储库通常不会相处。 这是重写历史。 如果其他人正在使用该分支或已从该分支分支，则重新设置基准将非常不愉快。

通常，对本地分支机构管理来说，改组效果很好。 远程分支管理最适合与显式合并（--no-ff）一起使用。

我们还避免将master合并到功能分支中。 取而代之的是，我们改用母版，但使用新的分支名称（例如，添加版本后缀）。 这避免了在共享存储库中重新设置基准的问题。