当前位置：首页 > news >正文

协作开发攻略：Git全面使用指南 — 第二部分高级技巧与最佳实践

news 来源：原创 2025/7/1 18:45:57

Git 是一种分布式版本控制系统，用于跟踪文件和目录的变更。它能帮助开发者有效管理代码版本，支持多人协作开发，方便代码合并与冲突解决，广泛应用于软件开发领域。

文中内容仅限技术学习与代码实践参考，市场存在不确定性，技术分析需谨慎验证，不构成任何投资建议。

Git LFS
📖 引言 🔥

为什么选择Git？
Git的基本概念简述
安装与配置Git环境

📖 第一部分 Git基础 🔥

版本控制概述
初始化仓库
文件状态管理
提交更改
查看历史记录
撤销操作
分支管理
远程仓库
标签管理

📖 第二部分高级技巧与最佳实践 🔥

交互式重置
变基操作
子模块
Git Hooks
全性和身份验证

📖 第三部分特殊应用场景 🔥

大型文件存储——Git LFS 解决方案
协作开发流程——Git Flow/GitHub/GitLab CI/CD 集成

📖 结语 🔥

要点速查
进一步学习资源
常见问题解答

第二部分高级技巧与最佳实践

10. 交互式重置

在 Git 中，交互式重置是一种强大的工具，可以帮助你重新组织提交历史或更精细地控制暂存区的内容。以下是如何使用交互式重置来重新组织提交历史和交互式地添加部分内容至暂存区的详细内容。

重新组织提交历史

git rebase -i 命令允许你交互式地修改提交历史。你可以进行多种操作，如合并提交、删除提交、重新排序提交等。

启动交互式 rebase：
使用 git rebase -i <commit-hash> 命令可以启动交互式 rebase。<commit-hash> 是你要开始重写的最后一个提交之前的那个提交。
```
git rebase -i HEAD~3
```
这条命令会打开一个文本编辑器，显示最近的三个提交（包括当前的 HEAD）。
编辑提交历史：
在编辑器中，你会看到类似以下的内容：
```
pick abc1234 (HEAD -> main) Add new feature
pick def5678 Fix bug in new feature
pick ghi9012 Update documentation
```
每一行代表一个提交，并且每行前面有一个关键字（如 pick）。你可以对这些关键字进行修改以执行不同的操作：
- pick：保留该提交。
- reword：保留该提交，但允许你修改提交信息。
- edit：保留该提交，但在应用该提交后暂停 rebase，允许你进一步修改提交。
- squash：将该提交与其前一个提交合并。
- fixup：将该提交与其前一个提交合并，但不保留该提交的提交信息。
- exec：在每个提交之后运行一个 shell 命令。
- drop：删除该提交。
例如，如果你想将 Fix bug in new feature 提交与 Add new feature 提交合并，可以将 def5678 行的 pick 改为 squash：
```
pick abc1234 (HEAD -> main) Add new feature
squash def5678 Fix bug in new feature
pick ghi9012 Update documentation
```
保存并退出编辑器：
保存并退出编辑器后，Git 会按照你的指示重新组织提交历史。如果选择了 squash 或 fixup，Git 会要求你编辑合并后的提交信息。
完成 rebase：
如果一切顺利，rebase 会自动完成。如果有冲突，你需要手动解决冲突，然后继续 rebase：
```
git rebase --continue
```

实战示例

假设你在 main 分支上进行了几次提交，现在希望将这些提交重新组织。

查看当前提交历史：

git log --oneline

输出可能如下：

ghi9012 (HEAD -> main) Update documentation
def5678 Fix bug in new feature
abc1234 Add new feature

启动交互式 rebase：
```
git rebase -i HEAD~3
```

编辑提交历史：
在编辑器中，将 def5678 的 pick 改为 squash：

pick abc1234 Add new feature
squash def5678 Fix bug in new feature
pick ghi9012 Update documentation

保存并退出编辑器：
保存并退出编辑器后，Git 会要求你编辑合并后的提交信息：

# This is a combination of 2 commits.
# The first commit's message is:
Add new feature# This is the 2nd commit message:Fix bug in new feature# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch main
# Your branch is up to date with 'origin/main'.
#
# Changes to be committed:
#       modified:   src/feature.py
#

