Git工作流最佳实践

📅 2026-03-04 ⏱️ 14 分钟阅读 👤 HEPH Team
Git工作流

Git已经成为现代软件开发的标配工具，但会用Git和用好Git是两回事。在团队协作中，不规范的使用方式会导致代码混乱、冲突频发、回退困难等问题。在这篇文章中，我将分享Git工作流的最佳实践，帮助你建立高效的团队协作模式。

分支策略

GitHub Flow

最简单的工作流，适合持续部署的项目：

  • main：主分支，始终保持可部署状态
  • feature/*：功能分支，完成后合并到main
# 创建功能分支
git checkout -b feature/new-login

# 开发并提交
git add .
git commit -m "feat: add new login page"

# 推送到远程
git push origin feature/new-login

# 创建Pull Request，代码审查后合并

Git Flow

更结构化的工作流，适合有明确发布周期的项目：

  • main：生产环境代码
  • develop：开发主分支
  • feature/*：功能分支，从develop分出
  • release/*：发布准备分支
  • hotfix/*：紧急修复分支
# 功能开发
git checkout develop
git checkout -b feature/user-profile
# 开发完成后
git checkout develop
git merge feature/user-profile

# 准备发布
git checkout -b release/1.0.0
# 修复bug、更新版本号
git checkout main
git merge release/1.0.0
git tag -a v1.0.0

# 紧急修复
git checkout -b hotfix/critical-bug main
# 修复后
git checkout main
git merge hotfix/critical-bug
git checkout develop
git merge hotfix/critical-bug

Trunk Based Development

所有开发都在主干进行，使用功能开关控制发布：

# 直接在main上开发，或使用短期分支
git checkout main
git pull
git checkout -b short-lived-feature

# 快速完成并合并（通常1-2天）
git push origin short-lived-feature
# 创建PR并合并

提交规范

Git提交规范

Conventional Commits

使用规范化的提交信息格式：

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

<body>

<footer>

类型（type）

  • feat：新功能
  • fix：修复bug
  • docs：文档变更
  • style：代码格式（不影响功能）
  • refactor：重构
  • test：测试相关
  • chore：构建或辅助工具变动
  • perf：性能优化
feat(auth): add OAuth2 login support

Implement OAuth2 authentication flow with Google and GitHub providers.
Users can now login using their social accounts.

Closes #123

fix(cart): correct total calculation with discounts

The discount was being applied after tax, causing incorrect totals.
Now applies discount before tax calculation.

fixes #456

提交最佳实践

  1. 一个提交一个变更：每个提交只做一件事
  2. 提交信息要清晰：说明"做了什么"和"为什么"
  3. 使用祈使语气："add feature" 而非 "added feature"
  4. 引用相关Issue：便于追踪

代码审查

Pull Request规范

一个好的PR描述应该包含：

## 变更说明
简要描述本次变更的目的和内容

## 变更类型
- [ ] 新功能
- [ ] Bug修复
- [ ] 重构
- [ ] 文档更新

## 测试情况
描述如何测试这些变更

## 截图
如果有UI变更，附上截图

## 检查清单
- [ ] 代码遵循项目规范
- [ ] 已添加测试
- [ ] 文档已更新
- [ ] 无新的警告

审查要点

  • 代码正确性：逻辑是否正确，边界条件是否处理
  • 代码质量：可读性、可维护性、性能
  • 测试覆盖：是否有足够的测试
  • 安全考虑：是否有安全风险

冲突解决

预防冲突

  • 保持分支更新，定期rebase或merge主分支
  • 小步快跑，频繁合并
  • 团队成员间保持沟通
  • 合理拆分模块，减少交叉修改

解决冲突

# 更新主分支
git checkout main
git pull origin main

# 回到功能分支并rebase
git checkout feature/my-feature
git rebase main

# 如果有冲突，解决冲突
# 编辑冲突文件...

# 标记已解决
git add resolved-file.js
git rebase --continue

# 强制推送（因为历史已改变）
git push origin feature/my-feature --force

实用命令

暂存工作

# 暂存当前工作
git stash

# 带描述的暂存
git stash save "WIP: login feature"

# 查看暂存列表
git stash list

# 恢复暂存
git stash pop

# 恢复特定暂存
git stash apply stash@{0}

撤销操作

# 撤销工作区的修改
git checkout -- file.js

# 撤销暂存
git reset HEAD file.js

# 修改最后一次提交
git commit --amend

# 撤销提交（保留修改）
git reset --soft HEAD~1

# 撤销提交（丢弃修改）
git reset --hard HEAD~1

# 创建撤销提交
git revert commit-hash

查看历史

# 图形化历史
git log --oneline --graph --all

# 查看特定文件的历史
git log -p file.js

# 查看谁修改了某行
git blame file.js

# 搜索提交信息
git log --grep="关键词"

工具推荐

  • commitlint：提交信息格式检查
  • husky：Git hooks管理
  • lint-staged：只检查暂存文件
  • git-cz：交互式提交信息生成
  • semantic-release：自动化版本发布

总结

良好的Git工作流是团队协作效率的基石。选择适合团队的分支策略，坚持提交规范，认真对待代码审查，这些习惯会让协作更加顺畅。

记住，工具和规范服务于效率，不要为了规范而规范。根据团队规模、项目特点灵活调整，找到最适合你们的工作方式。

Git 工作流 团队协作 版本控制