在推送之前管理从开发分支到功能的更改（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

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

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

Answer 1

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

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

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

• 变基在历史上看起来要干净得多，因为您似乎是从更近的 develop 状态开始分支的。

但这里有一些反诉：

• 如果有即将到来的冲突，变基会使解决这些冲突变得更加困难。

• 在推送形成拉取请求后你不能变基，因为这会重写共享历史；而您可以随时反向合并。

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