Git 工作流指南：从 commit 到 PR 的最佳实践

为什么需要规范的工作流

在团队协作中，Git 是沟通的桥梁。好的 Git 工作流能让代码历史清晰可读、协作顺畅高效、问题易于追溯。混乱的 Git 使用则是 Bug 和冲突的温床。

分支管理策略

主干分支模型

main        ─────●─────────────●─────────────●────────→ 生产环境
                \             / \             /
feature/login    ●───●───●───●   \           /
feature/header                  ●───●───●───●

分支命名规范：

| 分支类型 | 命名格式 | 示例 | |---------|---------|------| | 功能分支 | feature/描述 | feature/user-auth | | 修复分支 | fix/描述 | fix/login-redirect | | 热修复 | hotfix/描述 | hotfix/security-patch | | 发布分支 | release/版本 | release/v2.0 |

Commit 规范

Conventional Commits

<type>(<scope>): <subject>

<body>

<footer>

常用 type：

feat:     新功能
fix:      修复 Bug
docs:     文档变更
style:    代码格式（不影响逻辑）
refactor: 重构
test:     测试相关
chore:    构建/工具变更

示例：

feat(auth): 添加 OAuth2 登录支持

集成了 Google 和 GitHub OAuth2 登录，
用户可以选择第三方账号登录。

Closes #42

写好 commit message 的原则

主语使用祈使句 — "添加" 而不是 "添加了"
一行不超过 72 字符
说明"为什么"而非"做了什么" — 代码已经说明了"做了什么"

日常操作最佳实践

提交前检查

# 查看将要提交的内容
git diff --staged

# 交互式暂存，精确控制提交内容
git add -p

保持线性历史

# rebase 而非 merge，保持历史线性
git pull --rebase

# 在 feature 分支上 rebase 最新 main
git checkout feature/user-auth
git rebase main

合并多个 commit

# 交互式 rebase 合并最近 3 个 commit
git rebase -i HEAD~3

pick   abc1234 添加登录表单
squash def5678 修复样式
squash ghi9012 添加验证逻辑

Pull Request 流程

PR 标题与描述

## 概述
实现用户认证模块，支持邮箱登录和 OAuth2。

## 变更内容
- 添加登录/注册页面
- 集成 JWT token 认证
- 添加路由守卫

## 测试
- [x] 单元测试通过
- [x] E2E 测试通过
- [x] 手动测试登录流程

## 关联 Issue
Closes #42, #43

Code Review 要点

Review 代码，不是 Review 人
指出问题时，提供改进建议
区分"必须修改"和"建议修改"
对好的代码给予肯定

冲突解决

# rebase 时遇到冲突
git rebase main
# 解决冲突后
git add .
git rebase --continue

# 放弃 rebase
git rebase --abort

减少冲突的策略

频繁 rebase — 保持 feature 分支与 main 同步
小步提交 — 每个 commit 范围小，冲突也小
沟通协调 — 避免多人同时修改同一文件

实用别名配置

# ~/.gitconfig
[alias]
  co = checkout
  br = branch
  ci = commit
  st = status
  lg = log --oneline --graph --decorate --all
  last = log -1 HEAD
  unstage = reset HEAD --

紧急回滚

# 撤销最近一次提交（保留改动）
git reset --soft HEAD~1

# 创建回滚 commit（不改写历史，安全）
git revert <commit-hash>

总结

Git 工作流的核心不是规则本身，而是让团队协作更高效。选择适合团队规模的策略，保持一致性，比追求"完美"的工作流更重要。

好的 Git 历史是一本可读的书，坏的 Git 历史是一本乱码日记。