我们的Git工作流
2026-10-21 04:29:33
你们的Git工作流是一个高效且结构化的开发流程，它基于Git的版本控制功能，并结合了团队的特定需求和习惯。以下是对你们Git工作流的详细解释：
一、分支结构
prod分支
用于生产部署，所有上线到生产环境的代码都来源于此分支。
需要对每次上线的代码打tag，以便后续可能需要的回滚操作。
master分支
用于CI（持续集成），旨在提供一个稳定的测试环境。
合并prod分支的代码，确保测试环境与生产环境保持一致。
dev分支
对本次迭代功能进行开发，所有开发人员都有权限向此分支提交代码。
开发人员在此分支上进行日常开发，前端使用mock接口，后端在本地测试接口。
feature分支
基于dev分支的下一迭代功能开发，一个功能一个分支。
命名格式为：feature-${根据功能取个英文名字}。
开发完成后，合并到dev分支，并删除该feature分支。
hotfix分支
基于prod分支修复生产环境中的bug。
命名格式为：hotfix-{index}，其中index是迭代号，从1开始，表示上线顺序。
修复完成后，合并到prod及dev分支，并打tag发布生产。
二、工作流程
确定上线功能
每周一确定本周要上线的功能，开发人员明确自己的开发任务。
日常开发
所有开发人员在dev分支上进行开发，前端使用mock接口，后端在本地测试接口。
后端人员开发完某完整功能的全部接口后，合并代码到master，触发CI，并通知前端人员可对接真实接口。
相关前端人员调试真实接口，完成后合并到master，触发CI，并通知相关后端人员，相互验证。
合并到prod
如果一切顺利，周五时相关人员将master分支合并到prod，并打一个tag，之后便可部署到生产环境。
超前开发
在迭代周期内，如果开发人员有空余时间，可以基于dev分支checkout一个feature分支进行超前开发。
超前开发的功能在下次迭代时再合并到dev分支，并删除该feature分支。
紧急修复
如果在生产环境中发现bug需要紧急修复，则基于prod分支checkout一个hotfix分支进行修复。
修复完成后，合并到dev及prod分支，并打tag发布生产。
三、注意事项
- CI触发：只对master分支进行CI，避免在dev分支上频繁触发CI导致开发阻塞。
- 分支命名：遵循约定的命名规范，以便团队成员能够清晰地理解每个分支的用途。
- tag管理：每次上线前打tag，记录上线版本的信息，方便后续回滚和追踪。
四、示例图片
以下图片展示了你们Git工作流中的一些关键步骤和分支结构：
综上所述，你们的Git工作流是一个结构清晰、流程规范的开发流程，它能够帮助团队成员高效地协作开发，确保代码的质量和稳定性。
热门标签
