在本地rebase之后更新git pull请求

Question

我最近遇到了一种情况，当我从本地上游进行rebase，然后尝试在github上推送到我的本地PR时，我的错误修复请求被搞砸了。 我想知道我是否采取了正确的方式，或者我的工作流程需要改变。

基本上，我遵循了这个工作流程：

• 在github上分叉
• 在本地计算机上克隆。设置原点（自动）和上游遥控器。
• 创建fix分支。
• 编辑文件。
• git push -u origin fix并从该分支机构提交PR。
• 同时，我的修复程序中的一个文件在主存储库中得到了更新。所以我git fetch upstream; git merge upstream/master
• 我更新了我的来源/主人：git push。
• 然后我在git rebase master分支上本地fix，由于冲突而手动合并它们。 git add; git rebase --continue。
• 然后我尝试了git push，那就是出错的地方。似乎没有一个很好的干净方法将rebase fix分支放入我的公关。

所以我想知道我是否错过了一步，或者我是否应该改变一步。我不确定git push origin是否正确，或者是否需要更具体（例如，使用分支名称）。应该/我可以在最后一步尝试使用git push --force（PR的一部分在我的github存储库中，但很可能没有其他地方被删除）吗？

Answer 1

不要在拉取请求中引入合并。正确的工作流程如下：

• 叉
• 克隆
• 科
• [核心编码工作]
• [提交（S）]
• Rebase（到上游/主站），例如使用git pull --rebase upstream master
• 推
• 创建拉取请求。

这样就可以避免合并提交，最终在pull请求中提交基于上游存储库当前 master 的干净提交。

如果您在rebase之前推送，则必须使用-f执行强制推送，以便在重新定位后再次推送，因为您在rebase期间重写了历史记录。

值得记住的一点：合并（不是快进或重新定义）应该从不出现在简单的修复/功能分支中 - 就像你永远不应该重写＃34中的历史记录一样;主＆＃34;其他人可能以自己的工作为基础的分支。

Answer 2

  

我应该/可以在最后一步尝试使用git push --force（PR的一部分在我的github存储库中，但很可能没有其他地方被拉掉）？

是。如果您的本地分支不是远程分支的后代，则需要强制推送分支，而不是在重新分支之后。

您应该了解强制推送给可能已经覆盖了更改的其他开发人员的后果，我不推荐它： 更好地使用简单拉动引入上游变化。