Git 工作流与协作

简介

Git 工作流定义了团队如何使用 Git 进行分支管理、代码合并和版本发布。选择合适的工作流能减少冲突、提高协作效率。本文介绍主流的 Git 工作流、分支策略和团队协作最佳实践。

特点

• 1.分支策略 — 明确的分支命名和使用规范
• 2.代码审查 — PR/MR 审查保证代码质量
• 3.版本管理 — 语义化版本控制
• 4.自动化 — CI/CD 与 Git 工作流集成

主流工作流

1. Git Flow

特点：适合有计划发布周期的项目

分支：
master    — 生产代码，只接受合并
develop   — 开发主线
feature/* — 功能分支
release/* — 发版准备
hotfix/*  — 紧急修复

流程：
1. 从 develop 创建 feature 分支
2. 功能开发完成后合并回 develop
3. 从 develop 创建 release 分支
4. 测试通过后合并到 master 和 develop
5. 紧急修复从 master 创建 hotfix

优点：流程严谨，适合大型项目
缺点：分支多，流程复杂

2. GitHub Flow

特点：简单直接，适合持续部署

分支：
main      — 始终可部署
feature/* — 功能分支

流程：
1. 从 main 创建分支
2. 提交代码并推送
3. 创建 Pull Request
4. 代码审查和讨论
5. 合并到 main
6. 自动部署

优点：简单、快速、持续部署
缺点：不适合多版本维护

3. GitLab Flow

特点：结合 Git Flow 和 GitHub Flow

分支：
main          — 主分支
feature/*     — 功能分支
staging       — 预发布
production    — 生产

流程：
1. 功能分支 → main（代码审查）
2. main → staging（测试）
3. staging → production（发布）

优点：兼顾灵活和稳定
缺点：需要 CI/CD 支持

分支命名规范

feature/user-authentication     功能开发
bugfix/login-error              Bug 修复
hotfix/payment-crash            紧急修复
release/v2.1.0                  版本发布
refactor/database-layer         重构
docs/api-documentation          文档
test/integration-tests          测试

Commit 规范

Conventional Commits

[type]([scope]): [subject]

[body]

[footer]

类型说明

类型	说明	示例
feat	新功能	feat(auth): 添加 JWT 认证
fix	Bug 修复	fix(order): 修复金额计算错误
docs	文档	docs(api): 更新接口文档
style	格式	style: 代码格式化
refactor	重构	refactor(db): 重构数据访问层
perf	性能	perf(query): 优化查询性能
test	测试	test(order): 添加订单单元测试
ci	CI/CD	ci: 配置 GitHub Actions
chore	构建/工具	chore: 升级 .NET 8

Commit 示例

feat(order): 添加订单导出功能

- 支持 Excel 和 PDF 格式导出
- 支持按日期范围筛选
- 支持批量导出

Closes #123

常用 Git 操作

分支操作

# 创建并切换分支
git checkout -b feature/user-auth

# 推送新分支到远程
git push -u origin feature/user-auth

# 合并分支（推荐用 PR）
git checkout main
git merge --no-ff feature/user-auth

# 删除已合并分支
git branch -d feature/user-auth
git push origin --delete feature/user-auth

# 查看分支状态
git branch -a
git log --oneline --graph --all

# 暂存工作
git stash
git stash pop
git stash list

PR 审查流程

# 1. 更新本地分支
git checkout feature/user-auth
git fetch origin
git rebase origin/main

# 2. 解决冲突后推送
git push origin feature/user-auth --force-with-lease

# 3. 在 GitHub/GitLab 创建 Pull Request

# 4. 审查者拉取测试
git fetch origin
git checkout origin/feature/user-auth

# 5. 审查通过后合并（Squash Merge 推荐）

代码审查检查项

功能正确性：
- 是否实现了需求
- 边界条件是否处理
- 错误处理是否完善

代码质量：
- 命名是否清晰
- 是否有重复代码
- 是否遵循团队规范

安全性：
- 是否有注入风险
- 敏感信息是否暴露
- 权限检查是否到位

性能：
- 是否有 N+1 查询
- 是否有不必要的循环
- 资源是否正确释放

版本管理

语义化版本

v{MAJOR}.{MINOR}.{PATCH}

MAJOR — 不兼容的 API 变更
MINOR — 向后兼容的功能新增
PATCH — 向后兼容的 Bug 修复

示例：
v1.0.0 → v1.0.1  Bug 修复
v1.0.1 → v1.1.0  新增功能
v1.1.0 → v2.0.0  破坏性变更

Tag 管理

# 创建标签
git tag -a v1.0.0 -m "发布 v1.0.0"

# 推送标签
git push origin v1.0.0
git push origin --tags

# 查看标签
git tag -l
git show v1.0.0

# 删除标签
git tag -d v1.0.0
git push origin --delete v1.0.0

.gitignore 配置

# .NET
bin/
obj/
*.user
*.suo
.vs/

# 发布输出
publish/

# 用户敏感文件
appsettings.Production.json
*.pfx
*.key
.env

# IDE
.idea/
.vscode/

# 操作系统
Thumbs.db
.DS_Store

工作流选择

团队规模	项目类型	推荐工作流
1-3 人	小项目	GitHub Flow
5-15 人	中型项目	GitLab Flow
20+ 人	大型项目	Git Flow
开源项目	任意	GitHub Flow + Fork

合并冲突解决

合并冲突是团队协作中不可避免的问题，掌握高效的冲突解决方法能显著提升开发效率。

冲突产生的原因与预防

# 冲突常见原因
# 1. 两个人同时修改了同一文件的同一行
# 2. 一个人修改了文件，另一个人删除了该文件
# 3. 分支长期不合并，积累大量差异

# 预防冲突的策略
# 1. 小步提交，频繁合并主分支
git fetch origin
git merge origin/main
# 或使用 rebase 保持线性历史
git rebase origin/main

# 2. 团队分工明确，减少同一文件的并行修改
# 3. 使用 feature flag（功能开关）代替长期分支

# 4. 配置 .gitattributes 管理合并策略
# .gitattributes
# *.cs merge=union           # C# 文件使用 union 合并
# README.md merge=ours       # README 始终保留当前分支版本

冲突解决实战

# 步骤 1：更新本地分支并发现冲突
git fetch origin
git merge origin/main
# 自动合并失败，提示 CONFLICT

# 步骤 2：查看冲突文件
git status
# both modified:   src/Services/OrderService.cs

# 步骤 3：打开文件查看冲突标记
# <<<<<<< HEAD
# 你的代码
# =======
# 对方的代码
# >>>>>>> origin/main

# 步骤 4：手动解决冲突（选择保留哪部分或合并两者）

# 步骤 5：标记冲突已解决
git add src/Services/OrderService.cs

# 步骤 6：完成合并
git commit -m "merge: resolve conflict in OrderService"

# 使用工具辅助解决冲突
# VS Code：内置 Git 冲突可视化
# IntelliJ IDEA：三路合并视图
# Beyond Compare：专业文件对比工具
# git mergetool --tool=vscode

复杂冲突处理

# 情况 1：合并后想撤销（合并尚未推送）
git merge --abort
# 回到合并前的状态

# 情况 2：rebase 过程中的冲突
git rebase origin/main
# 出现冲突后：
git add .                    # 解决冲突
git rebase --continue        # 继续 rebase
git rebase --abort           # 放弃 rebase

# 情况 3：二进制文件冲突（图片、PDF等）
# Git 无法自动合并二进制文件
# 手动选择保留哪个版本：
git checkout --theirs assets/logo.png    # 使用对方的版本
git checkout --ours assets/logo.png      # 使用自己的版本
git add assets/logo.png

# 情况 4：文件被删除的冲突
# 如果一方修改了文件，另一方删除了文件
# 选择保留文件：
git add src/OldService.cs
# 选择删除文件：
git rm src/OldService.cs

CI/CD 与 Git 工作流集成

GitHub Actions 自动化

# .github/workflows/ci.yml
name: CI Pipeline

on:
  pull_request:
    branches: [main, develop]
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'

      - name: Restore dependencies
        run: dotnet restore

      - name: Build
        run: dotnet build --no-restore --configuration Release

      - name: Run tests
        run: dotnet test --no-build --configuration Release --collect:"XPlat Code Coverage"

      - name: Check formatting
        run: dotnet format --verify-no-changes

Git Hooks 自动检查

# 使用 husky 或 git hooks 管理提交前检查
# 安装 husky（Node.js 项目）
npx husky init

# .husky/pre-commit — 提交前自动检查
#!/bin/sh
dotnet format --verify-no-changes
dotnet test --no-build

# .husky/commit-msg — 提交信息格式检查
#!/bin/sh
# 检查是否符合 Conventional Commits 格式
msg=$(head -1 "$1")
if ! echo "$msg" | grep -qE "^(feat|fix|docs|style|refactor|perf|test|ci|chore)(\(.+\))?: .+"; then
  echo "错误：提交信息格式不符合 Conventional Commits 规范"
  echo "正确格式：type(scope): subject"
  echo "示例：feat(auth): 添加 JWT 认证"
  exit 1
fi

# .husky/pre-push — 推送前运行完整测试
#!/bin/sh
dotnet test --configuration Release

分支保护规则

# GitHub 分支保护规则（通过 Web 界面或 API 配置）
# Settings > Branches > Branch protection rules

# 推荐的保护规则：
# 1. Require a pull request before merging
#    - Required approving reviews: 1-2 人
#    - Dismiss stale pull request approvals when new commits are pushed
# 2. Require status checks to pass before merging
#    - ci/build, ci/test, ci/format
# 3. Require signed commits
# 4. Do not allow force pushes
# 5. Do not allow deletions

# GitLab 保护分支（通过 Web 界面配置）
# Settings > Repository > Protected branches
# 1. Allowed to merge: Maintainers
# 2. Allowed to push: No one
# 3. Required MR approvals: 1

高级协作技巧

Feature Flag 模式

// 使用 Feature Flag 避免长期分支
// 在主分支上开发，通过开关控制功能是否生效
public class FeatureFlags
{
    public bool EnableNewPaymentGateway { get; set; }
    public bool EnableDarkMode { get; set; }
}

// appsettings.json
// "FeatureFlags": {
//     "EnableNewPaymentGateway": false,
//     "EnableDarkMode": true
// }

// 在代码中使用
if (featureFlags.EnableNewPaymentGateway)
{
    return new StripePaymentService();
}
else
{
    return new LegacyPaymentService();
}

Trunk-Based Development（主干开发）

特点：所有人直接在 main 上提交，配合 Feature Toggle

流程：
1. 从 main 拉取最新代码
2. 在本地开发功能（通过 Feature Flag 控制是否生效）
3. 提交前运行自动化测试
4. 推送到 main（或通过短生命周期的 PR）
5. 通过 CI/CD 自动部署到测试/生产环境

优点：
- 消除合并冲突（没有长期分支）
- 持续集成，问题更早暴露
- 发布更频繁，风险更小

要求：
- 强大的 CI/CD 管道
- 完善的自动化测试
- Feature Flag 管理系统
- 小步提交（每次提交都能编译通过）

优点

• 1.规范统一 — 团队遵循同一套流程
• 2.代码质量 — PR 审查保证质量
• 3.可追溯 — 每次变更都有记录
• 4.自动化 — CI/CD 集成

缺点

• 1.学习成本 — 新人需要学习工作流
• 2.流程开销 — PR 审查需要时间
• 3.冲突处理 — 并行开发可能冲突
• 4.工具依赖 — 需要 GitHub/GitLab 平台

总结

Git 工作流没有银弹，根据团队规模和项目特点选择。小团队用 GitHub Flow 简单高效，大团队用 Git Flow 严谨可控。核心原则：规范分支命名，统一 Commit 格式，坚持代码审查，自动化 CI/CD。

关键知识点

• DevOps 主题的核心是让交付更快、更稳、更可审计。
• 自动化不是把命令脚本化，而是把失败、回滚、权限和观测一起设计进去。
• 生产链路必须明确制品、环境、凭据、配置和责任边界。

项目落地视角

• 把流水线拆成构建、测试、制品、部署、验证和回滚几个阶段。
• 为关键步骤补齐日志、指标、通知和人工兜底点。
• 定期演练扩容、回滚、故障注入和灾备切换。

常见误区

• 只关注部署成功，不关注失败恢复和审计追踪。
• 把环境差异藏在临时脚本或人工操作里。
• 上线频率高了以后，没有标准化制品和配置管理。

进阶路线

• 继续补齐 GitOps、可观测性、平台工程和成本治理。
• 把主题和应用架构、安全、权限、备份恢复联动起来理解。
• 形成团队级平台能力，而不是每个项目重复造轮子。

适用场景

• 当你准备把《Git 工作流与协作》真正落到项目里时，最适合先在一个独立模块或最小样例里验证关键路径。
• 适合构建自动化交付、基础设施治理、监控告警和生产发布体系。
• 当团队规模扩大、发布频率提升或环境变多时，这类主题会显著影响交付效率。

落地建议

• 所有自动化流程尽量做到幂等、可审计、可回滚。
• 把制品、变量、凭据和执行权限分层管理。
• 定期演练扩容、回滚、密钥轮换和灾备恢复。

排错清单

• 先定位失败发生在代码、构建、制品、环境还是权限层。
• 检查流水线变量、凭据、镜像标签和目标环境配置是否一致。
• 如果问题偶发，重点看并发发布、资源争抢和外部依赖抖动。

复盘问题

• 如果把《Git 工作流与协作》放进你的当前项目，最先要验证的输入、输出和失败路径分别是什么？
• 《Git 工作流与协作》最容易在什么规模、什么边界条件下暴露问题？你会用什么指标或日志去确认？
• 相比默认实现或替代方案，采用《Git 工作流与协作》最大的收益和代价分别是什么？

延伸阅读

• Git 高级操作
• gitops practice
• github actions matrix
• GitHub Actions 自动化