你可以编辑这个信息，然后保存并退出编辑器。

完成 rebase：
```
git rebase --continue
```

交互式地添加部分内容至暂存区

git add -p 命令允许你交互式地选择要添加到暂存区的部分更改。这对于更精细地控制提交内容非常有用。

查看当前状态：
使用 git status 命令查看当前工作区的状态。

git status

输出可能如下：

On branch main
Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified:   src/main.pymodified:   README.md

交互式地添加部分内容至暂存区：
使用 git add -p 命令启动交互式添加。
```
git add -p
```
选择要添加的更改：
Git 会逐个显示文件中的更改块，并提示你选择要添加到暂存区的更改。选项包括：
- y：添加该更改块。
- n：不添加该更改块。
- a：添加所有剩余的更改块。
- d：不添加任何剩余的更改块。
- q：退出而不添加任何更改块。
- s：将当前更改块分割成更小的块。
- e：手动编辑当前更改块。
例如，对于 src/main.py 文件中的更改，Git 会显示：
```
diff --git a/src/main.py b/src/main.py
index 1234567..89abcde 100644
--- a/src/main.py
+++ b/src/main.py
@@ -10,7 +10,7 @@def main():print("Hello, World!")
-    print("This is a test.")
+    print("This is a test with some changes.")Stage this hunk [y,n,q,a,d,/,e,?]? y
```
完成添加：
继续选择其他文件中的更改，直到所有需要的更改都已添加到暂存区。
提交更改：
使用 git commit 命令提交更改。
```
git commit -m "Add specific changes to main.py"
```

实战示例

假设你在 src/main.py 和 README.md 文件中进行了多个更改，但只希望将 src/main.py 中的一部分更改提交。

查看当前状态：

git status

输出可能如下：

On branch main
Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified:   src/main.pymodified:   README.md

交互式地添加部分内容至暂存区：
```
git add -p
```

选择要添加的更改：

diff --git a/src/main.py b/src/main.py
index 1234567..89abcde 100644
--- a/src/main.py
+++ b/src/main.py
@@ -10,7 +10,7 @@def main():print("Hello, World!")
-    print("This is a test.")
+    print("This is a test with some changes.")Stage this hunk [y,n,q,a,d,/,e,?]? y

完成添加：
继续选择其他文件中的更改，直到所有需要的更改都已添加到暂存区。

提交更改：

git commit -m "Add specific changes to main.py"

11. 变基操作

变基（Rebase）是 Git 中一个强大的工具，用于将一个分支的更改应用到另一个分支上。与合并（Merge）不同，变基会重新应用提交历史，使得提交历史更加线性和整洁。以下是关于变基操作的详细内容，包括什么是变基、何时使用它以及如何解决变基过程中的冲突。

什么是变基？何时使用它？

变基是一种将一个分支的更改应用到另一个分支上的方法。具体来说，变基会将当前分支的提交历史“移动”到目标分支的顶部，使提交历史看起来像是在目标分支上直接进行的一样。这使得提交历史更加线性和易于理解。

何时使用变基？

保持提交历史的线性：变基可以使提交历史更加线性和简洁，特别适合于特性分支和小团队。
清理提交历史：通过交互式变基，可以删除不必要的提交或合并多个提交，使提交历史更清晰。
协作开发：在多人协作开发时，变基可以帮助你保持本地分支与远程分支同步，避免频繁的合并提交。
简化 Pull Request：在向主分支提交 Pull Request 之前，使用变基可以使提交历史更干净，便于代码审查。

基本用法

普通变基：
使用 git rebase <target-branch> 命令将当前分支的更改应用到目标分支上。
```
git rebase main
```
交互式变基：
使用 git rebase -i <target-commit> 命令启动交互式变基，允许你修改提交历史。
```
git rebase -i HEAD~3
```

解决变基过程中的冲突

在变基过程中，如果目标分支上有新的提交，可能会导致冲突。以下是解决这些冲突的步骤：

开始变基：
使用 git rebase <target-branch> 命令开始变基。
```
git rebase main
```

识别冲突：
如果变基过程中出现冲突，Git 会暂停并提示哪些文件存在冲突。

error: could not apply abc1234... Add new feature
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git rebase --continue'

