变基后的Git推送

Question

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

git checkout master
git pull
git 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://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.

我在本地有：特性分支，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 做了什么，知道什么时候可以用本地覆盖上游（然后你可以推力），什么时候不可以（你需要拉）。

回到你原来的情况，你重新设置了你的分支，所以它发生了分歧（根据定义），所以如果你独自在分支上工作，或者你确保在此期间没有人推任何东西，@987654331 @ 是你需要的。