Git合并请求的思考
12/03
本文最后更新于
2024年12月03日，已超过
88天没有更新。如果文章内容或图片资源失效，请留言反馈，我会及时处理，谢谢！
前两天将开发的一个特性（feature）分支内容通过PR(Pull Request)合并请求方式合并到主线develop开发分支上。合并完成后复盘整个过程发现了一个问题：合并到develop分支的提交记录太多了。下面介绍了合并过程以及一些思考。
- 在个人特性分支上开发过程中，非常频繁的提交，虽然有意识的使用
amend修补提交方式合并提交，但结果提交记录仍然过多。对于一个特性分支来说，它的使命就是为了完成一个feature的开发，理论上应该只有一个commit提交记录。实际情况可能会有几个commit记录，但不应该太多。 - 为了保持develop分支开发记录是一个线性记录，先通过变基（rebase）操作使个人特性分支变基到develop分支最新提交上，使特性分支看起来像是在develop最近提交基础上开始开发的。
- 将个人特性分支推送到远程仓库，通过网页界面的PR按钮申请合并到develop分支。
- 然后仓库管理员通过变基后快进方式合并特性分支内容。
以上就是基于分支策略的工作流。这种变基后快进方式会将特性分支开发提交记录都会保存下来并维护develop分支线性记录特点。但这也带来一个问题：如果没有仔细整理过特性分支的提交记录的话，在develop分支上这些记录会显得杂乱，对其他人来说可能没有意义。
因此，前文介绍的Git提交粒度的“适中”原则很有必要。比较好的实践流程如下：
- 在开发过程中，使用
amend提交尽可能将subtask合并成一个提交记录； - 在开发结束后、发起合并请求前使用
git rebase -i进行提交记录的整理，使用squash压缩提交。； - 在PR期间如果需要修正，使用
amend提交方式； - PR通过后使用变基后快进方式合并。
参考资料
