对于Git来说，我通常都很有能力，但我不太确定在这种情况下发生了什么，以及什么是最好的解决方案。
场景：
git pull并查看我的队友的几个提交。 git checkout featureBranch后跟git rebase dev重播我对最新开发者的更改（据我了解）。 git status表示需要本地和原点featureBranch分歧git pull。 git pull会导致提交消息终端打开。 git status显示git push是必需的。 git push之后，我的公关显示了我的同事来自我的分支机构的所有提交，而不仅仅是修复。在这种情况下我做错了什么？我想继续单独处理我的featureBranch，直到它被修复，并且在那时，确保我的更改应用于最新的dev避免冲突。在这种情况下，我的团队鼓励变革。
为什么在我的PR featureBranch＆gt;＆gt;中显示dev的新提交？他们已经在dev上了吗？
将我的公关回到原始提交的最佳解决方案是什么？我不是指在这里压缩，我的意思是开发提交不应该在这里。
答案 0 :(得分：4)
在这种情况下，我做错了什么？
第二个git pull。一旦你重新定位，预计git status会告诉你你已经分歧了
但是你应该从那里强制推动（git push --force），用新的替换PR分支的远程历史。
如果你是唯一一个从事PR工作的人，那就更是如此。
答案 1 :(得分：3)
git status表示本地和原点featureBranch有分歧的git pull是必需的。
当您重新定位时，您实际上会改变分支的历史记录。此历史记录与origin的历史记录不同，但这很好，因为它是您想要的。您在此步骤中应该做的是通过将push -f运行到origin/yourFeatureBranch来强制推送。
答案 2 :(得分：3)
git status表示本地和原点featureBranch需要分散git pull。
这是预期的，因为与原始版本（上游跟踪）相比，您重写了本地分支历史记录。
git pull导致提交消息终端打开。
是的，你想在这里做的是不做拉，并在本地合并，或强制推上游以反映你在远程中的重新分支版本。通过拉你然后再将原始历史合并到你的重新定位的历史中，这违背了变基的目的。
在这种情况下，我做错了什么？我想继续单独处理我的featureBranch，直到它被修复，并且在那时，确保我的更改应用于最新的dev以避免冲突。在这种情况下，我的团队鼓励变革。
（在你的情况下）你所做的“错误”是在重新定位后再次拉动分支。你应该小心强行推动（例如git push myremote mybranchname --force）。如果您养成了在强制推动时始终指定远程和分支名称的习惯，那么您不太可能覆盖您不期望的内容。
为什么我的PR featureBranch＆gt;＆gt;中显示dev的新提交？开发时他们已经开发了吗？
因为您已经重新定位，但是通过将原始版本拉回到您的重定格版本中来搞乱分支历史记录。您应该期望成功的rebase只在pull请求中显示您的提交。
将我的PR带回原始提交的最佳解决方案是什么？我不是说压扁在这里，我的意思是开发提交不应该在这里。
如果您上次推送到遥控器后没有更改任何其他内容，我建议您再次重置和重新定位：
git reset --hard yourremote yourbranchname
git rebase devbranch
git push yourremote yourbranchname --force
希望这有帮助。