什么是正确的方式来做一个git rebase?

Question

我有一个github存储库，它遵循以下分支策略:-

1. 有一个长期存在的主分支
每当有新特性需要处理时，
2. 特性分支就会从master中被切断。如。特性/功能/B
3. 故事、缺陷或任务分支从它们所属的单个特征分支中被切断。
4. 多个功能可以并行开发。
故事、缺陷、任务分支被合并到各自的特性分支，当这些分支的工作完成时。
5. 每个特性完成后，该特性上所做的工作必须合并到主分支

现在，假设功能/A和功能/B正在同时进行，负责功能/A的团队首先完成了功能，并提出了一个简单的Pull Request，将更改合并到主分支。

在feature/B的工作完成后，我们想要在master的基础上重新建立它，以便在提出pull请求将feature/B分支的更改合并到master之前，从master(包含feature/A的工作)获得最新的更改。

在这种情况下做rebase的正确方法是什么?

以下是我尝试过的两种方法

方法一:-

1. 在本地工作副本上从feature/B分支创建一个新的分支，例如-任务/变基
运行git rebase master
2. 解决冲突并迭代地继续重置，直到完成。
3. 将任务/重基分支推送到远程存储库。
4. 将PR从task/rebase提升到master。

关于此方法的问题1 -

1. PR是否从task/rebase提升到feature/B?在这种情况下，它无论如何都不允许合并更改。
2. 如果遵循这种方法，如何在步骤5之后获得feature/B分支的更改?

方法2:-

1. 在本地工作副本上签出feature/B分支。
运行git rebase master
2. 解决冲突并迭代地继续重置，直到完成。
3. 从远程特性/B分支拉取，因为本地副本已经分叉，并且不允许在拉取之前进行推送。再次解决一些冲突。
4. 将更改推送到远程存储库，并将PR从功能/B分支提升到主分支。

关于这个方法的问题2 -

1. 这是正确的方式做rebase?当步骤5中的PR被触发时，我看到重复的提交。

Answer 1

Git允许您重写历史(rebase)，并通过git push -f强制到远程(假设所需的权限)。

另一种组合不同历史的方法是合并。例如，您可以首先将master合并到feature/B中以解决冲突，而不是进行重基。或者直接合并到master.

如果你有很多人在做特性/B，重定基础通常不是最好的方法，除非所有的工作都停止了，每个人都准备关闭分支。否则，它可能会造成竞争条件，在您开始重置之后，但在您强制推送之前，有人会推送更改，从而失去他们的工作。

如果你坚持重新定位，方法1不会给你任何好处。方法2几乎是正确的方法。唯一的问题是第4步是撤消所有的好处的重基。您不需要将feature/B与origin/feature/B合并，而是需要执行git push --force来使用新的提交历史更新远程。

正如方法2，步骤4所暗示的，合并可能仍然是您的情况下最好的方法。