重新合并后的 Git push

Question

重新合并后的 Git push

30

我知道这个问题以前已经被问过了，但是我好像无法理解这件事情...

git checkout master
git pull
git checkout feature
git rebase origin/master

then resolve all the problems....
Try to push - not gonna happen...

在进行一次变基（处理n个冲突）之后，Git 确实告诉我有两个选择：

使用 --force，但这似乎很危险和愚蠢。

或者再次 pull 并再次处理合并冲突… 最终还是会面临同样的情况吗？

error: failed to push some refs to 'ssh://git@git.zzz.com/yyy/xxx.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

我本地有：特性分支、主分支（已更新）

远端有：特性分支（现在领先？！）和主分支。

我只想要更新我的特性分支，使它更接近主分支的版本...... 为什么git就是这样呢...

我已经阅读了很多关于这个问题的帖子，唯一的解决方案似乎是使用--force

对我来说，这根本不算是解决方案，毕竟这是一个如此常用的工具...

- Clomez

你在尝试推送之前解决了所有冲突吗？ - U. Windl

1

可能是Git合并功能分支后推送被拒绝的重复问题。 - kowsky

1

感谢您正确地提出问题！非常有用！:D - Sreekiran A R

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- padawin · Accepted Answer

git push --force 原则上没有任何问题。

它所做的是用本地分支替换远程分支的 head。

有两种情况，一种情况下可以强制推送，另一种情况则根本不行：

如果你进行了 rebase 操作（因此为你的分支创建了一个新的提交链），你的分支和远程分支就会分叉，这是可以预料的结果。而且你是故意让它们分叉的。例如，你的分支与 master 不同步，因此你将其 rebase 到 master 之上（从技术上讲，提交是从新基础，即 master 重新创建的，但实际上看起来就像是移动了）。所以你知道它们已经分叉，并且你的本地版本是正确的。在这种情况下，告诉 git：“采用这个版本，放弃你持有的版本”是可行的。

然而，如果您与其他人在同一分支上工作，其中一人在您做出更改时推送了新变更的分支，则当您想要推送时，Git 还会告诉您本地分支及其上游分支已经分叉，因此您应该先拉取等。在这种情况下，很重要的一点是不要使用push --force，否则您的同事的工作将被覆盖，他/她可能会非常生气。所以在这种情况下，您确实需要先pull(我建议使用pull --rebase，以避免创建合并提交，并保持您的历史记录更清晰，但这是非常主观的)，然后再push（在拉取后，不需要使用--force）。

总之，了解git push --force的含义，知道何时可以用本地分支覆盖上游分支（您可以使用push --force），以及何时不可以（您需要拉取）。

回到您最初的情况，您已经变基了自己的分支，所以它已经分叉（根据定义），如果您独自在分支上工作，或者如果您确保没有人在此期间推送任何内容，则git push --force是您需要的。