功能分支重新设置后，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工作维护远程备份。到目前为止，我们还不错。

但是现在我想基于master feature的F--G提交基础，所以我git checkout feature和git rebase master。还好。现在我们有：

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

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

我讨厌--force不确定我是否需要它。所以，我需要吗？变基是否必然意味着下一个push应该满足--force？

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

问题在于，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只需origin/feature-branch使用local 覆盖feature-branch。

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

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

--force-with-lease

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

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

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

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

一种解决方案是执行msysGit的重定基合并脚本的工作-在重定基数后，将其合并到featurewith中-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

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

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

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

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

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

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

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

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

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

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

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

分支git merge master上的a有什么问题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。

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

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

以下对我有用：

git push -f origin branch_name

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

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

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

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

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

作为实践呢？

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

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

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