手动合并到主分支参考
本文用于记录两个相关仓库从功能分支合并到主分支的通用流程。示例只使用泛化名称,复制到公开笔记时按需替换路径和分支名。
适用场景
- 功能已经开发完成,并且已经在测试或生产环境验证过。
- 需要把前端仓库和后端仓库的功能分支同步合并到
master。 - 两个仓库分别独立管理 Git 历史,需要分别检查、合并和推送。
合并前检查
先分别进入两个仓库,确认工作区干净:
cd<frontend-repo>gitstatus--short--branchcd<backend-repo>gitstatus--short--branch如果有未提交改动,先确认这些改动是否属于本次发布:
- 属于本次发布:先提交到功能分支,再合并。
- 不属于本次发布:先暂存到 stash,或切到新的临时分支保存。
- 不确定来源:不要直接丢弃,先确认再处理。
拉取远端信息
分别获取远端主分支和功能分支:
cd<frontend-repo>gitfetch origin master<frontend-feature-branch>cd<backend-repo>gitfetch origin master<backend-feature-branch>检查本地master是否和远端一致:
gitrev-list --left-right--countmaster...origin/master输出0 0表示本地master与远端master一致。
检查功能分支相对master的提交数量:
gitrev-list --left-right--countmaster...<feature-branch>如果输出类似0 69,表示master是功能分支祖先,可以使用 fast-forward 合并。
合并前端仓库
cd<frontend-repo>gitswitch mastergitmerge --ff-only<frontend-feature-branch>如果成功,会看到Fast-forward。如果失败,说明不能快进合并,需要先检查是否有并行提交或冲突。
合并后端仓库
cd<backend-repo>gitswitch mastergitmerge --ff-only<backend-feature-branch>同样优先使用--ff-only,这样主分支历史会保持线性,更容易回溯。
推送主分支
确认两个仓库合并成功后,分别推送:
cd<frontend-repo>gitpush origin mastercd<backend-repo>gitpush origin master推送完成后,再确认主分支状态:
gitstatus--short--branchgitlog--oneline--decorate-5如果不能 fast-forward
如果git merge --ff-only <feature-branch>报错,先不要强推。按下面顺序处理:
gitfetch origin master<feature-branch>gitswitch mastergitpull --ff-only origin mastergitmerge<feature-branch>如果出现冲突:
gitstatus--short打开冲突文件,保留正确内容后执行:
gitadd<resolved-files>gitcommitgitpush origin master冲突处理完成后,建议至少运行一次项目自身的基础检查,例如类型检查、单元测试、构建或核心接口冒烟测试。
推荐核对清单
- 工作区在合并前是干净的。
- 本地
master与origin/master一致。 - 功能分支已经包含本次要发布的全部提交。
- 前端仓库已合并到
master。 - 后端仓库已合并到
master。 - 两个仓库的
master都已推送远端。 - 如有数据库变更,已确认线上应该执行的是增量 SQL,而不是全新初始化 SQL。
- 如有部署流程,已确认部署使用的是更新后的
master。
常用命令速查
gitstatus--short--branchgitfetch origin master<feature-branch>gitrev-list --left-right--countmaster...origin/mastergitrev-list --left-right--countmaster...<feature-branch>gitswitch mastergitmerge --ff-only<feature-branch>gitpush origin mastergitlog--oneline--decorate-5