实际项目中 Git 的最佳实践

在团队协作和项目管理中，遵循 Git 最佳实践能显著提升效率、减少冲突、保证代码质量。以下是结合实际项目场景总结的核心实践：

一、分支策略：选择适合团队的工作流

1. Git Flow（适合有明确发布周期的项目）

• 核心分支：
  • main/master：稳定版本，随时可部署。
  • develop：开发集成分支，所有新功能最终合并到这里。
• 辅助分支：
  • feature/*：新功能分支（从 develop 切出，合并回 develop）。
  • release/*：发布分支（从 develop 切出，用于测试和修复 bug，最终合并到 main 和 develop）。
  • hotfix/*：紧急修复分支（从 main 切出，修复生产问题，合并回 main 和 develop）。
• 适用场景：传统软件项目、版本发布节奏清晰（如每月/每季度发布）。

2. Trunk-Based Development（适合持续交付的项目）

• 核心原则：
  • 开发者频繁（每天至少一次）将代码合并到 main 分支。
  • 通过特性开关（Feature Flags）控制未完成功能的可见性。
  • 依赖自动化测试（CI/CD）保证 main 分支始终稳定。
• 适用场景：互联网产品、需要快速迭代和持续部署的项目（如 SaaS 应用）。

二、提交规范：让历史记录“会说话”

1. 遵循 Conventional Commits 格式

提交信息格式：<type>(<scope>): <subject>

• type：提交类型（必须），常见值：
  • feat：新功能
  • fix：修复 bug
  • docs：文档更新
  • style：代码格式调整（不影响逻辑）
  • refactor：重构（既不新增功能也不修复 bug）
  • test：测试相关
  • chore：构建/工具链相关
• scope：影响范围（可选），如 auth、checkout。
• subject：简短描述（不超过 50 字符），用动词开头（如“添加”“修复”）。

示例：

git commit -m "feat(auth): 支持微信登录"
git commit -m "fix(checkout): 修复购物车数量计算错误"

2. 提交原则

• 原子性提交：一个提交只做一件事（避免“大杂烩”提交）。
• 频繁提交：小步快跑，便于回滚和代码审查。
• 拒绝“半成品”：确保提交的代码可编译、可运行（通过本地测试）。

三、代码审查：PR/MR 是质量的守门员

1. PR（Pull Request）/MR（Merge Request）规范

• PR 大小适中：建议单个 PR 代码变更不超过 400 行（便于审查）。
• 清晰的 PR 描述：
  • 说明“为什么做”（背景/需求）和“怎么做”（实现思路）。
  • 关联相关 Issue（如 Closes #123）。
  • 附上截图/演示（如涉及 UI 变更）。
• 指定审查者：至少 1-2 人审查，优先邀请相关模块负责人。

2. 审查重点

• 代码质量：逻辑是否清晰、是否有重复代码、命名是否规范。
• 功能正确性：是否实现需求、是否引入新 bug。
• 安全性：是否存在安全漏洞（如 SQL 注入、XSS）。
• 可维护性：是否有注释、文档是否同步更新。

3. 审查反馈原则

• 对事不对人：聚焦代码，避免人身攻击。
• 给出具体建议：如“这里可以用 Map 替代 Object 提升性能”。
• 鼓励提问：对不清楚的地方及时沟通，不要“不懂装懂”。

四、远程仓库管理：保护核心分支，规范协作

1. 分支保护规则

在 GitHub/GitLab 中为 main/master 和 develop 分支设置保护：

• 禁止直接推送：必须通过 PR/MR 合并。
• 强制代码审查：至少 1 人批准才能合并。
• 强制 CI 通过：自动化测试（如单元测试、lint 检查）通过后才能合并。
• 禁止删除分支：防止误删核心分支。

2. 标签（Tag）管理：版本发布的“锚点”

• 语义化版本（Semantic Versioning）：v<major>.<minor>.<patch>（如 v1.2.3）。
  • major：不兼容的 API 变更。
  • minor：向下兼容的功能新增。
  • patch：向下兼容的 bug 修复。
• 打标签并推送：

  git tag -a v1.2.3 -m "发布版本 1.2.3"
  git push origin v1.2.3
  

五、冲突处理：预防为主，高效解决

1. 预防冲突

• 频繁拉取远程代码：每天至少 git pull origin <分支> 一次，及时同步他人修改。
• 小分支开发：分支生命周期越短，冲突概率越低（建议 feature 分支不超过 3 天）。
• 明确代码所有权：不同模块由专人负责，减少多人同时修改同一文件的情况。

2. 解决冲突

• 保持冷静：冲突是正常的，不要盲目“覆盖”他人代码。
• 步骤：
  1. Git 会标记冲突文件（如 <<<<<<< HEAD、=======、>>>>>>> branch-name）。
  2. 打开文件，手动编辑保留需要的代码，删除冲突标记。
  3. 运行 git add <冲突文件> 标记冲突已解决。
  4. 运行 git commit 完成合并（Git 会自动生成合并提交信息）。
• 工具辅助：使用 VS Code、Sourcetree 等可视化工具，更清晰地查看冲突差异。

六、安全与清理：守护仓库的“健康”

1. 敏感信息管理

• 永远不要提交敏感信息：如 API 密钥、数据库密码、私钥等。
• 使用 .gitignore：忽略敏感文件（如 .env、config/secrets.yml）。
• 如果不小心提交了敏感信息：
  • 立即修改密码/密钥。
  • 使用工具清理历史记录（如 git filter-repo、BFG Repo-Cleaner）。
  • 注意：即使删除了文件，敏感信息仍可能存在于 Git 历史中，需彻底清理。

2. 仓库清理

• 删除已合并的分支：定期运行 git branch -d <分支名> 清理本地分支，远程分支可在 PR 合并后自动删除。
• 清理大文件：如果仓库中不小心提交了大文件（如视频、压缩包），使用 git filter-repo 移除，避免仓库体积过大。

七、实用技巧：提升 Git 使用效率

1. git stash：暂存未完成的修改

场景：正在开发新功能，突然需要切换分支修复 bug，但当前代码还没写完。

git stash save "暂存未完成的微信登录功能"  # 暂存修改
git switch hotfix-xxx  # 切换到修复分支
# ... 修复 bug 并提交 ...
git switch feature-wechat-login  # 切回原分支
git stash pop  # 恢复暂存的修改

2. git bisect：快速定位引入 bug 的提交

场景：发现 main 分支有 bug，但不知道是哪个提交引入的。

git bisect start  # 启动二分查找
git bisect bad  # 标记当前提交为“有 bug”
git bisect good v1.2.0  # 标记 v1.2.0 为“无 bug”
# Git 会自动切换到中间的提交，测试后标记 good/bad
# 直到找到第一个引入 bug 的提交
git bisect reset  # 退出二分查找

3. git reflog：恢复误操作

场景：不小心 git reset --hard 丢失了提交。

git reflog  # 查看操作历史，找到丢失的提交哈希值
git reset --hard <哈希值>  # 恢复到该提交

八、团队协作：统一规范，减少摩擦

• 文档化 Git 流程：在项目 Wiki 中记录分支策略、提交规范、PR 流程等，新人入职可快速上手。
• 统一工具配置：
  • 共享 .gitignore 模板（如 GitHub/gitignore）。
  • 统一编辑器配置（如 .editorconfig），避免换行符、缩进差异。
• 定期 Git 培训：分享 Git 技巧、踩坑经验，提升团队整体 Git 水平。