在推送之前管理从开发分支到功能的更改 (git)

Question

我过去工作的大多数团队在使用 Git 时都遵循相同的工作流程（有一些微小的变化）：

1. 拉动 develop 分支 (git checkout develop)
2. 从中创建一个新的功能分支 (git checkout -b feature/XYZ-123)
3. 做你的工作
4. 当您准备好创建 PR 时，添加并提交您的更改 (git add . && git commit -m "some commit message")，然后将 develop 重新选中，将其拉出 (git checkout develop && git pull)
5. 切换回您的功能分支并将 develop 合并到其中 (git checkout feature/XYZ-123 && git merge develop)
6. 最后推送 (git push -u origin feature/XYZ-123) 并创建 PR

我们将其称为“合并方法”。好处是自您创建分支以来对 develop 的任何更改现在都合并到您的分支中。因此，当您创建 PR 时，与 develop 之间不存在合并冲突，并且代码审查人员可以看到您的分支与 develop 之间的清晰、无冲突的差异。

我现在在一个团队中工作，该团队在合并步骤之前都有类似的流程，但随后他们没有将 develop 合并到我的功能分支中，而是要求从 origin/develop 重新设置基准。所以实际步骤是：

1. git checkout develop
2. git checkout -b feature/XYZ-123
3. 做你的工作
4. git add . && git commit -m "some commit message"
5. git checkout develop && git pull
6. git checkout feature/XYZ-123
7. 从 origin/dev 变基
8. git push -u origin feature/XYZ-123

我们将其称为“Rebase 方法”。它也产生合并无冲突 PR，但显然它必须与上面解释的合并方法有不同的优点/缺点。

我想知道这些优点/缺点是什么。合并方法有什么特点是 Rebase 方法缺乏的，反之亦然？什么时候应该使用一种方法而不是另一种方法？

Answer 1

<块引用>

但显然它必须与上面解释的合并方法有不同的优点/缺点

不是真的。在反向合并（如我所说）和 rebase 之间，最终效果完全相同，即尝试从 develop 中获取所有最近的更改，以便 (1) 可以准确地测试功能分支(2) 合并到 develop 时发生合并冲突的机会减少了。

反向合并和变基之间的主要明显区别是在功能分支上缺少额外的合并提交。这使得 rebase 具有吸引力。所以：

• 历史上的变基看起来更清晰，因为您似乎是从更近的 develop 状态开始的。

但这里有一些反诉：

• 如果出现冲突，重新设置基准会使解决这些冲突变得更加困难。

• push 形成 pull request 后不能 rebase，因为这样会重写共享历史；而您可以随时反向合并。

我个人两个都用！我在初始推送之前变基以形成拉取请求；如果拉取请求存在很长时间，我会定期反向合并，尤其是在实际批准和合并之前。