5.1 交互式暂存

交互式暂存是 Git 中一个强大的特性，允许你精确控制哪些更改应该被提交。这对于保持提交历史的清晰和有意义非常有帮助，尤其是当你在一个大型提交中做了多项不相关的更改时。

5.1.1 基础知识讲解

• 交互式暂存使用：通过 git add -p 或 git add --patch 命令启动，Git 会将文件更改分成小块（称为 “hunks”）。对于每个块，Git 会询问你是否要暂存它、编辑它、忽略它，或者将更改分割得更细。
• 选择更改：在交互式模式中，你可以选择暂存全部更改、某些特定的更改，或者甚至是一个大更改中的一小部分。
• 暂存策略：这种方式特别适用于当你的工作包含多个逻辑上独立的更改，但你想在不同的提交中分别提交它们。

5.1.2 重点案例：为 Python 项目分阶段提交

假设你正在开发一个 Python 项目，你在过去几个小时内完成了两项工作：一是优化了现有功能的性能，二是修复了一个长期存在的 bug。

步骤 1：开始交互式暂存

你的更改散布在几个文件中，但你想分两个提交分别提交它们。

git add -p

Git 逐一展示每个更改，让你决定是否暂存。

步骤 2：选择性暂存优化更改

首先，你只选择与性能优化相关的更改进行暂存。对于每个展示的块，只有当它与性能优化相关时，你才选择 “y”（是）。

步骤 3：提交优化更改

完成暂存后，你提交了这部分更改：

git commit -m "Optimize existing functionality for better performance"

5.1.3 拓展案例 1：细粒度控制更改

在某些情况下，一个文件中的一个更改可能同时包含你希望提交和你希望暂时保留的更改。通过选择 e（编辑）选项，你可以手动编辑每个块，只保留你想要暂存的那部分。

5.1.4 拓展案例 2：处理遗漏的更改

完成性能优化的提交后，你记得还有一个小改进没有包括在内。你再次运行 git add -p，找到那个遗漏的更改，将其加入到下一个提交中，这次是关于修复 bug 的。

通过这一节，你学会了如何利用交互式暂存来精确控制你的提交内容，这不仅可以让你的提交历史更加清晰，还能在团队合作中减少混乱。记住，一个好的提交历史就像是一个好的故事，它应该清晰、连贯，每次提交都有其目的和理由。现在，就让我们用这些技巧来编织我们代码的故事吧！

---

5.2 使用 Rebase 优化提交历史

在 Git 的世界里，rebase 是一种强大的魔法，可以帮助你重新书写代码的历史。不是真的改变过去，而是让提交历史更加整洁和有序。通过 rebase，你可以将一系列的提交重新基于另一个分支的顶部，或者整理你自己的提交历史，使其更加清晰。

5.2.1 基础知识讲解

• 什么是 Rebase：rebase 允许你将一个分支的更改重新应用到另一个分支上。与合并（merge）不同，rebase 通过重新创建更改在新的基础上，使得历史成为一条直线，避免了不必要的合并提交。
• 使用场景：rebase 最常见的使用场景包括：将本地分支更新到最新的主分支状态，以及在将更改合并到主分支前清理提交历史。
• 交互式 Rebase：git rebase -i 允许你交互式地选择每个提交进行重新排序、合并、编辑或删除。这是优化你的提交历史的强大工具。

5.2.2 重点案例：整理 Python 项目的提交历史

假设你正在开发一个 Python 项目，并在 feature-branch 上进行了一系列的提交，包括一些新功能的添加和几个 bug 的修复。

步骤 1：开始交互式 Rebase

你想在将这个分支合并到 main 前整理你的提交历史：

git checkout feature-branch
git rebase -i main

这会打开一个编辑器，列出了你准备重新整理的所有提交。

步骤 2：重新排序和合并提交

在编辑器中，你决定将一些小的 bug 修复合并成一个单独的提交，并将一些相关的更改放在一起。

5.2.3 拓展案例 1：解决 Rebase 过程中的冲突

