我对Github分叉了。我设置了我的fork的本地版本，以通过adding it as upstream从原始存储库进行更新。
现在，我创建了一个功能分支，进行了更改并将其拉至原点存储库。由于变化很大，因此回购所有者还没有接受拉动。
同时，我从原始存储库的主服务器进行了git pull upstream master次更新，从而使我的master分支发生了几次变化，因此我的功能分支与master分支不同步。
我需要同步它们，因为我需要从两个分支生成文档并进行比较。
我所知道的（不是git pro）是，我将首先在我的功能分支中本地提交隐匿的更改，然后再在本地将我的分支基于主节点（或在git lingua中如何称呼）。
但是我读到，重新定基会在其他人的存储库中造成混乱。
那我该怎么做呢？我应该关闭我的PR，在新分支上重新定基吗？我想如果我能防止这种情况，因为我不想污染原始的仓库。
答案 0 :(得分：1)
在许多git工作流程中，您可以区分功能分支和“稳定”分支。
以以下示例为例：（任意工作流程，可能与您的工作流程有所不同，只是为了说明稳定/功能分支）并考虑其历史：
-----------------D <<< feature-bar
/ \
---A------------E-------H---J <<< master
\ / \ /
B--------C F---G---I <<< feature-foo
master是一个稳定的分支，是永久的，反映了应用程序的当前状态。在某些工作流程中，您具有更稳定的分支，一个用于登台，一个用于开发，一个用于稳定生产状态，等等。
另一方面，特征分支是易变的和可抛弃的。每个文件都是为特定需要而创建的（通常是错误修复，新功能），并在最终合并到其稳定的目标位置时被删除。 （在上面的模式feature-bar和feature-foo中，但是我们还可以猜测到某个时刻指向C的分支，在E之后已被删除合并。）
当开发人员独自在其功能分支上工作时（如果尚未合并），他们在其分支上所做的任何事情都会保留在其上，并且 历史部分可以通过重新设置基准或任何其他方式进行更改操作，不会对其他任何人造成不良影响。
当然，在大多数情况下，稳定分支的基础是很大的禁忌，因为所有其他开发人员都共享这部分回购历史记录，并且必须解决潜在的棘手冲突。
我在架构和说明中使用了合并，但是使用rebase的工作流也将在稳定/功能分支之间进行相同的区分。
如果您一个人在功能分支上工作，然后创建一个PR，然后意识到您必须对其进行基础设置，没有麻烦，那么在您推销PR的新历史之后，PR就会自动更新。分支，并且目标分支的历史不会被弄乱。
更麻烦的是重新建立与他人共享的稳定分支，因为这会导致历史冲突，是的，解决起来很麻烦。
您链接的文章非常有趣，我同意要点，但是请注意，当您发现git并尝试有效使用它时，它可能会误导您。这些是相当高级的考虑因素，如果在没有明确理解的情况下遵循，可能会引发“ cargo-cult”实践。变基是一个有用的工具，请不要丢掉它。