解决冲突：
打开冲突文件，手动解决冲突。冲突标记与合并冲突类似：
```
<<<<<<< HEAD
def main():print("Hello, World!")
=======
def main():print("Hello, Git!")
>>>>>>> feature-branch
```
根据实际需求编辑文件，选择保留或合并冲突部分。例如：
```
def main():print("Hello, World and Git!")
```
添加解决冲突后的文件到暂存区：
使用 git add 命令将解决冲突后的文件添加到暂存区。
```
git add src/main.py
```
继续变基：
使用 git rebase --continue 命令继续变基过程。
```
git rebase --continue
```
放弃变基：
如果你在变基过程中遇到了难以解决的问题，可以使用 git rebase --abort 命令放弃变基，回到变基前的状态。
```
git rebase --abort
```

实战示例

假设你在 feature-branch 上进行了开发，并希望将其变基到 main 分支上。

切换到 feature-branch：
```
git checkout feature-branch
```

开始变基：

git rebase main

输出可能如下：

First, rewinding head to replay your work on top of it...
Applying: Add new feature
Using index info to reconstruct a base tree...
M    src/main.py
Falling back to patching base and 3-way merge...
Auto-merging src/main.py
CONFLICT (content): Merge conflict in src/main.py
error: could not apply abc1234... Add new feature
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git rebase --continue'

解决冲突：
打开 src/main.py 文件，解决冲突：
```
def main():print("Hello, World and Git!")
```
添加解决冲突后的文件到暂存区：
```
git add src/main.py
```
继续变基：
```
git rebase --continue
```

12. 子模块

在 Git 中，子模块（Submodule）允许你将一个外部的 Git 仓库作为子目录包含在你的主项目中。这对于管理和跟踪依赖项非常有用。以下是如何包含外部项目作为子模块、更新和管理子模块的详细内容。

包含外部项目作为子模块

添加子模块：
使用 git submodule add <repository-url> <path> 命令可以将一个外部 Git 仓库作为子模块添加到你的项目中。
```
git submodule add https://github.com/username/external-project.git external-project
```
这条命令会将 external-project 仓库克隆到 external-project 目录，并在 .gitmodules 文件中记录子模块的信息。
初始化子模块：
如果你从一个已经包含子模块的仓库克隆了项目，需要初始化并更新子模块。
```
git submodule init
git submodule update
```
你也可以使用一条命令来同时初始化和更新子模块：
```
git submodule update --init --recursive
```

查看子模块状态：
使用 git status 命令可以查看子模块的状态。

git status

输出可能如下：

On branch main
Your branch is up to date with 'origin/main'.Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git restore <file>..." to discard changes in working directory)modified:   external-project (new commits)no changes added to commit (use "git add" and/or "git commit -a")

提交子模块更改：
如果你在子模块中进行了更改并希望将其包含在主项目的提交中，首先需要在子模块中进行提交。
```
cd external-project
git add .
git commit -m "Update external project"
cd ..
git add external-project
git commit -m "Update external project submodule"
```

实战示例

假设你有一个主项目 myproject，并且希望将 external-project 作为子模块包含进来。

添加子模块：

git submodule add https://github.com/username/external-project.git external-project

初始化并更新子模块：

git submodule update --init --recursive

查看子模块状态：
```
git status
```

在子模块中进行更改：

cd external-project
# 在这里进行更改
git add .
git commit -m "Update external project"
cd ..

提交子模块更改到主项目：

git add external-project
git commit -m "Update external project submodule"

更新和管理子模块

更新子模块：
使用 git submodule update 命令可以更新子模块到其最新提交。
```
git submodule update
```
更新子模块到最新远程分支：
使用 git submodule update --remote 命令可以更新子模块到其远程分支的最新提交。
```
git submodule update --remote
```
更新所有子模块：
如果你有多个子模块，可以使用 --recursive 选项来递归更新所有子模块。
```
git submodule update --init --recursive
```

删除子模块：
删除子模块需要几个步骤：

从 .gitmodules 文件中删除子模块配置。
从 .git/config 文件中删除子模块配置。
从工作树中删除子模块文件夹。
移除子模块的 Git 链接。

例如，假设你要删除 external-project 子模块：

