1. 分支策略
1.1 主分支（main 或 master）
- 功能：主分支应该始终保持可部署的状态，代表生产环境中的代码。
- 实践：所有代码最终都需要合并到
main分支，且合并之前应经过充分测试和审查。
1.2 开发分支（develop）
- 功能：
develop是开发过程中的集成分支，所有开发者的代码合并到此分支进行集成。 - 实践：所有特性分支（feature branch）完成后合并到
develop，测试新功能和修复 bug。
1.3 特性分支（feature/）
-
功能：每个新功能或任务都应该创建独立的分支。
-
命名规范：
feature/<功能名称>，例如feature/login-page、feature/user-profile。 -
实践：
- 从
develop分支创建特性分支。 - 每个特性分支应只处理一个功能，避免包含多个不相关的功能。
- 完成后将特性分支合并回
develop分支。
- 从
1.4 发布分支（release/）
-
功能：当
develop分支的代码已经足够稳定，可以创建发布分支，用于做最后的调试和 bug 修复。 -
命名规范：
release/<版本号>，例如release/1.0.0。 -
实践：发布分支上的所有更改应仅限于修复 bug、更新文档或做小范围改进，不应添加新功能。
- 一旦发布准备就绪，合并回
main和develop，并打上标签（tag）进行版本发布。
- 一旦发布准备就绪，合并回
1.5 热修复分支（hotfix/）
-
功能：当生产环境中的代码出现重大 bug 或问题时，立即创建
hotfix分支修复。 -
命名规范：
hotfix/<问题描述>，例如hotfix/fix-login-error。 -
实践：从
main分支创建hotfix分支，修复紧急问题后合并回main和develop。- 打上版本标签并发布，确保修复代码不会遗漏。
1.6 分支合并策略
-
合并方法：推荐使用
merge或rebase。merge：保留提交历史，适用于大多数场景。rebase：将分支上的提交应用到目标分支的最新提交上，历史记录更加清晰，但需要小心使用，避免公共历史的改变。
2. 提交规范
2.1 提交频率
- 实践：保持频繁的小提交，不要等到一大段代码完成后才提交。每次提交应该解决一个小的、独立的问题。
- 好处：有助于追踪问题，易于回滚，减少冲突。
2.2 提交信息格式
-
格式：简洁明了，通常包括两部分：
- 类型：描述提交的类型（
feat、fix、docs、style、refactor、test等）。 - 描述：简短明了地描述变更。
- 类型：描述提交的类型（
-
示例：
feat: 增加用户登录功能fix: 修复支付页面按钮点击无反应docs: 更新 README 文件style: 格式化代码test: 增加用户登录单元测试
2.3 避免无意义的提交
- 示例：
fix typo、debugging等不具备上下文的提交信息不推荐使用。
3. 代码审查与 Pull Request（PR）流程
3.1 使用 Pull Request 进行代码审查
-
目标：在将代码合并到主分支之前，其他团队成员应对代码进行审查，确保代码质量。
-
实践：
- PR 需要清晰的标题和描述。
- PR 描述应包括变更背景、影响的模块、相关的 bug 号或任务号等。
- 审查过程中，提出的意见应是具体的，不仅仅是 “改进” 或 “优化”，而要指出具体改进的地方。
- 确保 PR 合并前通过所有自动化测试（如 CI/CD 流程）。
3.2 PR 合并时的注意事项
-
合并前拉取最新代码：确保在合并前已拉取并解决了所有的冲突，避免因缺少更新导致代码问题。
-
代码审查要点：
- 代码是否遵循项目的编码规范？
- 代码是否简洁高效？
- 是否有多余的注释或不必要的代码？
- 是否进行了充分的单元测试，代码覆盖率是否足够？
4. 代码同步与推送
4.1 及时拉取（Pull）
-
实践：每天或在开始工作前，从远程仓库拉取最新的代码，确保本地仓库与远程仓库同步。
- 使用命令：
git pull origin <branch-name>。 - 确保本地分支更新，与其他开发人员的工作不冲突。
- 使用命令：
4.2 及时推送（Push）
-
实践：开发完成后，及时将本地的提交推送到远程仓库，确保团队能够及时查看和共享代码。
- 使用命令：
git push origin <branch-name>。
- 使用命令：
4.3 推送策略
- 避免滞后推送：不要长时间不推送代码，避免出现大范围的冲突。
- 避免强制推送（force push） ：强制推送会覆盖远程仓库的历史，可能会导致其他开发人员的代码丢失。除非必要，避免使用
git push --force。
5. 清理不再需要的分支
5.1 删除已合并的分支
- 本地分支：
git branch -d <branch-name>（-d会防止删除未合并的分支，-D强制删除）。 - 远程分支：
git push origin --delete <branch-name>。
5.2 定期清理
- 实践：定期删除已经合并且不再需要的分支，保持仓库清洁。
- 自动化：可以设置 Git 钩子（hooks）自动化一些清理工作，或使用 GitLab、GitHub 等平台的分支清理功能。
6. 标签与版本管理
6.1 版本标签
-
功能：使用标签来标记版本发布点，便于回溯版本历史。
-
命名规范：使用语义化版本号，如
v1.0.0、v1.1.0、v2.0.0。 -
创建标签：
- 创建本地标签：
git tag v1.0.0。 - 推送标签到远程：
git push origin v1.0.0。
- 创建本地标签：
-
标签管理：一旦版本发布，使用标签标记该点，方便将来查看和回滚。
7. .gitignore 与大文件管理
7.1 .gitignore 配置
-
功能：避免将不必要的文件（如临时文件、IDE 配置、编译文件等）提交到仓库。
-
实践：创建
.gitignore文件，列出不需要跟踪的文件和目录。-
示例：
*.log *.tmp node_modules/ .DS_Store
-
7.2 大文件管理（Git LFS）
- 功能：使用 Git LFS（Large File Storage）来管理项目中的大文件，避免直接将大文件提交到 Git 仓库中。
- 实践：使用
git lfs安装并设置，指定需要管理的大文件类型。
8. 自动化与 CI/CD
8.1 CI/CD 流程
- 功能：自动化测试和部署，确保代码质量和持续交付。
- 实践：在每次推送或合并时触发 CI/CD 流程，运行单元测试、集成测试，并在通过后自动部署到测试环境或生产环境。
