第七章 Git 高级用法与实用配置

随着项目规模增长，常规操作时常难以应对特殊场景——例如不想跟踪某个文件、需要临时切换分支但工作区尚未清理完毕，或者希望简化冗长的命令。这些情况下，Git 的进阶功能便能有效助你解决问题。

7.1 .gitignore —— 配置忽略规则，避免误提交

在项目根目录下创建 .gitignore 文件，明确指定哪些文件或目录应当被 Git 完全忽略。几乎每个项目都离不开它，否则编译产物、依赖包或本地配置文件很容易被意外提交，带来不必要的麻烦。

常见需要忽略的内容包括：

• 编译产物：*.class、*.o、*.exe
• 依赖目录：node_modules/、vendor/、__pycache__/
• 环境配置：.env、*.local
• IDE 配置：.idea/、.vscode/、*.swp
• 日志文件：*.log
• 系统文件：.DS_Store、Thumbs.db

以下是一个典型的 .gitignore 示例：

# 忽略所有 .log 文件
*.log
# 但跟踪这个特定的 .log 文件（例外规则）
!important.log
# 忽略 build 目录下的所有内容
build/
# 忽略根目录下的 temp 文件
/temp
# 忽略 doc 下所有 .txt 文件，但保留 notes.txt
doc/*.txt
!doc/notes.txt
# 忽略所有以 ~ 结尾的文件
*~
# 忽略 node_modules 目录
node_modules/
# 忽略环境变量文件
.env
.env.local

如果想检查当前哪些文件被忽略，可执行以下命令：

git status --ignored

7.2 贮藏（Stash） —— 临时保存工作区修改

正在开发中途，却需要紧急切换到其他分支修复 bug，又舍不得提交半成品代码？git stash 正是为此而生。它能够将工作区与暂存区的更改存储到一个“堆栈”内，使工作区恢复干净状态，待切回后再恢复继续工作。

# 贮藏当前修改（包括暂存区和工作区）
git stash
# 贮藏时添加描述信息
git stash push -m "WIP: login feature"
# 查看贮藏列表
git stash list
# 应用最近的贮藏（保留贮藏记录）
git stash apply
# 应用特定贮藏
git stash apply stash@{1}
# 应用并删除贮藏
git stash pop
# 删除指定贮藏
git stash drop stash@{0}
# 清空所有贮藏
git stash clear
# 从贮藏创建分支（若贮藏的改动与当前分支冲突，使用此方法）
git stash branch new-branch stash@{0}

7.3 别名（Alias） —— 自定义快捷命令

Git 命令有时过于冗长。例如，每次查看漂亮的日志图都需要输入一长串 log --oneline --graph --decorate --all。别名的作用正是将长命令映射为简洁的单词，提升操作效率。

# 配置别名
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --global alias.unstage "reset HEAD --"
git config --global alias.last "log -1 HEAD"
git config --global alias.tree "log --graph --pretty=oneline --abbrev-commit"
# 使用别名
git st        # 代替 git status
git lg        # 精美的日志图
git unstage file
git last

7.4 子模块 —— 管理外部依赖仓库

当项目需要依赖另一个 Git 仓库（如第三方库），并且期望将其作为项目子目录直接管理时，子模块提供了最干净的方式。它能将外部仓库的某个固定版本嵌入当前项目，同时保持各自独立的提交历史。

# 添加子模块
git submodule add https://github.com/jquery/jquery.git libs/jquery
# 克隆包含子模块的仓库（需额外拉取）
git clone --recursive 
# 或在已克隆的仓库中初始化子模块
git submodule init
git submodule update
# 更新子模块到最新
git submodule update --remote
# 查看子模块状态
git submodule status

7.5 搜索与调试

代码维护过程中，常常需要追溯某行代码的修改者，或定位某个 bug 由哪次提交引入。Git 为此提供了成套的搜索与调试工具。

# 按文本搜索历史（查找哪次提交引入了某行代码）
git grep "函数名" $(git rev-list --all)
# 使用 blame 查看每一行的最后修改者
git blame hello.py
# 二分查找定位引入 bug 的提交（git bisect）
git bisect start
git bisect bad           # 当前版本有 bug
git bisect good v1.0     # v1.0 没有 bug
# Git 会切换到一个中间提交，测试后标记
git bisect good          # 如果这个版本正常
git bisect bad           # 如果这个版本有 bug
# 重复直到找到第一个 bad 提交
git bisect reset         # 退出二分模式

第八章 常见工作流与协作模式

个人使用 Git 可以灵活自由，但团队协作时需要约定统一的协作规范。不同规模的团队和项目类型，适合采用不同的工作流模式。

8.1 集中式工作流（类似 SVN）

所有开发者直接向中央仓库的 master 分支推送代码。这种方式简单直接，适用于两三人的小型临时项目。缺点也很明确：多人同时修改同一文件时，极易产生冲突。

8.2 功能分支工作流（Feature Branch Workflow）

每个新功能或修复任务在独立分支上开发，完成后合并回主分支。这是目前最普遍的做法，既能隔离风险，又能让代码审查有条不紊地进行。

# 开发新功能
git checkout -b feature-awesome
# ... 开发，多次提交
git push -u origin feature-awesome
# 创建 Pull Request / Merge Request
# 代码审查通过后合并
git checkout master
git pull
git merge --no-ff feature-awesome
git push
git branch -d feature-awesome

8.3 Git Flow（经典分支模型）

对于具有严格发布周期的项目，Git Flow 堪称行业标准。它定义了两条长期分支：master（生产环境代码）和 develop（开发主线），外加三种临时分支：feature/*、release/*、hotfix/*。

# 初始化 Git Flow（需安装 git-flow）
git flow init
# 开始新功能
git flow feature start login
# 完成功能（合并到 develop）
git flow feature finish login
# 开始发布
git flow release start 1.0.0
# 更新版本号、文档
git flow release finish 1.0.0

8.4 GitHub Flow（简化版）

GitHub 推崇的极简流程：master 分支始终保持可部署状态，新功能从 master 拉出分支，开发完成后提交 PR，合并后立即部署。没有 develop 或 release 分支，干净利落，特别适合持续部署的团队。

8.5 Fork & Pull Request（开源协作）

这是开源项目的标准协作方式：先 Fork 原仓库至自己的账户，克隆 Fork 后的仓库，修改后推送，再向原仓库提交 Pull Request。原仓库维护者审核并合并代码。

# 添加上游仓库（原项目）
git remote add upstream https://github.com/original/repo.git
# 获取上游更新
git fetch upstream
# 将上游 master 合并到本地 master
git checkout master
git merge upstream/master
# 推送同步到自己的 fork
git push origin master

第九章 常见问题与解决方案

遇到 Git 问题时不必慌张，大多情况它都能提供“兜底”机制。以下列举几个开发者几乎都会碰到的典型问题。

9.1 如何撤销已经 push 的提交？

分两种情况处理：若可以接受改写历史（例如只有你一个人使用该分支），采用 reset 并强制推送；若已有多人协作，则使用 revert 生成反向提交，不破坏历史记录。

# 方法1：回退本地并强制推送（会改写历史）
git reset --hard HEAD~1
git push --force-with-lease origin master
# 方法2：使用 git revert 创建反向提交（安全，不破坏历史）
git revert HEAD      # 撤销最近一次提交，生成新提交
git push origin master

9.2 忘记添加某个文件到上一次提交

解决方法很简单：将文件添加到暂存区，然后使用 --amend 补进上次提交，连注释都无需修改。

git add forgotten.txt
git commit --amend --no-edit

9.3 提交信息写错了（未 push）

git commit --amend -m "新的正确信息"

9.4 误删分支，如何恢复？

分支虽被删除，但提交记录仍保留在 reflog 中。找到最后一次提交的哈希值，重新基于它创建分支即可。

# 找到被删除分支的最后一次提交哈希
git reflog
# 基于该哈希创建新分支
git branch recovered-branch 

9.5 如何合并某个分支的特定提交（cherry-pick）？

若只想拉取另一分支上的某一次改动，而非整个分支的合并，可使用 git cherry-pick。

# 切换到目标分支
git checkout master
# 将 feature 分支上的某次提交应用到当前分支
git cherry-pick 

9.6 如何清空工作区所有未跟踪文件？

临时文件或构建产物堆积时，可使用 git clean 一次性清理。执行前建议先用 -n 预览待删除文件。

# 查看哪些文件会被删除（dry-run）
git clean -n
# 删除未跟踪文件
git clean -f
# 同时删除未跟踪目录
git clean -fd
# 删除 .gitignore 忽略的文件也一并删除（危险）
git clean -x

第十章 图形化工具与 IDE 集成

命令行是 Git 的基础技能，但图形化界面能够帮助更直观地理解 Git 内部逻辑。尤其对于分支、合并等操作的新手，可视化工具可以瞬间看清代码演变过程。

10.1 常用 GUI 客户端

• Git GUI：Git 自带，运行 git gui 即可启动。
• GitK：查看历史使用 gitk。
• Sourcetree（Windows/Mac，免费）
• GitKraken（跨平台，功能强大）
• GitHub Desktop（简洁够用）
• VS Code：内置 Git 支持，点击即可提交、推送、分支管理，冲突解决体验出色。

10.2 VS Code 内置 Git 常用操作

在 VS Code 左侧的“源代码管理”面板中，你可以直观查看所有更改、暂存文件、输入提交信息并推送，一气呵成。分支切换只需点击左下角当前分支名称。差异查看和冲突解决均提供友好的内联界面。

综合实战：基于 Git 的协作模拟

理论与实践相结合。假设你和同事合作开发一个 Web 项目，你负责“用户注册”模块，同事负责“用户登录”模块。下面是一套完整的协作流程——从克隆到合并，再到后续迭代。

# 第一天：克隆项目
git clone https://github.com/company/webapp.git
cd webapp
# 创建你的功能分支
git checkout -b feature-register
# 添加注册功能文件
echo "
注册表单
" > register.html
git add register.html
git commit -m "feat: 添加注册页面基础结构"
# 同事也创建了他的分支
git checkout -b feature-login   # 在他的电脑上
# 你继续完善注册功能
echo "后端验证逻辑" >> register.html
git commit -am "feat: 注册表单后端验证"
# 同事提交他的工作
echo "登录框" > login.html
git add login.html
git commit -m "feat: 添加登录页面"
# 同事推送他的分支
git push origin feature-login
# 你推送你的分支
git push origin feature-register
# 在 GitHub/GitLab 上分别创建 Pull Request 到 main 分支
# 代码审查后，合并两个 PR
# 第二天，你需要基于最新的 main 继续工作
git checkout main
git pull origin main          # 获取别人合并后的最新代码
# 删除本地已合并的功能分支
git branch -d feature-register
# 创建新的功能分支
git checkout -b feature-profile

至此，一个典型的 Git 协作循环已完整走通。从各自在分支上开发，到推送、提交 PR、审查合并，再到拉取最新代码并开启下一个功能——整个过程环环相扣。熟练之后，这些操作将成为肌肉记忆，极大提升协作效率。