使用Git拆分项目产品版本的最佳实践及临时版本构建咨询

针对你需要基于旧生产版本制作临时修复、同时分离后续开发的场景，提供以下几种规范且高效的Git方案，适配前后端双仓库的情况：

方案1：标准Hotfix分支工作流（推荐，符合Git规范） #

这是Git Flow中针对生产紧急修复的标准流程，能清晰区分临时修复与后续开发，且方便同步修复到各分支：

1. 定位稳定生产版本提交：找到最新无问题的生产版本对应的master提交哈希（记为prod-commit-hash，如果之前给生产版本打了标签，直接用标签名更方便，比如v2.0.0）
2. 创建Hotfix分支：在前后端仓库分别执行：

   # 拉取最新master代码
   git checkout master
   git pull origin master
   # 从生产版本提交创建hotfix分支
   git checkout -b hotfix/temp-minor-fix prod-commit-hash
   

3. 完成微小修复并提交：在hotfix分支上修改那2行代码，然后提交：

   git add .
   git commit -m "hotfix: 修复[具体问题描述]（2行代码调整）"
   

4. 构建部署与同步修复：
   • 触发Jenkins构建该hotfix分支，部署到测试环境验证后，发布为临时生产版本
   • 将修复同步到master（后续版本的基础）和正在开发的feature分支：

     # 合并到master
     git checkout master
     git merge hotfix/temp-minor-fix --no-ff
     git push origin master
     # 合并到开发中的feature分支（示例：feature/new-module）
     git checkout feature/new-module
     git merge hotfix/temp-minor-fix --no-ff
     git push origin feature/new-module
     

5. 清理分支（可选）：修复同步完成后，删除本地和远程的hotfix分支：

   git branch -d hotfix/temp-minor-fix
   git push origin --delete hotfix/temp-minor-fix
   

方案2：轻量临时分支+Cherry-Pick（适合极小修复） #

如果不想用标准Hotfix流程，可优化你原本的思路，无需重新克隆仓库，用Cherry-Pick精准同步修复：

1. 创建临时修复分支：

   # 直接从生产版本提交创建临时分支
   git fetch origin master
   git checkout -b temp-fix-branch prod-commit-hash
   

2. 完成修复并提交：同方案1的步骤3，记录下修复提交的哈希（记为fix-commit-hash）
3. 构建部署临时版本：用该临时分支触发Jenkins构建部署
4. 同步修复到其他分支：用Cherry-Pick把修复提交单独同步到master和开发分支：

   # 同步到master
   git checkout master
   git cherry-pick fix-commit-hash
   git push origin master
   # 同步到开发分支
   git checkout feature/new-module
   git cherry-pick fix-commit-hash
   git push origin feature/new-module
   

双仓库与Jenkins适配注意事项 #

• 前后端的修复分支保持命名一致（比如都用hotfix/temp-minor-fix），且确保两个仓库都是基于同一生产版本提交创建分支，避免版本不匹配问题
• 可在Jenkins流水线中新增规则：当推送hotfix/*或temp-fix-*前缀的分支时，自动触发构建部署，复用现有feature分支的构建逻辑

后续Git规范优化建议 #

• 每次发布生产版本时，在对应master提交上打标签：git tag -a v2.0.0 -m "生产正式版本v2.0.0"，后续定位生产版本只需git checkout v2.0.0，无需记忆哈希
• 坚持用feature分支做新开发，master只用于合并已测试完成的feature或hotfix分支，保持分支职责清晰

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