Git 完整训练手册

Last updated on 19 Feb 2026

从零基础到工作实战 · 按顺序执行，循序渐进

📌 为什么 Platform Engineer 必须精通 Git？

Git 不只是"存代码的地方"，它是团队协作的核心基础设施。平台架构师面试中，面试官会通过你的 Git workflow 判断你是否有工程团队协作经验。精通 Git 的人，在 code review、CI/CD pipeline 设计、多环境发布管理中都能体现高层次的工程思维。

第一章：基础概念与环境搭建

1.1 Git 的核心模型（必须理解）

Git 的设计基于三棵树（Three Trees）：

Working Directory  →  Staging Area (Index)  →  Repository (.git)
     工作区                  暂存区                    仓库

Working Directory：你实际编辑文件的地方
Staging Area：git add 后，准备提交的快照
Repository：git commit 后永久保存的历史记录

💡 高阶思维：Git 存储的不是"差异（diff）"，而是完整的文件快照（snapshot），这是 Git 与 SVN 的本质区别，也是 Git 高性能的根本原因。

1.2 安装与初始配置

# 安装（Ubuntu/Debian）
sudo apt-get install git

# 安装（macOS）
brew install git

# 验证安装
git --version

# 【必须做】配置身份信息（会写入每次 commit）
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

# 配置默认编辑器（推荐 VS Code）
git config --global core.editor "code --wait"

# 配置默认主分支名（现代标准）
git config --global init.defaultBranch main

# 查看所有配置
git config --list

练习 1：初始化你的第一个仓库

mkdir git-practice && cd git-practice
git init
ls -la   # 观察 .git 目录的出现

第二章：基础操作 — 提交工作流

2.1 文件状态生命周期

Untracked → Staged → Committed → Modified → Staged → Committed
  (新建)     (add)    (commit)    (修改)     (add)     (commit)

2.2 核心命令实战

# 创建测试文件
echo "Hello Git" > README.md

# 查看状态（非常重要，养成习惯）
git status

# 将文件加入暂存区
git add README.md

# 或者添加所有变更
git add .

# 提交（-m 后写清晰的提交信息）
git commit -m "feat: add README with project description"

# 查看提交历史
git log
git log --oneline          # 简洁模式
git log --oneline --graph  # 图形模式（分支时很有用）

2.3 规范的 Commit Message（面试加分项）

工业界标准格式（Conventional Commits）：

<type>(<scope>): <description>

[optional body]

[optional footer]

类型说明：

feat：新功能
fix：修复 bug
docs：文档变更
refactor：重构
test：测试相关
chore：构建/工具变更（如 CI 配置）
perf：性能优化

示例：

feat(api): add JWT authentication middleware
fix(pipeline): resolve race condition in batch processor
docs(readme): update deployment instructions for k8s

💡 高阶思维：规范的 commit message 是自动生成 CHANGELOG、触发 CI/CD 策略（如 semantic-release 自动发版）的基础。Platform Engineer 会设计强制这种规范的 Git Hook。

练习 2：完整提交流程

echo "# My Platform Project" > README.md
echo "print('hello')" > main.py
git add README.md
git commit -m "docs: add project README"
git add main.py
git commit -m "feat: add main entry point"
git log --oneline

第三章：分支管理 — 团队协作的核心

3.1 分支本质

分支在 Git 中只是一个指向某个 commit 的轻量级指针。创建分支几乎是零成本操作。

# 查看所有分支
git branch

# 创建新分支
git branch feature/user-auth

# 切换到分支
git checkout feature/user-auth

# 创建并切换（推荐写法）
git checkout -b feature/user-auth

# 现代写法（Git 2.23+）
git switch -c feature/user-auth

# 查看所有分支（包括远程）
git branch -a

3.2 分支合并

# 场景：在 feature 分支完成开发后，合并回 main

git switch main
git merge feature/user-auth

# 如果有冲突，解决后：
git add <conflicted-file>
git commit -m "merge: resolve conflict in user-auth feature"

# 合并后删除 feature 分支（保持整洁）
git branch -d feature/user-auth

3.3 Rebase vs Merge（关键概念）

# Merge：保留完整历史，产生 merge commit
# Rebase：重写历史，保持线性，更整洁

# Rebase 示例
git switch feature/my-feature
git rebase main   # 将 feature 的 commits 移到 main 最新节点之后

# 交互式 rebase（整理提交历史）
git rebase -i HEAD~3   # 整理最近 3 个 commit

⚠️ 黄金规则：永远不要对已推送到共享远程分支的 commit 做 rebase，这会重写公共历史，破坏团队其他人的工作。

💡 高阶思维：面试中被问 "rebase vs merge" 时，回答应该上升到团队 Git 策略层面：小团队快速迭代用 rebase 保持线性历史；大型开源项目用 merge 保留完整上下文。Platform 团队需要在 CI 策略中强制执行这个选择。

