Git:我如何协调一个基于本地的功能分支和它的远程对等项？

Question

我已经在master上做了分支，在feature-branch上做了工作。已将feature-branch推到遥控器上。其他人的工作被合并到master中。我将更改提取到master，然后根据更新后的master重新构建我的本地feature-branch版本。

下一次我尝试将feature-branch推送到遥控器时，我无法将其推送到遥控器上，因为它与远程版本不同步。我在单独工作时的解决方案是强制推送，但有没有更好的解决方案？我的一个同事，而不是强制推，做了一个拉，然后推，但结果看起来很奇怪(其他人的提交出现在做一个拉-请求的主人)。

Answer 1

永远不要改变你推送的分支的基址。

你永远不应该在历史公之于众之后改变它(它是通过推送变成的)。Rebase改变历史记录(例如，修改)。

你可能会想：“我可以强迫它，对吧？”否:每个拉出feature-branch的人都将需要强制下一次拉入。更糟糕的是:如果有基于原始feature-branch的提交，那么它们也需要更改。这很快就会变成一场噩梦。

在这一点上，唯一的解决方案是恢复你的rebase并将master合并到feature-branch中。

一般来说，我会建议永远不要改变基数，避免快进合并。也许有一天，你会为拥有一段有意义的历史而感到高兴，即使它看起来很丑陋。如果线性历史不代表实际的历史，那么它不会获得任何好处。

Answer 2

只有当开发人员很少，你可以用一只手计算他们的数量，并且你可以与他们联系并让他们都修复他们的repoes时，重新建立你已经推送的东西的基础才是真正实用的。

如果我想要发布一些正在进行的工作，但仍然保留以后更改其基址的选项，我会执行以下两种操作之一：

• 通过某种命名约定将其推送到不是“神圣的”存储库，人们知道它只是为了在
• 周围抓来抓去，并明确地将其标记为“由您承担风险，以后可能会重新建立基础”。