资源描述
本资源提供企业级 Git 工作流最佳实践指南，涵盖基于 Git Flow 的分支管理策略、Angular 提交规范及标准化协作流程。适用于研发团队规范版本控制、提升代码审查效率与 CI/CD 自动化集成。帮助开发者告别分支混乱，实现高效、安全的代码交付与发布管理。
详细内容
## 工作流概述
本指南基于经典的 Git Flow 模型进行优化，旨在为研发团队提供一套标准化、可追溯的 Git 版本控制工作流。通过严格的分支管理、规范的提交信息和清晰的协作步骤，确保代码从开发、测试到发布的整个生命周期安全、高效且可控。
## 分支策略与命名规范
- **main / master**: 生产环境代码，始终保持稳定，仅接受 release 或 hotfix 分支的合并，每次合并需打 Tag。
- **develop**: 开发主分支，包含下一个版本要发布的所有功能，是 feature 分支的基准。
- **feature/***: 功能分支，从 develop 切出，用于开发新功能或优化，完成后合并回 develop。
- **release/***: 发布分支，从 develop 切出，用于发布前的最终测试和 Bug 修复，完成后合并至 main 和 develop。
- **hotfix/***: 紧急修复分支，从 main 切出，用于修复生产环境紧急 Bug，完成后合并至 main 和 develop。
## 提交信息规范 (Commit Message)
遵循 Angular 规范，格式为 `<type>(<scope>): <subject>`：
- **feat**: 新功能 (feature)
- **fix**: 修复 bug
- **docs**: 文档更新 (documentation)
- **style**: 代码格式调整（不影响代码运行的变动）
- **refactor**: 重构（即不是新增功能，也不是修改 bug 的代码变动）
- **test**: 增加测试或修改测试
- **chore**: 构建过程或辅助工具的变动
## 标准工作流操作步骤
### 步骤 1：同步主干与创建功能分支
在开始新功能开发前，确保本地 develop 分支是最新的，并基于此创建独立的功能分支。
```bash
git checkout develop
git pull origin develop
git checkout -b feature/user-login
```
### 步骤 2：本地开发与原子提交
在功能分支上进行开发，保持提交的原子性（一个 commit 只做一件事），并严格遵循提交规范。
```bash
git add .
git commit -m "feat(auth): 实现用户登录接口及基础校验"
```
### 步骤 3：推送分支与发起 Pull Request (PR)
开发完成后，将本地分支推送到远程仓库，并在代码托管平台发起 PR/MR，目标分支选择 develop。
```bash
git push origin feature/user-login
```
*动作：在平台填写 PR 描述，关联相关 Issue，并指定 Reviewer。*
### 步骤 4：代码审查 (Code Review) 与合并
团队成员进行代码审查。审查通过后，由 PR 发起人或 Maintainer 执行合并。推荐使用 **Squash and merge** 以保持 develop 分支历史整洁。合并后删除远程 feature 分支。
### 步骤 5：发布准备与热修复处理
- **常规发布**：从 develop 创建 `release/v1.0.0` 分支，进行集成测试。修复问题后，合并至 main（打 Tag `v1.0.0`）和 develop。
- **紧急修复**：从 main 创建 `hotfix/fix-crash` 分支，修复后合并至 main（打 Tag `v1.0.1`）和 develop。
## 注意事项与最佳实践
1. **保护核心分支**：在代码托管平台设置分支保护规则，禁止直接向 main 和 develop 推送代码，强制要求通过 PR 合并。
2. **集成 CI/CD**：配置自动化流水线，在 PR 创建时自动触发代码静态检查（Lint）和单元测试，测试通过后方可合并。
3. **保持分支短命**：Feature 分支存活时间尽量不超过一周，避免长期不合并导致后期解决冲突成本过高。
4. **及时清理分支**：PR 合并后，及时删除远程和本地的废弃分支，保持仓库整洁。
## 常见问题提示 (FAQ)
- **Q: 合并 PR 时遇到代码冲突怎么办？**
A: 在本地拉取最新的 develop 分支，使用 `git merge develop` 或 `git rebase develop` 解决冲突，测试无误后再推送到远程 feature 分支更新 PR。
- **Q: 提交历史太乱，如何清理？**
A: 在推送到远程前，可使用 `git rebase -i HEAD~n` 进行交互式变基，将多个零碎的 commit 压缩（squash）为一个逻辑完整的 commit。
- **Q: 紧急修复时，develop 分支有未发布的新功能怎么办？**
A: Hotfix 必须基于 main 分支创建。修复并合并到 main 后，**必须**将 hotfix 分支同步合并回 develop，确保生产环境的修复不会在下次发版时丢失。