练习 3：分支开发流程

git switch -c feature/data-pipeline
echo "pipeline code" > pipeline.py
git add . && git commit -m "feat(pipeline): add base data pipeline"
git switch main
git merge feature/data-pipeline
git branch -d feature/data-pipeline
git log --oneline --graph

第四章：远程仓库操作

4.1 连接远程仓库

# 克隆远程仓库
git clone https://github.com/user/repo.git
git clone git@github.com:user/repo.git   # SSH 方式（推荐）

# 查看远程仓库配置
git remote -v

# 添加远程仓库
git remote add origin https://github.com/user/repo.git

# 修改远程地址
git remote set-url origin git@github.com:user/repo.git

4.2 推送与拉取

# 推送本地分支到远程
git push origin main
git push origin feature/my-feature

# 首次推送并建立追踪关系（之后可直接 git push）
git push -u origin main

# 拉取远程变更（fetch + merge）
git pull origin main

# 更安全的方式：先 fetch 再 rebase
git fetch origin
git rebase origin/main

# 强制推送（⚠️ 谨慎使用，仅在个人分支上）
git push --force-with-lease   # 比 --force 更安全，会检查远程是否有新提交

4.3 SSH 密钥配置（工作必备）

# 生成 SSH 密钥
ssh-keygen -t ed25519 -C "your.email@example.com"

# 查看公钥（复制到 GitHub/GitLab 的 SSH Keys 设置）
cat ~/.ssh/id_ed25519.pub

# 测试连接
ssh -T git@github.com

练习 4：远程仓库操作

# 在 GitHub 创建一个新仓库，然后：
git remote add origin git@github.com:yourname/git-practice.git
git push -u origin main

# 模拟团队成员提交：在 GitHub 上直接编辑文件，然后：
git fetch origin
git log --oneline origin/main  # 查看远程新提交
git pull origin main

第五章：撤销与修复操作

5.1 常用撤销命令

# 撤销工作区修改（未 add）
git restore <file>             # 现代写法
git checkout -- <file>         # 旧写法

# 撤销暂存（已 add，未 commit）
git restore --staged <file>

# 修改最后一次 commit（未推送时）
git commit --amend -m "新的 commit 信息"
git commit --amend --no-edit   # 只添加文件，不改信息

# 创建一个新 commit 来撤销某次提交（安全，适合已推送的情况）
git revert <commit-hash>

# 回退到某个版本（⚠️ 危险操作）
git reset --soft HEAD~1   # 撤销 commit，保留暂存区
git reset --mixed HEAD~1  # 撤销 commit，清空暂存区（默认）
git reset --hard HEAD~1   # 撤销 commit，丢弃所有变更

💡 高阶思维：revert vs reset 的选择是团队协作中的关键决策。已推送的 commits 永远用 revert（保留审计轨迹），未推送的可以用 reset 整理历史。Platform Engineer 会在 protected branch 上禁止 force push 来强制执行这个原则。

5.2 Stash — 临时保存工作

# 保存当前未完成的工作
git stash
git stash save "WIP: working on feature X"

# 查看 stash 列表
git stash list

# 恢复最近的 stash
git stash pop       # 恢复并删除
git stash apply     # 恢复但保留

# 恢复指定 stash
git stash apply stash@{2}

# 删除 stash
git stash drop stash@{0}
git stash clear   # 清空所有

练习 5：撤销操作

echo "wrong code" > bug.py
git add bug.py
git restore --staged bug.py   # 撤销暂存
git restore bug.py             # 撤销修改

echo "feature in progress" > wip.py
git stash save "WIP: experimenting with new feature"
git stash list
git stash pop

第六章：Git 工作流策略

6.1 GitHub Flow（推荐入门）

main（始终可部署）
  ↑
feature/xxx  →  Pull Request  →  Code Review  →  merge to main  →  deploy

流程：

从 main 创建 feature 分支
提交代码
开 Pull Request（PR）
Code Review
合并到 main
自动触发 CI/CD 部署

6.2 Git Flow（适合版本化发布）

main（生产版本，带 tag）
develop（集成分支）
feature/xxx（功能开发）
release/1.2.0（发布准备）
hotfix/critical-bug（紧急修复）

6.3 Trunk-Based Development（大厂主流）

main/trunk（唯一主干，高频合并）
short-lived feature branches（存活 < 2天）
feature flags（控制功能开关，不靠分支）

💡 高阶思维：Google、Facebook、Databricks 等大厂普遍使用 Trunk-Based Development 配合 Feature Flags。这种策略减少了"合并地狱"，支持持续集成。作为 Platform Engineer，你需要能向面试官解释：为什么这种策略在大规模团队中更优于 Git Flow，以及如何用 CI/CD 配置来支持这个流程。