# 从 .gitmodules 文件中删除子模块配置
sed -i '/\[submodule "external-project"\]/d' .gitmodules# 从 .git/config 文件中删除子模块配置
git config --remove-section submodule.external-project# 从工作树中删除子模块文件夹
rm -rf external-project# 移除子模块的 Git 链接
git rm -f external-project

最后，提交这些更改：

git commit -m "Remove external-project submodule"

查看子模块信息：
使用 git submodule status 命令可以查看子模块的状态。
```
git submodule status
```
输出可能如下：
```
+abc1234 external-project (heads/main)
```

同步子模块 URL：
如果你需要更改子模块的 URL，可以在 .gitmodules 文件中修改相应的 URL，然后使用 git submodule sync 命令同步更改。

# 修改 .gitmodules 文件中的 URL
[submodule "external-project"]path = external-projecturl = https://github.com/new-username/external-project.git# 同步子模块 URL
git submodule sync

实战示例

假设你已经将 external-project 作为子模块包含在 myproject 中，并且现在需要更新它。

更新子模块：
```
git submodule update
```
更新子模块到最新远程分支：
```
git submodule update --remote
```

更新所有子模块：

git submodule update --init --recursive

查看子模块状态：
```
git submodule status
```

删除子模块：

# 从 .gitmodules 文件中删除子模块配置
sed -i '/\[submodule "external-project"\]/d' .gitmodules# 从 .git/config 文件中删除子模块配置
git config --remove-section submodule.external-project# 从工作树中删除子模块文件夹
rm -rf external-project# 移除子模块的 Git 链接
git rm -f external-project# 提交更改
git commit -m "Remove external-project submodule"

13. Git Hooks

Git 钩子（Git Hooks）是一种强大的工具，允许你在特定的 Git 事件发生时自动执行脚本。这些钩子可以帮助你自动化各种任务，如代码格式检查、测试、部署等。以下是如何使用 Git 钩子以及一些常见的应用场景。

自动执行脚本

Git 钩子分为客户端钩子和服务器端钩子。客户端钩子存储在每个仓库的 .git/hooks 目录中，而服务器端钩子存储在 Git 服务器的 hooks 目录中。以下是一些常见的钩子类型及其用途：

客户端钩子

pre-commit：
在 git commit 命令之前运行。

用途：代码格式检查、静态代码分析、测试等。

# .git/hooks/pre-commit
#!/bin/sh
echo "Running pre-commit hook..."
# 运行代码格式检查
./scripts/format-check.sh
# 如果检查失败，退出并阻止提交
if [ $? -ne 0 ]; thenecho "Code format check failed. Aborting commit."exit 1
fi

post-commit：
在 git commit 命令之后运行。

用途：发送通知、日志记录等。

# .git/hooks/post-commit
#!/bin/sh
echo "Running post-commit hook..."
# 发送通知
./scripts/send-notification.sh

pre-rebase：
在 git rebase 命令之前运行。

用途：防止对某些分支进行变基。

# .git/hooks/pre-rebase
#!/bin/sh
refname=$1
if [ "$refname" = "main" ]; thenecho "Rebasing the main branch is not allowed. Aborting."exit 1
fi

post-merge：
在 git merge 命令之后运行。

用途：更新依赖项、生成文档等。

# .git/hooks/post-merge
#!/bin/sh
echo "Running post-merge hook..."
# 更新依赖项
./scripts/update-dependencies.sh

pre-push：
在 git push 命令之前运行。

用途：运行测试、验证代码质量等。

# .git/hooks/pre-push
#!/bin/sh
echo "Running pre-push hook..."
# 运行测试
./scripts/run-tests.sh
# 如果测试失败，退出并阻止推送
if [ $? -ne 0 ]; thenecho "Tests failed. Aborting push."exit 1
fi

prepare-commit-msg：
在 git commit 命令准备提交信息时运行。

用途：自动生成提交信息、添加默认信息等。

# .git/hooks/prepare-commit-msg
#!/bin/sh
msg_file=$1
if [ -z "$(cat $msg_file)" ]; thenecho "Default commit message: Initial commit" > $msg_file
fi

commit-msg：
在 git commit 命令提交信息时运行。

用途：验证提交信息格式。

# .git/hooks/commit-msg
#!/bin/sh
msg_file=$1
if ! grep -q "Fixes #[0-9]" $msg_file; thenecho "Commit message must include 'Fixes #<issue-number>'. Aborting commit."exit 1
fi