在 rebase 过程中，你遇到了一些冲突。Git 会停下来让你解决冲突，然后继续 rebase 流程：

# 解决所有冲突
git add .
git rebase --continue

如果任何时刻你决定这个 rebase 是个坏主意，你可以通过 git rebase --abort 来取消整个操作。

5.2.4 拓展案例 2：使用 Rebase 精简提交

在开发一个新的数据处理功能时，你创建了多个“探索性”的提交，现在你希望在合并到 main 分支前将它们精简成更少的、更有意义的提交。

git rebase -i HEAD~5

你选择了 squash 选项来合并这些提交，并为合并后的提交编写了一个清晰的消息，说明了这个功能的实现和目的。

通过这一章，你已经学到了如何使用 rebase 来优化你的提交历史，让它更加清晰和有序。记住，一个好的提交历史不仅能帮助你和你的团队更好地理解项目的发展过程，还能在需要追踪问题时，提供极大的帮助。现在，拿起你的魔法杖，开始使用 rebase 来整理你的代码历史吧！

---

5.3 钩子脚本自动化工作流

在 Git 的魔法世界中，钩子脚本（Git hooks）是那些藏在幕后的小精灵，它们在 Git 操作的特定时刻悄悄地执行任务，从而自动化你的开发工作流。这些脚本可以帮助你自动运行测试、检查代码风格、甚至自动部署应用，让你的开发过程更加高效和规范。

5.3.1 基础知识讲解

• Git 钩子类型：Git 提供了多种钩子，例如 pre-commit、post-commit、pre-push 等，分别在不同的操作前后触发。
• 钩子脚本位置：这些脚本位于 Git 仓库的 .git/hooks 目录下。默认情况下，Git 提供了一些示例脚本，但它们默认是禁用的（文件名以 .sample 结尾）。
• 激活钩子脚本：要启用一个钩子脚本，你需要移除文件扩展名 .sample，并确保该脚本是可执行的。

5.3.2 重点案例：自动运行 Python 单元测试

假设你正在开发一个 Python 项目，并希望在每次提交前自动运行单元测试，确保只有通过所有测试的代码才能被提交。

步骤 1：创建 pre-commit 钩子

在 .git/hooks 目录下创建一个名为 pre-commit 的文件（无文件扩展名），并添加以下内容：

#!/bin/sh
pytest

步骤 2：使钩子脚本可执行

通过运行以下命令，使得 pre-commit 钩子脚本可执行：

chmod +x .git/hooks/pre-commit

现在，每次执行 git commit 命令前，pytest 将自动运行。如果测试失败，提交将被阻止。

5.3.2 拓展案例 1：自动检查 Python 代码风格

想要在提交前自动检查代码风格，确保代码符合 PEP 8 规范？你可以在 pre-commit 钩子中集成 flake8。

更新你的 pre-commit 钩子脚本，包含以下内容：

#!/bin/sh
flake8 .
if [ $? -ne 0 ]; then
    echo "Code style checks failed, commit aborted."
    exit 1
fi

这样，只有当你的代码完全符合 PEP 8 规范时，才能成功提交。

5.3.4 拓展案例 2：使用钩子自动部署应用

如果你的项目被部署在一个可以通过 Git 钩子自动更新的服务器上，你可以使用 post-receive 钩子来自动部署应用。

在服务器的裸仓库（bare repository）中的 .git/hooks 目录下创建 post-receive 钩子，包含如下内容：

#!/bin/sh
GIT_WORK_TREE=/path/to/your/deployment/directory git checkout -f

这样，每当你向这个仓库 push 更改时，post-receive 钩子会自动将更改检出到部署目录。

通过这一章，你已经探索了如何使用 Git 钩子脚本自动化你的开发工作流，从自动运行测试到代码风格检查，再到自动部署应用。记住，利用这些小精灵的力量，你可以将重复的任务自动化，让你有更多时间专注于创造伟大的代码。现在，让我们继续探索 Git 的更多秘密，让你的开发之旅更加顺畅！