核心是建立轻量有约束的Git工作流规范：主干稳定、MR/PR合入、CI通过、代码审查、关联任务编号；功能用feature/模块名-说明分支；紧急修复走hotfix并双线同步；提交遵循Conventional Commits；配套本地开发习惯。
PHP网站搭建版本控制，核心不是选哪个工具，而是让Git工作流真正跑起来。团队里没人拉代码、分支乱建、提交信息写“fix bug”——这些都不是技术问题，是流程没立住。关键在于用一套轻量但有约束力的规范，把日常开发动作固定下来。
主干必须稳定，所有变更走合并请求
main分支只允许通过Merge Request（MR）或Pull Request（PR）合入，禁止直接push。每次合入前，必须满足：CI流水线全部通过、至少一名同事完成代码审查、关联对应的任务编号（如Jira ID或GitHub Issue）。这样能守住生产环境的底线，避免“本地能跑，线上炸锅”。
功能开发用feature分支，命名带上下文
每个新需求或修复都从main拉出独立分支，格式统一为feature/模块名-简要说明，例如feature/api-user-list或fix/login-session-expire。分支生命周期明确：开发完成→推送到远程→发起MR→审查通过→自动合并→本地删除该分支。不保留长期存活的功能分支，避免偏离主干太远。
紧急修复走hotfix，双线同步保障一致性
线上突发问题必须从main分支拉hotfix分支，例如hotfix/db-connection-timeout。修复完成后，先合并回main并打tag（如v2.1.3），再同步合并到develop（如有）。这样确保热修既上线又进后续迭代，不会漏掉或重复。
立即学习“PHP免费学习笔记（深入）”；
提交信息按类型+范围+描述写清楚
拒绝模糊描述，采用Conventional Commits风格：type(scope): subject。常用类型包括：
- feat(auth): 添加微信登录支持
- fix(api): 修复用户列表接口分页偏移错误
- docs(readme): 更新部署说明中的PHP版本要求
- chore(composer): 升级monolog至v3.5.0
每条提交对应一个明确意图，方便生成CHANGELOG、定位问题、回滚特定功能。
本地开发习惯要配套跟上
每天开工第一件事是git pull origin main；改完代码先git status确认改动范围；提交前用phpcs --standard=PSR12检查风格；大功能提交前运行本地单元测试。这些动作不靠工具强制，靠每日站会提醒和Code Review时当面确认，慢慢就成了肌肉记忆。