服务器端钩子

pre-receive：
在 git push 命令接收到推送数据后但在更新引用前运行。

用途：验证推送的提交、权限检查等。

# hooks/pre-receive
#!/bin/sh
while read oldrev newrev refname
do# 检查推送的提交./scripts/check-commits.sh $oldrev $newrevif [ $? -ne 0 ]; thenecho "Push rejected: Invalid commits detected."exit 1fi
done

post-receive：
在 git push 命令更新引用后运行。

用途：触发部署、发送通知等。

# hooks/post-receive
#!/bin/sh
while read oldrev newrev refname
do# 触发部署./scripts/deploy.sh
done

update：
在 git push 命令更新引用前运行。

用途：拒绝特定的推送操作。

# hooks/update
#!/bin/sh
refname=$1
oldrev=$2
newrev=$3
if [ "$refname" = "refs/heads/main" ]; thenecho "Pushing to main branch is not allowed. Aborting."exit 1
fi

钩子的应用场景介绍

代码格式检查：
使用 pre-commit 钩子在每次提交前运行代码格式检查工具（如 Prettier 或 ESLint），确保代码风格一致。
静态代码分析：
使用 pre-commit 钩子在每次提交前运行静态代码分析工具（如 SonarQube 或 PyLint），发现潜在的代码问题。
自动化测试：
使用 pre-push 钩子在每次推送前运行自动化测试（如单元测试、集成测试），确保代码质量。
代码审查：
使用 commit-msg 钩子在每次提交时验证提交信息，确保提交信息符合团队规范（如包含 JIRA 问题编号）。
依赖项管理：
使用 post-merge 钩子在每次合并后更新项目的依赖项（如 npm install 或 pip install），确保依赖项是最新的。
部署自动化：
使用 post-receive 钩子在服务器端接收推送后触发自动部署（如 Docker 部署或 CI/CD 流水线），实现持续集成和持续部署。
权限控制：
使用 pre-receive 或 update 钩子在服务器端验证推送权限，确保只有授权用户可以推送更改到特定分支（如 main 分支）。
日志记录：
使用 post-commit 或 post-receive 钩子在每次提交或推送后记录日志，便于审计和追踪。
通知系统：
使用 post-commit 或 post-receive 钩子在每次提交或推送后发送通知（如邮件、Slack 消息），及时通知团队成员。

实战示例

假设你希望在每次提交前运行代码格式检查，并在每次推送前运行自动化测试。

创建 pre-commit 钩子：

# .git/hooks/pre-commit
#!/bin/sh
echo "Running pre-commit hook..."
# 运行代码格式检查
npx prettier --check .
# 如果检查失败，退出并阻止提交
if [ $? -ne 0 ]; thenecho "Code format check failed. Aborting commit."exit 1
fi

创建 pre-push 钩子：

# .git/hooks/pre-push
#!/bin/sh
echo "Running pre-push hook..."
# 运行测试
npm test
# 如果测试失败，退出并阻止推送
if [ $? -ne 0 ]; thenecho "Tests failed. Aborting push."exit 1
fi

确保钩子文件具有可执行权限：

chmod +x .git/hooks/pre-commit
chmod +x .git/hooks/pre-push

14. 安全性和身份验证

在 Git 中，安全性和身份验证是非常重要的方面。使用 SSH 密钥进行身份验证可以提高安全性，而设置 GPG 签名则可以确保提交的真实性。以下是如何使用 SSH 密钥进行身份验证以及如何设置 GPG 签名的详细内容。

使用 SSH 密钥进行身份验证

SSH 密钥是一种非对称加密技术，允许你以更安全的方式进行身份验证。以下是生成和配置 SSH 密钥的步骤：

生成 SSH 密钥：
使用 ssh-keygen 命令生成 SSH 密钥对。
```
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
按照提示操作，通常会生成两个文件：id_rsa（私钥）和 id_rsa.pub（公钥）。
添加 SSH 密钥到 SSH 代理：
启动 SSH 代理并添加私钥。
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
```
将公钥添加到你的 Git 托管服务：
- GitHub：
  1. 登录 GitHub。
  2. 进入 Settings -> SSH and GPG keys。
  3. 点击 “New SSH key”，粘贴你的公钥内容（从 ~/.ssh/id_rsa.pub 文件中复制），然后保存。
