在推送 (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，但显然它必须与上面解释的合并方法有不同的优点/缺点。

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

Answer 1

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

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

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

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

但这里有一些反诉：

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

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

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