基础产品功能合并至客户特定分支的最优策略及自动化咨询
基础功能向客户特定分支合并的最优自动化策略
一、先把分支规矩立清楚
- 所有新基础功能必须在独立feature分支开发,比如
feature/wechat-pay,合并到主分支(main)前必须过PR评审、全量自动化测试,确保基础代码的稳定性。 - 客户分支是长期稳定分支,只接受主分支的同步合并或客户专属需求的小改动,绝对禁止直接在客户分支上开发通用基础功能。
二、核心合并策略选哪种?
1. 定期全量同步(首推)
- 固定周期(比如每周一凌晨)把
main分支合并到所有客户分支,避免代码差异攒得太大,冲突爆发式增长。 - 合并优先用
git merge --no-ff,保留完整的合并历史,后续查冲突来源一目了然。如果团队习惯线性历史,且冲突极少,也可以用git rebase,但要注意rebase会改写历史,必须团队达成共识。
2. 按需增量同步
- 如果部分客户不需要全部新功能,只把他们需要的特定feature分支(已经合并到
main的)cherry-pick到对应客户分支;或者直接把feature分支merge到客户分支(前提是该feature已经通过main的验证)。 - 这种方式更适配客户需求差异化大的场景,减少不必要的代码引入。
三、自动化怎么搞?
1. CI/CD工具配置自动同步(以GitHub Actions为例)
直接写个定时执行的工作流,支持手动触发,核心代码如下:
name: Sync Main to Client Branches on: schedule: - cron: '0 0 * * 1' # 每周一凌晨0点执行 workflow_dispatch: # 允许手动触发同步 jobs: sync-branches: runs-on: ubuntu-latest steps: - name: 拉取全量代码 uses: actions/checkout@v4 with: fetch-depth: 0 # 必须拉取全部历史,否则合并会出问题 - name: 同步main到client-A run: | git checkout client-A git pull origin client-A git merge origin/main --no-ff -m "Auto-sync main to client-A $(date +'%Y-%m-%d')" git push origin client-A continue-on-error: true # 某分支失败不影响其他分支同步 - name: 同步main到client-B run: | git checkout client-B git pull origin client-B git merge origin/main --no-ff -m "Auto-sync main to client-B $(date +'%Y-%m-%d')" git push origin client-B continue-on-error: true
- 冲突处理:如果同步时出现冲突,CI会直接失败,这时得手动拉取客户分支,解决冲突后重新触发同步。可以在工作流里加个通知步骤,冲突时发Slack或邮件提醒负责人。
2. 提前堵冲突:预合并测试
在基础功能合并到main前,强制跑一次和各客户分支的预合并测试,提前发现冲突并解决,别等同步到客户分支才炸。
比如在feature分支的PR里加个步骤:
git checkout client-A git merge feature/wechat-pay npm run client-A-test # 跑客户A的专属测试用例 git reset --hard HEAD~1 # 重置临时合并,不污染分支
四、避坑关键点
- 客户代码隔离:所有客户定制化代码必须放在独立目录(比如
client-custom/client-A/)或用专属命名空间,别和基础代码混在一起,从根源减少冲突。 - 打标签留后路:每次同步完成后,给客户分支打个版本标签,比如
client-A-v2.3.0-sync-20240520,出问题能快速回滚。 - 回滚要果断:如果同步后客户分支出问题,直接用
git revert撤销合并提交,或者回滚到同步前的标签,先保客户业务稳定,再排查问题。
内容的提问来源于stack exchange,提问作者Tiago Francisco
相关产品推荐
相关产品推荐