- GitLab：
  1. 登录 GitLab。
  2. 进入 Settings -> SSH Keys。
  3. 粘贴你的公钥内容（从 ~/.ssh/id_rsa.pub 文件中复制），然后保存。
- Bitbucket：
  1. 登录 Bitbucket。
  2. 进入 Personal settings -> SSH keys。
  3. 粘贴你的公钥内容（从 ~/.ssh/id_rsa.pub 文件中复制），然后保存。
测试 SSH 连接：
使用 ssh -T git@github.com 或 ssh -T git@gitlab.com 命令测试 SSH 连接是否成功。
```
ssh -T git@github.com
```
如果成功，你会看到类似以下的消息：
```
Hi your_username! You\'ve successfully authenticated, but GitHub does not provide shell access.
```
配置 Git 使用 SSH 协议：
在克隆仓库时使用 SSH URL。
```
git clone git@github.com:username/repository.git
```

实战示例

假设你希望为你的 GitHub 账户生成和配置 SSH 密钥。

生成 SSH 密钥：
```
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
按照提示操作，生成密钥对。

添加 SSH 密钥到 SSH 代理：

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

将公钥添加到 GitHub：
- 登录 GitHub。
- 进入 Settings -> SSH and GPG keys。
- 点击 “New SSH key”，粘贴你的公钥内容（从 ~/.ssh/id_rsa.pub 文件中复制），然后保存。
测试 SSH 连接：
```
ssh -T git@github.com
```

配置 Git 使用 SSH 协议：

git clone git@github.com:username/repository.git

设置 GPG 签名以保证提交真实性

GPG（GNU Privacy Guard）签名可以帮助你确保提交的真实性和完整性。以下是生成和配置 GPG 签名的步骤：

生成 GPG 密钥：
使用 gpg 命令生成 GPG 密钥。
```
gpg --full-generate-key
```
按照提示选择密钥类型、密钥长度等，并输入个人信息。

列出 GPG 密钥：
使用 gpg --list-secret-keys --keyid-format LONG 命令查看生成的 GPG 密钥。

gpg --list-secret-keys --keyid-format LONG

输出可能如下：

sec   rsa4096/XXXXXXXXXXXXXXXX 2023-10-01 [SC]XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid                 [ultimate] Your Name <your_email@example.com>
ssb   rsa4096/YYYYYYYYYYYYYYYY 2023-10-01 [E]

配置 Git 使用 GPG 密钥：
设置全局 GPG 密钥 ID。

git config --global user.signingkey XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

启用 GPG 签名：
配置 Git 在每次提交时自动签名。
```
git config --global commit.gpgsign true
```
创建带签名的提交：
使用 git commit -S 命令创建带签名的提交。
```
git commit -S -m "Your commit message"
```
验证签名：
使用 git log --show-signature 命令查看提交日志并验证签名。
```
git log --show-signature
```

实战示例

假设你希望为你的 Git 提交生成和配置 GPG 签名。

生成 GPG 密钥：
```
gpg --full-generate-key
```
按照提示操作，生成 GPG 密钥。
列出 GPG 密钥：
```
gpg --list-secret-keys --keyid-format LONG
```
记下你的 GPG 密钥 ID。

配置 Git 使用 GPG 密钥：

git config --global user.signingkey XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

启用 GPG 签名：

git config --global commit.gpgsign true

创建带签名的提交：

git commit -S -m "Add new feature with GPG signature"

验证签名：
```
git log --show-signature
```

第二部分 高级技巧与最佳实践

10. 交互式重置

重新组织提交历史

实战示例

交互式地添加部分内容至暂存区

实战示例

11. 变基操作

什么是变基？何时使用它？

何时使用变基？

基本用法

解决变基过程中的冲突

实战示例

12. 子模块

包含外部项目作为子模块

实战示例

更新和管理子模块

实战示例

13. Git Hooks

自动执行脚本

客户端钩子

服务器端钩子

钩子的应用场景介绍

实战示例

14. 安全性和身份验证

使用 SSH 密钥进行身份验证

实战示例

设置 GPG 签名以保证提交真实性

实战示例

相关文章：

第二部分高级技巧与最佳实践