如何解决在推送之前管理从开发分支到功能的更改 (git)
我过去工作的大多数团队在使用 Git 时都遵循相同的工作流程(有一些微小的变化):
- 拉动
develop
分支 (git checkout develop
) - 从中创建一个新的功能分支 (
git checkout -b feature/XYZ-123
) - 做你的工作
- 当您准备好创建 PR 时,添加并提交您的更改 (
git add . && git commit -m "some commit message"
),然后将develop
重新选中,将其拉出 (git checkout develop && git pull
) - 切换回您的功能分支并将
develop
合并到其中 (git checkout feature/XYZ-123 && git merge develop
) - 最后推送 (
git push -u origin feature/XYZ-123
) 并创建 PR
我们将其称为“合并方法”。好处是自您创建分支以来对 develop
的任何更改现在都合并到您的分支中。因此,当您创建 PR 时,与 develop
之间不存在合并冲突,并且代码审查人员可以看到您的分支与 develop
之间的清晰、无冲突的差异。
我现在在一个团队中工作,该团队在合并步骤之前都有类似的流程,但随后他们没有将 develop
合并到我的功能分支中,而是要求从 origin/develop
重新设置基准。所以实际步骤是:
git checkout develop
git checkout -b feature/XYZ-123
- 做你的工作
git add . && git commit -m "some commit message"
git checkout develop && git pull
git checkout feature/XYZ-123
- 从
origin/dev
变基 git push -u origin feature/XYZ-123
我们将其称为“Rebase 方法”。它也产生合并无冲突 PR,但显然它必须与上面解释的合并方法有不同的优点/缺点。
我想知道这些优点/缺点是什么。合并方法有什么特点是 Rebase 方法缺乏的,反之亦然?什么时候应该使用一种方法而不是另一种方法?
解决方法
但显然它必须与上面解释的合并方法有不同的优点/缺点
不是真的。在反向合并(如我所说)和 rebase 之间,最终效果完全相同,即尝试从 develop
中获取所有最近的更改,以便 (1) 可以准确地测试功能分支(2) 合并到 develop
时发生合并冲突的机会减少了。
反向合并和变基之间的主要明显区别是在功能分支上缺少额外的合并提交。这使得 rebase 具有吸引力。所以:
- 历史上的变基看起来更清晰,因为您似乎是从更近的
develop
状态开始的。
但这里有一些反诉:
-
如果出现冲突,重新设置基准会使解决这些冲突变得更加困难。
-
push 形成 pull request 后不能 rebase,因为这样会重写共享历史;而您可以随时反向合并。
我个人两个都用!我在初始推送之前变基以形成拉取请求;如果拉取请求存在很长时间,我会定期反向合并,尤其是在实际批准和合并之前。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。