第七章：高级工具与技巧

7.1 Cherry-pick

# 将某个特定 commit 应用到当前分支
git cherry-pick <commit-hash>

# 使用场景：在 hotfix 分支修复 bug 后，将这个 fix 同步到 develop 分支
git switch develop
git cherry-pick abc1234

7.2 Bisect — 二分查找 Bug

# 快速找到引入 bug 的 commit
git bisect start
git bisect bad           # 当前版本有 bug
git bisect good v1.0.0  # 这个版本是好的
# Git 自动切换到中间版本，测试后：
git bisect good  # 或 git bisect bad
# 重复直到找到出问题的 commit
git bisect reset   # 结束后重置

7.3 Git Hooks — 自动化质量控制

# 位置：.git/hooks/
# 示例：pre-commit hook 自动运行 linter

cat > .git/hooks/pre-commit << 'EOF'
#!/bin/sh
echo "Running linter..."
flake8 . --count --select=E9,F63,F7,F82
if [ $? -ne 0 ]; then
  echo "Linting failed. Commit aborted."
  exit 1
fi
EOF

chmod +x .git/hooks/pre-commit

推荐使用 pre-commit 框架管理 hooks：

pip install pre-commit
# 创建 .pre-commit-config.yaml 配置文件
pre-commit install

7.4 有用的别名配置

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "restore --staged"

7.5 .gitignore 最佳实践

# 创建 .gitignore
cat > .gitignore << 'EOF'
# Python
__pycache__/
*.pyc
*.egg-info/
.venv/
dist/

# Data & Models（不要提交大文件！）
*.csv
*.parquet
data/raw/
models/weights/

# 环境变量（绝对不要提交！）
.env
*.env.local
secrets/

# IDE
.vscode/
.idea/
*.swp

# OS
.DS_Store
Thumbs.db
EOF

git add .gitignore
git commit -m "chore: add gitignore for Python project"

⚠️ 绝对不要提交：密钥、API Token、数据库密码、大型数据文件。使用 git-secrets 或 truffleHog 进行自动检测。

第八章：团队协作实战流程

8.1 完整的 Pull Request 流程

# 1. 确保本地 main 是最新的
git switch main
git pull origin main

# 2. 创建功能分支（命名规范）
git switch -c feature/TICKET-123-add-pipeline-monitor

# 3. 开发并提交（小步提交）
git add src/monitor.py
git commit -m "feat(monitor): add pipeline health check endpoint"

git add tests/test_monitor.py
git commit -m "test(monitor): add unit tests for health check"

# 4. 推送前先 rebase（保持历史整洁）
git fetch origin
git rebase origin/main

# 5. 推送
git push -u origin feature/TICKET-123-add-pipeline-monitor

# 6. 在 GitHub/GitLab 创建 PR，等待 Code Review

# 7. Review 后合并，删除远程分支
# （通常在 PR 界面点击操作）

# 8. 本地清理
git switch main
git pull origin main
git branch -d feature/TICKET-123-add-pipeline-monitor

8.2 解决合并冲突

# 当 merge 或 rebase 出现冲突时
git status   # 查看冲突文件，显示 "both modified"

# 打开冲突文件，内容如下：
# <<<<<<< HEAD（你的修改）
# your code
# =======
# their code
# >>>>>>> feature-branch（别人的修改）

# 手动编辑解决冲突，然后：
git add <resolved-file>
git rebase --continue   # 或 git merge --continue

第九章：快速参考 Cheatsheet

操作	命令
初始化仓库	`git init`
克隆仓库	`git clone <url>`
查看状态	`git status`
添加文件	`git add <file>` / `git add .`
提交	`git commit -m "message"`
查看历史	`git log --oneline --graph`
创建分支	`git switch -c <branch>`
切换分支	`git switch <branch>`
合并分支	`git merge <branch>`
变基	`git rebase <branch>`
推送	`git push -u origin <branch>`
拉取	`git pull origin main`
临时保存	`git stash` / `git stash pop`
撤销暂存	`git restore --staged <file>`
撤销修改	`git restore <file>`
安全回退	`git revert <hash>`
查看差异	`git diff` / `git diff --staged`
标签	`git tag v1.0.0`

第十章：学习路径与下一步

对你求职的直接价值

配置好规范 Git workflow 的项目（有清晰的 commit history、PR 记录、分支策略说明）会让招聘经理看到你具备团队协作的工程成熟度，这是从 IC（Individual Contributor）到 Platform Engineer 的关键信号之一。

在 GitHub 的 README 中加入一段 Contributing Guide，说明你的项目使用 Conventional Commits + GitHub Flow，这本身就是一个很好的 portfolio 亮点。

Generated for Frankfurt Platform Engineering Job Hunt 2026