Git 的正确使用姿势与最佳实践：团队协作与版本控制Git 的正确使用姿势与最佳实践：团队协作与版本控制一、Git 的

分支策略
- 主分支（main 或 master） ：
  - 保存稳定、可发布的代码。
- 开发分支（develop） ：
  - 用于集成和测试新功能。
- 功能分支（feature/*） ：
  - 每个新功能或任务单独创建一个分支。
- 修复分支（hotfix/* 或 bugfix/*） ：
  - 紧急修复生产环境问题。

推荐分支模型（Git Flow）

main
 |
 |-- develop
      |-- feature/feature-name
      |-- bugfix/bug-id

提交规范
- 小而频繁：每次提交只解决一个问题或完成一个功能。
- 清晰的提交信息：使用描述性语言，标明改动内容。
推荐格式（Angular 提交规范）：
```
<type>(<scope>): <subject>
<空行>
<body>
```
示例：
```
feat(auth): add user login endpoint
- Add JWT authentication for login
- Update database schema for user sessions
```
常见的 type 类型：
- feat：新增功能。
- fix：修复问题。
- docs：修改文档。
- refactor：代码重构。
- test：增加或修改测试。
避免提交大文件或敏感信息
- 配置 .gitignore，排除临时文件和非必要文件。
示例 .gitignore 文件：
```
# 忽略临时文件
*.log
*.tmp

# 忽略环境配置文件
.env
```

Pull Request（PR）流程
- 功能完成后，提交 PR 到主分支或开发分支。
- 团队成员审查代码，给出改进建议。
- 通过审查后再合并。
合并策略
- Rebase 合并：保持提交历史线性，适合小团队。
- Merge 合并：保留分支历史，适合需要完整开发记录的团队。
示例合并命令：
```
# 使用 rebase 合并
git checkout main
git pull origin main
git checkout feature/branch-name
git rebase main
git checkout main
git merge feature/branch-name
```
代码审查工具
- GitHub/GitLab 的代码审查功能。
- 使用静态分析工具（如 SonarQube）自动检测代码问题。

避免冲突
- 定期同步远程分支，减少分支间差异。
- 将大型功能拆分成小任务，分步提交。
解决冲突
- 使用工具（如 VS Code、git mergetool）解决冲突。
- 确保修改后手动测试，避免功能丢失。
示例解决冲突流程：
```
git pull origin main
# 检查冲突文件
git status
# 编辑文件，解决冲突
git add <file>
git commit
```

多人协作规范
- 确保团队成员对远程分支的修改权限受控。
- 使用保护分支机制，防止直接推送到主分支。
示例保护分支规则：
- 禁止直接提交，必须通过 PR 合并。
- 至少 1-2 人审核后才能合并。
标签（Tags）与版本发布
- 使用标签标记稳定版本，方便回溯。
示例创建标签：
```
git tag -a v1.0.0 -m "Release version 1.0.0"
git push origin v1.0.0
```

版本回滚

示例回滚命令：

# 回滚到上一个提交
git reset --hard HEAD~1

# 回滚到指定提交
git reset --hard <commit-hash>

推荐工具
- 命令行工具：熟练掌握基本命令如 git clone、git pull、git push。
- 可视化工具：如 SourceTree、GitKraken。
- IDE 集成：如 VS Code 的 Git 插件。
资源推荐

熟练运用 Git，不仅能提高团队协作效率，还能降低项目出错率，推动高质量代码的输出。