如何通过Pull Requests完成GitFlow版本发布的完整流程？

你当前的操作可以满足PR流程要求，但不属于最优方案，存在冗余步骤和潜在风险：

• 多余的中转分支：额外创建release/x-target分支属于无意义的操作，GitFlow原生设计中release分支本身就是用来对接master、develop合并的专属分支，不需要额外新增中转层。
• 合并参数风险：git merge -X theirs release/x会强制优先采用release分支的内容覆盖master侧改动，如果master上存在未同步到release、develop的hotfix提交，这一步会直接抹除热修复内容，引发线上故障。

适配PR流程的标准GitFlow发布步骤 #

1. 从最新的develop分支切出release/x分支，在该分支上完成发布前测试、版本号更新、小BUG修复等操作，所有改动直接提交到release/x。
2. 发起release/x到master的PR：
   • 若出现合并冲突，在本地拉取最新的master和release/x分支，切换到release/x分支执行git merge master（偏好线性历史可以用git rebase master），手动逐行解决所有冲突后推送到远程release/x，PR会自动更新消除冲突。
   • 解决冲突时必须逐一核对两边改动，确认保留内容，禁止直接用自动覆盖参数处理冲突。
3. PR审核通过后合并到master，给master分支打上对应版本号的tag，执行线上发布。
4. 发起release/x到develop的PR，如有冲突按相同规则手动解决后合并，保证develop分支同步所有发布相关的改动。
5. 流程结束后删除远程和本地的release/x分支即可。

该方案既符合GitFlow的原生设计逻辑，也满足PR审核的要求，分支管理更清晰，冲突处理的记录可追溯，同时避免了自动覆盖参数带来的线上风险。

内容的提问来源于stack exchange，提问作者Aaron Ullal