时间戳

首页 > 解决方案 > Rebase 拉取的分支尚未被 repo 所有者合并

git - Rebase 拉取的分支尚未被 repo 所有者合并

问题描述

我在 Github 上创建了一个项目。我已经设置了我的 fork 的本地版本，通过将其添加为 upstream来从原始 repo 进行更新。

现在我创建了一个功能分支，进行了更改并拉到了原始存储库。由于变化很大，回购所有者尚未（尚未）接受拉动。

同时，我从原始 repo 的 master 更新了我的 master 分支git pull upstream master几次，所以我的 feature 分支与 master 分支不同步。

我需要同步它们，因为我需要从两个分支生成文档并进行比较。

我所知道的（我不是 git pro）是我会首先在我的功能分支中本地提交我隐藏的更改，然后也在本地将我的分支重新定位到 master（或者在 git lingua 中如何调用它）。

但我读到变基会在其他人的回购中造成混乱。

那么我该怎么做呢？我应该关闭我的 PR，在新分支上重新设置基础并再次拉动它吗？我想如果我能阻止这种情况，因为我不想污染原始回购。

标签： gitgithubbranchrebasepull-request

解决方案

在许多 git 工作流中，您可以区分功能分支和“稳定”分支。

举这个例子（任意工作流程，可能与你的不同，但只是为了说明稳定/功能分支）并考虑它的历史：

     -----------------D <<< feature-bar
    /                  \
---A------------E-------H---J <<< master
    \          / \         /
     B--------C   F---G---I <<< feature-foo

master是一个稳定的分支，它是永久的并且反映了应用程序的当前状态。在某些工作流中，您有更稳定的分支，一个用于暂存，一个用于开发，一个用于稳定的生产状态，等等。

另一方面，特征分支是易变的和一次性的。每个都是为特定需求（通常是错误修复、新功能）而创建的，并在最终合并到其稳定目标时被删除。（在上面的模式中，feature-barand feature-foo，但我们也可以猜到有一个分支指向某个点，合并C后已被删除。）E

当开发人员单独在其功能分支上工作时，如果尚未合并，则无论他们在其分支上所做的任何事情都将保留在该分支上，并且可以通过变基或任何其他操作来更改历史记录的一部分，而不会对其他人产生不良影响。

当然，在大多数情况下，rebase 一个稳定的分支将是一个很大的禁忌，因为所有其他开发人员共享这部分 repo 历史，并且必须解决潜在的令人讨厌的冲突。

我在我的架构和解释中使用了合并，但是使用 rebase 的工作流也会在稳定/功能分支之间做出同样的区分。

如果你单独在一个特性分支上工作，然后创建一个 PR，然后意识到你必须对其进行 rebase，没问题，PR 会在你推送分支的新历史后自行更新，并且不会出现任何问题目标分支的历史。

更成问题的是 rebase stable 分支，与其他人共享，因为这会导致历史冲突，是的，解决起来可能很麻烦。

您链接的文章非常有趣，我同意主要观点，但是请注意，当您发现 git 并尝试有效地使用它时，它可能会产生误导。这些是相当高级的考虑，如果在没有明确理解的情况下遵循，可能会引发“货物崇拜”的做法。Rebase 是一个有用的工具，不要扔掉它。

推荐阅读