Git 工作流 — GitHub Flow、Git Flow 与 Pull Request

前面学的都是"单兵作战"的命令。这一章讲团队怎么用 Git 协作——也就是"工作流"。一个团队约定好统一的分支策略和合并流程,代码才能整洁、可追溯、少冲突。还会讲每个项目都该有的 .gitignore 文件。

1. GitHub Flow — 现代(最流行)

GitHub Flow 是当下最流行的工作流,特点是简单、轻量、以 Pull Request 为中心。核心理念:main 分支永远可部署,任何改动都从 main 拉一个 feature 分支,完成后通过 PR 评审合并。适合 Web 应用、SaaS、持续部署的项目。

# GitHub Flow:最流行、最简单的现代工作流
# 核心理念:main 永远可部署,所有改动走 Pull Request
#
# 1. 从 main 拉一个 feature 分支
git switch main
git pull
git switch -c feature/user-profile

# 2. 开发、提交、推到远程同名分支
echo "profile page" > profile.html
git add . && git commit -m "feat: 添加个人资料页"
git push -u origin feature/user-profile

# 3. 在 GitHub 网页发 Pull Request(feature → main)
# 4. 同事 review、留 comments、讨论、改代码
#    review 时如果还要改,继续在本地 commit + push,PR 会自动更新
git commit -m "fix: 资料页响应式调整"
git push

# 5. approve 后点 "Squash and merge" 合并到 main
# 6. 删掉 feature 分支(本地 + 远程)
git switch main
git pull
git branch -d feature/user-profile
git push origin --delete feature/user-profile

2. Git Flow — 重型(传统)

Git Flow 是 2010 年 Vincent Driessen 提出的经典模型,分支角色更多(main / develop / feature / release / hotfix),适合有明确版本发布周期的产品(桌面软件、企业级应用、嵌入式)。Web 项目通常觉得它太重。

# Git Flow:更重型、适合"有版本发布"的产品(如桌面/企业软件)
# 分支角色:
#   main        生产环境,每个提交都是一个发布版本(配 tag)
#   develop     开发主线,最新功能的集成分支
#   feature/*   功能分支,从 develop 拉出,合并回 develop
#   release/*   发布预备分支,从 develop 拉出,合并回 main + develop
#   hotfix/*    紧急修复,从 main 拉出,合并回 main + develop
#
# 示例:
# 1. 开发新功能(从 develop 拉)
git switch develop && git pull
git switch -c feature/payment

# 2. 功能完成,合并回 develop
git switch develop
git merge --no-ff feature/payment

# 3. 准备发版 v2.0(从 develop 拉 release 分支)
git switch -c release/2.0
# ... 修最后的 bug、更新版本号 ...
git switch main
git merge --no-ff release/2.0
git tag -a v2.0.0 -m "发布 2.0"
git switch develop
git merge --no-ff release/2.0

# 4. 生产环境紧急 bug
git switch -c hotfix/2.0.1 main
# ... 修 bug ...
git switch main && git merge --no-ff hotfix/2.0.1
git tag -a v2.0.1
git switch develop && git merge --no-ff hotfix/2.0.1

如果发布就是"部署到服务器",用 GitHub Flow 就够了;如果发布是"出安装包、客户手动升级",Git Flow 的 release/hotfix 分支就有价值。

3. Pull Request — 代码评审的核心

Pull Request(简称 PR,GitLab 叫 Merge Request / MR)是 GitHub 提供的"合并请求"功能——你做完一个 feature,请求把它合并到 main,但不是直接合,而是先让同事评审。这是现代软件工程写出高质量代码的关键环节。

# Pull Request(PR)/ Merge Request(MR)
# 是 GitHub/GitLab 提供的"代码评审"功能,不是 Git 本身的命令
#
# PR 的价值:
#   - 代码评审(code review):同事帮你看代码,发现 bug、提建议
#   - 自动化检查:CI 跑测试、lint、构建,通过才能合并
#   - 讨论留痕:每个改动都有评论,决策过程可追溯
#   - 知识共享:review 别人的代码也是学习
#
# 一个好的 PR:
#   - 标题清晰(如 "feat: 添加手机号登录")
#   - 描述写清楚"改了什么、为什么改、怎么测"
#   - 改动控制在 300 行以内(太大难 review)
#   - 配截图/录屏(UI 改动)
#   - 自己先 review 一遍再提交
#
# review 时的好习惯:
#   - 对事不对人(评代码不评人)
#   - 提具体建议,不写"这写得不好"
#   - 区分"必须改"(blocking)和"可以更好"(nits)

一个健康的团队,代码评审应该认真但不刻薄。评审是对代码质量负责,不是显摆。被评审的人也别把建议当成攻击——大家目标都是让代码更好。

4. .gitignore — 忽略文件

很多文件不该进版本控制:依赖目录(node_modules)、编译产物(dist)、密钥文件(.env)、系统文件(.DS_Store)。用 .gitignore 告诉 Git 忽略它们,既能避免污染历史,又能防止把密钥泄露到公开仓库(这种事故每年都在发生)。

# .gitignore:告诉 Git 哪些文件不要追踪
# 在仓库根目录创建 .gitignore 文件,内容:

# 依赖目录
node_modules/
bower_components/

# 编译产物
dist/
build/
*.o
*.class

# 环境与密钥(千万别提交!)
.env
.env.local
*.pem
config/secrets.json

# 日志
*.log
logs/

# 系统文件
.DS_Store        # macOS
Thumbs.db        # Windows
.idea/           # JetBrains
.vscode/         # VS Code(可保留 .vscode/settings.json 共享配置)

# 语言相关
__pycache__/     # Python
*.pyc
.venv/
target/          # Rust
bin/obj/         # C# .NET

# 已经被追踪的文件,加进 .gitignore 也不会忽略!
# 需要先取消追踪:
git rm --cached .env           # 从仓库移除但保留本地文件
git commit -m "chore: 不再追踪 .env"

# GitHub 官方模板库:github/gitignore
# 几乎所有语言/框架的 .gitignore 模板都有,直接复制

GitHub 有个官方仓库 github/gitignore,收集了几乎所有语言/框架的 .gitignore 模板,直接复制即可。很多脚手架(create-react-app、vue-cli)会自动生成合适的 .gitignore。

5. 选哪种工作流?

没有"最好"的工作流,只有"最适合你团队"的。关键是约定好规则、文档化、新人入职讲清楚,避免每个人各搞各的。

6. 协作好习惯

← 上一篇 Git 远程仓库

下一篇 Git rebase 变基 →

✈️💬