rebase 后进行 Git 推送

Question

我知道以前有人问过这个问题，但我似乎无法理解这件事......

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

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

git 确实告诉我，在进行 rebase 后（处理 n:ths 冲突）

我有两个选择，使用

--force

，这看起来既危险又愚蠢。

再次

或

pull

并再次处理合并冲突...并最终处于相同的情况？

error: failed to push some refs to 'ssh://[email protected]/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.

我本地有：功能分支，master（最新）

和远程：featureBranch（现在领先了？！）和master。

我只是想更新我的功能分支，以便它甚至接近 master 上的版本...... 为什么git是这样的...

我已经阅读了很多有关此问题的帖子，唯一的解决方案似乎是使用

--force

对于我来说，对于这种常用的工具来说，这似乎是一个解决方案......

Answer 1

原则上

git push --force

没有任何问题。

它的作用是将分支的远程头替换为本地分支。

有两种情况，一种推力可以，一种根本不行：

如果您重新设置基础（因此为您的分支创建了一个新的提交链），您的分支和远程分支就会出现分歧，这是可以预料的。你故意让他们产生分歧。例如，您的分支不是最新的

master

，因此您将其变基以将其“移动”到

master

之上（从技术上讲，提交是从新的基础重新创建的，在本例中为

master

但实际上它看起来好像已经被移动了）。因此，您知道它们存在分歧，并且您的本地版本是正确的。在这种情况下，可以告诉 git：“使用这个版本，丢弃你拥有的版本”。

但是，如果您与同一分支上的其他人一起工作，并且一个人在您进行自己的更改时推送包含新更改的分支，那么当您想要推送时，Git 也会告诉您本地分支与其上游分支存在分歧，所以你应该先拉，依此类推。 在这种情况下重要的是不

push --force

否则你同事的工作将被删除，他/她会非常沮丧。因此，在这种情况下，您确实必须首先

pull

（我建议

pull --rebase

不要创建合并提交，并保持历史记录更清晰，但这非常主观），然后

push

（在拉动之后，没有

--force

将需要）。

底线是，知道

git push --force

的作用，知道什么时候可以用本地覆盖上游（然后你可以用力推），什么时候不行（你需要拉）。

回到你原来的案例，你重新调整了你的分支，所以它发生了分歧（根据定义），所以如果你在分支上单独工作或者你确保没有人同时在它上面推送任何东西，

git push --force

是你需要什么。

Answer 2

代替

git push --force

，您可以使用

git push --force-with-lease

，如果将任何新提交添加到远程分支，它会失败