Learning Hub

在这个教程中我假定你已经安装好了 Git。如果你没有安装，我推荐 Windows 用户在 WSL 中安装（以避免经典的CRLF 和 LF 换行符问题），使用你们在上一个 Shell 教程中学到的 sudo apt install git。如果是 Mac 用户，可以先安装 Homebrew 然后使用 brew install git。

现在，它的目的主要是来解决你们课上在运行 git commit -m 时它报的错误，你在当时可能看到它是这样说的

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

对于一些学习能力强的人来说他们看到报错可能已经去问过AI来解决问题了，不过我在这里还是想再讲一下：它到底干了什么，然后顺便再提一些 git 中别的配置。

Git 的配置是非常重要的，尤其是用户信息的配置。通过 git config 命令，你可以设置许多选项，包括用户的姓名和电子邮件地址。这些信息将会被 Git 用来标识每个提交的作者。

例如，运行我课上讲的 git log 命令，你可能会看到如下类似的东西

commit 9fceb02c0ee4b1a5c0e4b1a5c0ee4b1a5c0ee4b1a5
Author: Your Name <you@example.com>
Date:   Mon Sep 28 12:00:00 2021 +0800

    Your commit message

这里的 Author 字段就是从你通过 git config 设置的信息中获取的。如果你没有正确配置这些信息，Git 将无法识别你的身份，这可能会导致提交记录中缺少作者信息，影响团队协作和代码追踪。怎么配置？很简单，Git 在上面都教你了

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

--global 选项表示这些配置将应用于你系统上的所有 Git 仓库。如果你想为某个特定的仓库设置不同的用户信息，可以在该仓库目录下运行相同的命令，但不加 --global 选项。记得一定不要粘贴上面的命令中的 Your Name 和 you@example.com，而是要替换成你自己的信息。

除了用户信息，git config 还允许你设置其他许多选项。例如，你可以配置 Git 的颜色输出，使其在终端中更易读

git config --global color.ui auto

此外，Git 还支持配置别名，还记得我之前教的 Bash 别名吗？Git 也有类似的功能。刘祎禹学长在他的博客 ↗中提到了一些有用的 Git 别名，例如

• unstage：相当于 git reset HEAD --，用于取消暂存区的更改

  git config --global alias.unstage 'reset HEAD --'

  bash

• full-pull：相当于 git pull --recurse-submodules，用于拉取包含子模块的仓库

  git config --global alias.full-pull 'pull --recurse-submodules'

  bash

… 诸如此类的别名可以极大地提高你的工作效率，建议根据自己的习惯进行配置。

最后，所有这些配置都会被存储在一个名为 .gitconfig 的文件中，位于你的用户主目录下。你可以直接编辑这个文件来查看或修改你的配置。

你可以使用以下命令来查看当前的 Git 配置

git config --list

这将显示所有当前的配置选项及其值。如果你只配置了用户名和邮箱地址，你应该会看到类似如下的输出

[user]
    name = Your Name
    email = you@example.com

本章不设置挑战。作为阅读章节即可。如果你真能通过某些手段在本关正确拿到 flag 并提交，第一位正确的提交者将会获得一杯奶茶的奖励。

在开始使用 Git 之前，你需要先初始化一个 Git 仓库。

让我们从最基础的命令开始：git init！

什么是 Git 仓库？

Git 仓库（repository）是一个包含项目所有文件和版本历史的目录。它就像一个时光机，可以让你：

• 追踪文件的每一次修改
• 回到任何历史版本
• 与其他开发者协作
• 管理不同的开发分支

每个 Git 仓库都有一个隐藏的 .git 目录，这里存储着所有的版本信息和配置。还记得吗？你可以用 ls -la 来查看隐藏文件。

git init 命令

git init 是创建新 Git 仓库的命令。它会在当前目录下创建一个新的 Git 仓库。

基本用法

# 在当前目录初始化 Git 仓库
git init

# 创建新目录并初始化 Git 仓库
git init my-project

TIP 运行 git init 后，你会看到一条消息：“Initialized empty Git repository in /path/to/your/directory/.git/” 不要慌张，这只是告诉你当前目录是空的，并且已经成功初始化了一个 Git 仓库。

验证仓库初始化

初始化仓库后，让我们验证一下是否成功：

# 查看隐藏的 .git 目录
ls -la

# 检查 Git 状态
git status

ls -la 命令会显示所有文件，包括隐藏文件。你应该能看到一个 .git 目录。

我们后续会详细介绍 git status 命令的输出内容，但现在你只需要知道它可以告诉你当前仓库的状态。在新初始化的仓库中，你会看到类似这样的输出：

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

.git 目录是 Git 的核心，包含了：

• HEAD: 指向当前分支的指针
• config: 仓库的配置信息
• objects/: 存储所有的 Git 对象（commits, trees, blobs）
• refs/: 存储分支和标签的引用

⚠️ 警告: 永远不要手动修改 .git 目录中的文件！这可能会损坏你的仓库。

让我们创建一个简单的项目并初始化 Git 仓库：

# 创建新的项目目录
mkdir my-first-repo
cd my-first-repo

# 初始化 Git 仓库
git init

# 创建一个简单的文件
echo "# My First Git Repository" > README.md

# 查看状态
git status

运行 git status 会显示 README.md 是一个未跟踪的文件：

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)

初始化选项

git init 命令还有一些有用的选项：

# 指定初始分支名称
git init --initial-branch=main
# 或简写为
git init -b main

TIP 从 Git 2.28 开始，你可以配置默认分支名称，避免每次都指定。

你可能会问…

Q: 我可以在已有文件的目录中运行 git init 吗？ A: 当然可以！git init 不会删除任何现有文件，它只会创建 .git 目录。

Q: 如果我在错误的目录运行了 git init 怎么办？ A: 你可以简单地删除 .git 目录：rm -rf .git

RECAP

在本章中，你学习了 Git 版本控制的第一步：初始化仓库。

核心概念

• Git 仓库: 包含项目文件和版本历史的目录
• .git 目录: 存储所有 Git 数据的隐藏目录
• 分布式版本控制: 每个仓库都是完整的项目副本

关键命令

• git init : 在当前目录初始化新的 Git 仓库
• git init <目录名> : 创建新目录并初始化 Git 仓库
• git init -b <分支名> : 初始化仓库并指定初始分支名称

命令速查表

• git init : 初始化当前目录为 Git 仓库
• git init my-project : 创建并初始化新项目
• ls -la : 查看包括 .git 在内的所有文件

一些 Tips

• 初始化仓库后会创建 .git 目录
• 不要手动修改 .git 目录中的文件，会变得不幸！

任务卡

现在轮到你亲手初始化第一个仓库了。我们已经把环境收拾干净，请按顺序完成以下步骤：

1. 在 Home 目录下创建目录 dojo-init，并初始化其为 Git 仓库，让默认分支名就是我们习惯使用的 main。

如果你已经忘了 Home 目录是什么，请你看一下你学过的 Shell Dojo，或者问一问 AI。

2. 创建一个 README.md，首行写上 # dojo-init
3. 用 git status 验证一下仓库里只有一个未跟踪文件。
4. 上述都准备好后运行 /challenge/submit，验证你的仓库配置是否正确。

做到这里，你就已经完成了 Git 学习旅程中的第一小步！

将修改后的代码提交到 Git 仓库需要几步？

使用 git add 和 git commit让 Git 跟踪你的所有修改。

理解 Git 的三个区域

在学习 git add 和 git commit 之前，必须先理解 Git 管理文件的三个核心区域：

1. 工作区 (Working Directory): 用户在电脑上能直接看到和编辑的项目文件夹。
2. 暂存区 (Staging Area / Index): 一个临时的缓冲区，记录下一次准备提交的文件快照。
3. 版本库 (Repository): .git 目录，永久存储了项目所有版本历史的地方。

git add 将工作区的更改放入暂存区，而 git commit 则将暂存区的内容打包存入版本库。

git add 命令

git add 命令将工作区中某个文件或目录的当前更改放入暂存区，包含在下一次提交中，让用户能够精确控制每次提交的内容。

使用场景

1. 跟踪新文件: 在 Git 工作区中新建一个文件时，其状态为 Untracked，只有使用 git add <file> 后 Git 才会开始追踪并管理该文件。

   # 创建一个新文件
   echo "Hello, Git!" > README.md
   
   # 查看状态，会提示 README.md 是未跟踪文件(Untracked files)
   git status
   
   # 使用 git add 开始跟踪它
   git add README.md
   
   # 再次查看状态，会提示 README.md 已被暂存，准备提交(Changes to be committed)
   git status

   bash
2. 暂存已修改文件: 修改已被 Git 跟踪的文件后，使用 git add <filename> 将修改添加到暂存区。

   # 修改 README.md
   echo "Add a new line." >> README.md
   
   # 查看状态，会提示 README.md 有未暂存的修改(Changes not staged for commit)
   git status
   
   # 将修改添加到暂存区
   git add README.md
   
   # 再次查看状态，提示修改已暂存
   git status

   bash

基本用法

# 添加指定文件:
git add <file>

# 添加指定目录下的所有更改:
git add src/

# 添加当前目录所有更改:
git add .

# 交互式添加: 使用 `-p` 或 `--patch` 标志，Git 会逐一展示文件中的每一处修改（称为 "hunk"），让你决定是否要暂存它。
git add -p

git commit 命令

将暂存区中的内容打包，生成一个永久的版本记录并存入版本库，同时通过commit message为本次提交附加说明。简言之，每次提交都相当于项目历史中的一个“存档点”。

基本用法

# 使用 `-m` (message) 标志：通过命令行直接提供信息
git commit -m "feat: Add README.md"

# 打开文本编辑器编写信息：如果不带参数，Git 会自动打开配置的默认文本编辑器（如 Nano、Vim），让用户编写更详细的提交信息。
git commit

commit message

一次好的提交应只处理一个问题，而一个好的提交信息应该清晰地说明本次提交“做了什么”以及“为什么这么做”。

良好实践 (Conventional Commits 规范):

一个有所简化的标准的提交信息格式如下：

<类型>: <简短描述>

[可选的正文]

• 类型 (Type): 如 feat (新功能), fix (修复bug), docs (文档), style (格式), refactor (重构), test (测试), chore (构建或杂务)。
• 简短描述: 50个字符以内，清晰概括本次提交。
• 正文 (Body): 可选，正文必须起始于描述字段结束的一个空行后，每行不超过72个字符，并可以使用空行分隔不同段落。提交的正文内容自由编写。

例子:

git commit -m "fix: Remove null pointer dereference in user login"

更具体的规范可见： Conventional Commits 规范 ↗

RECAP

核心概念

工作区 -> 暂存区 -> 版本库: 这是 Git 提交的核心流程。

git add: 将选定的工作区中修改放进暂存区。

git commit: 将暂存区中所有修改打包并附上信息，永久地存入版本库历史中。

关键命令

• git add <file>: 将指定文件的更改添加到暂存区。
• git add <directory/>: 将指定目录下的所有更改添加到暂存区。
• git add .: 将当前目录下所有更改添加到暂存区。
• git add -p: 交互式地选择要暂存的修改部分。
• git commit -m "message": 将暂存区内容附上简短信息，并提交到版本库。
• git commit: 打开编辑器编写详细的提交信息。
• git commit <file1> <file2> ...: 提交指定文件的更改（该文件必须已被暂存）。

任务卡

进入仓库~/dojo-add-commit，仓库已初始化，文件结构如下：

include/
  book.hpp
  user.hpp
src/
  main.cpp
  book/
    book1.cpp
    book2.cpp
  user/
    user.cpp
CMakeLists.txt

请使用 git add 命令将工作目录下所有修改过的文件加入暂存区，并提交以下文件：

• include/book.hpp
• src/book/book1.cpp
• src/book/book2.cpp

只允许进行一次提交，且其它文件不能出现本次提交中。提交完成后运行 /challenge/submit 检查你的结果是否符合要求。

项目里有100个文件，忘了自己修改过哪些应该怎么办？

可以使用 git status 与 git diff 查看项目情况。

git status 命令

git status 能快速输出当前项目的状态：有哪些文件被修改了？有哪些文件已暂存？位于哪个分支？本地分支与远程分支是否同步？（分支相关内容详情见branch一节）

基本用法

# 该命令会向输出流中打印项目状态
git status

输出解读

一个典型的 git status 输出包含关于当前分支用户需要的所有信息：

# 1. 项目当前所在分支
On branch main

# 2. 本地分支与远程分支的关系
# "Your branch is up to date with 'origin/main'." -> 本地与远程同步，一切正常。
# "Your branch is ahead of 'origin/main' by X commits." -> 本地有X个新提交尚未推送到远程。
# "Your branch is behind 'origin/main' by Y commits." -> 远程有Y个新提交需要拉取到本地。
Your branch is up to date with 'origin/main'.

# 3. 已暂存的更改(位于Staging Area)
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   user.cpp

# 4. 已修改但未暂存的更改
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:   book.cpp
                book.hpp

# 5. 未被 Git 跟踪的新文件
Untracked files:
  (use "git add <file>..." to include in what will be committed)
            logger.hpp

git diff 命令

git status显示状态信息的最小单位是文件，而 git diff 可以精确地输出文件具体哪一行、哪个字符发生了变化。

基本用法

git diff 是一个多功能的比较工具，使用时需要指定比较的对象。

1. 比较“工作区”与“暂存区”: 这是 git diff 最常见的用法。它会显示所有已修改但未暂存的改动。

   # 查看所有未暂存的修改
   git diff
   
   # 只看特定文件的未暂存修改
   git diff book.hpp

   bash

2. 比较“暂存区”与“版本库”: 使用 --staged 标志，可以查看已暂存但未提交的改动。

   git diff --staged

   bash

3. 比较“工作区”与“版本库”: 比较你当前工作区的所有修改（无论是否暂存）与最近一次提交的版本有何不同。

   git diff HEAD

   bash

4. 其他: 事实上，只要一个项目状态可以被 Git 引用（无论是通过分支名、标签名、提交哈希，还是通过工作区/暂存区这些特殊位置），git diff 就能计算出它与另一个可引用状态之间的差异。同时通过选项可以将 git diff 比较的粒度调整到字符等更细的层次。

TIP: diff本身就是一个命令，可以在本地通过该命令比较两个文件的不同，实际上git diff是对diff命令的封装。

输出解读

diff --git a/book.cpp b/book.cpp
index 6b9195f..8b832a2 100644
--- a/book.cpp
+++ b/book.cpp
@@ -1,4 +1,4 @@
-  #include<bits/stdc++.h>;
+  #include<stdint.h>;
;

• --- a/book.cpp: 代表修改前的源文件 (a 文件)。
• +++ b/book.cpp: 代表修改后的目标文件 (b 文件)。
• @@ ... @@: 指明修改发生在文件的哪几行。
• - (减号): 表示这一行从源文件中被删除了。
• + (加号): 表示这一行在目标文件中是新增的。

TIPS:使用 q 键退出diff查看界面。

RECAP

核心概念

• git status: 输出项目的整体状态。
• git diff: 输出文件的具体变化。
• git diff比较不同的区域: git diff 通过调整flag可以灵活比较 Git 三大区域（工作区、暂存区、版本库）之间的差异。

关键命令

• git status: 查看项目当前状态。
• git diff: 查看未暂存的修改。
• git diff --staged: 查看已暂存、待提交的修改。
• git diff HEAD: 查看所有未提交的修改（包含已暂存和未暂存）。

任务卡

进入仓库~/dojo-status，调整仓库到如果使用 git status 命令会输出如下结果（忽略日期和提示，只需保证每个文件在对应的git分区内即可）：

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/main.cpp

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:   include/user.hpp

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        CMakeLists.txt

调整后运行 /challenge/submit 检测仓库状态。

你有没有尝试过去部署别人的项目? 开源世界有着相当多优质的项目; 而在本机上使用它们的第一步往往就是使用 git clone 命令将它们克隆到本地.

在本挑战中, 我们将学习如何使用 git clone 命令来克隆远程仓库.

Git clone 的基本语法是 git clone <repository-url>, 其中 <repository-url> 填写你想要克隆的远程仓库的 URL.

如果你想要克隆的仓库在 GitHub 上, 你可以在该仓库的主页上找到绿色的 “Code” 按钮, 点击它会显示出仓库的 URL. 你可以选择使用 HTTPS 或 SSH 的 URL.

git clone https://github.com/RayZh-hs/neofrp.git

执行上述命令后, 你会在当前目录下看到一个名为 neofrp 的文件夹, 里面包含了该仓库的所有内容.

如果你想要使用 SSH, 你需要确保你的本地机器已经配置了 SSH key 并将其添加到你的 GitHub 账户中. 如果你不知道怎么做, 可以参阅 GitHub 的官方文档 ↗. 这一块本教程不做要求.

git clone 命令提供了一些可选参数. 常用的有:

• git clone <remote-url> <new_path> 可以指定克隆到的目录名, 而不是使用默认的仓库名.
• git clone --recursive 如果仓库中包含子模块 (git 仓库中的 git 子仓库), 你可以使用这个选项来同时克隆所有子模块.
• git clone -b <branch-name> <remote-url> 如果你只想克隆某个特定分支 (branch), 可以使用这个选项. (分支在后面会提到)

在这个挑战中, 你需要克隆我们准备的一个远程仓库 (点击下面的链接访问 GitHub 页面):

Git Sample Dojo ↗

将它克隆在你的主目录 /home/hacker 下, 不要重命名, 然后运行 /challenge/submit 命令提交你的结果.

在使用 Git 进行多人合作的时候, 许多时候我们需要将自己的进度和他人共享, 或者获取他人的新进展. 这时候, 我们就需要使用 git fetch 和 git pull 等命令来实现本地仓库与远程仓库的同步.

git fetch 命令用于从远程仓库获取最新的更新. 它会将远程仓库的数据下载到你的本地, 但不会自动合并或修改你当前的工作.

# 从名为 origin 的远程仓库获取更新
$ git fetch origin

如果命令行没有任何输出, 说明你的本地仓库已经是最新的. 否则, 你可能会看到类似下面的输出:

From https://github.com/acm-dojo/sudo
    44bc5d6..3737415  main       -> origin/main

这表示远程仓库 origin 的 main 分支有了新的提交. origin/main 是一个远程跟踪分支, 它反映了远程仓库 main 分支在你上次 fetch 时的状态.

要将这些获取到的更新合并到你当前的本地分支, 你需要接着运行 git merge：

# 将 origin/main 分支合并到当前分支
git merge origin/main

在 Git 中, 远程和你的本地的操作都以分支 (branch) 形式存储. 你可以使用 git merge 来合并它们. 这在后续的教程中会详细说明.

为了简化这个两步过程, Git 提供了 git pull 命令. 它相当于 git fetch 和 git merge 的组合：

# 等同于 git fetch origin && git merge origin/main
git pull origin main

如果你当前的分支已经设置了上游分支 (upstream branch), 你可以省略远程仓库和分支名称, 直接运行 git pull.

你克隆下的仓库默认会有一个名为 origin 的远程仓库, 以及一个名为 main 的主分支. 因此, 你可以省略参数, 直接运行 git pull.

有 git pull 获取远程的更新, 当然也就有 git push 将你的本地更新推送到远程仓库. 它和 git pull 是相反的过程.

git push origin main

同理, 在有上游分支的情况下, 你也可以省略远程仓库和分支名称.

上一个挑战中, 你已经克隆了一个远程仓库 ~/git-sample-repo. 现在, 这个远程仓库有了新的更新. 你的任务是用将这些更新同步到你的本地仓库.

在更新后的仓库中, README.md 文件的内容已经被修改. 请根据它的提示, 完成本次挑战.

提示: 在做任何操作前, 请先确认你的工作目录在 ~/git-sample-repo 下.

不想让测试点与编译产物出现在 github 仓库中怎么办？

可以使用 .gitignore 文件让 Git “选择性失明”。

什么是.gitignore文件？其作用是什么？

.gitignore 文件是 Git 仓库中的一个文本文件，告诉 Git 哪些文件或目录不需要被跟踪和提交到版本库中。它的主要作用是防止不必要的文件，包括测试点、编译产物等被添加到 Git 仓库中，从而保持仓库的整洁和高效。

例 1 ： 某些大作业的测试点大小可能高达 500 MB ，如果我们将测试点解压到 Git 仓库 main 分支的 testcases/ 目录下并提交，会遭遇如下问题：

git add .
git commit -m "chore: add testcases."
git push origin main

remote: Resolving deltas: 100% (1/1), done.
......
remote: error: File testcases/your_large_file.dat is 1.00 GB; this exceeds GitHub's file size limit of 100.00 MB
......

而我们可以通过在 .gitignore 文件中添加 testcases/ 目录避免这个问题：

# 忽略 testcases 目录
testcases/

例 2 ： 与其将C++编译出的 .o 等编译产物提交到 Git 仓库中乃至提交到 github 上，不如只用 Git 管理并提交源代码文件，通过编译重新生成可执行代码。

# 忽略所有 .o 文件
*.o

注意： .gitignore 文件只会对 Git 未跟踪的文件起效。如果你已经将某个文件通过 git add 添加到 Git 仓库中（即已经被跟踪），那么即使你在 .gitignore 文件中忽略它，Git 仍然会继续跟踪该文件的更改。

例子：

# 创建两个日志文件
touch a.log b.log

# 将 a.log 添加到暂存区，使其变为“已跟踪”状态
git add a.log

# 查看当前状态，a.log 已暂存，b.log 未跟踪
git status

# 输出（部分省略）:
Changes to be committed:
       new file:   a.log

Untracked files:
       b.log

# 创建 .gitignore 文件，忽略所有 .log 文件
echo "*.log" >> .gitignore

# 再次查看状态
git status

# 输出:
Changes to be committed:
        new file:   a.log  

Untracked files:
        .gitignore 

# 解释：a.log 依然被跟踪，而b.log 因为从未被跟踪成功被.gitignore忽略。.gitignore 文件本身是新文件

bash

.gitignore文件常用语法

.gitignore 文件中的每一行都指定了一个忽略的对象。

1. 注释: 以 # 开头的行是注释，并无实际作用。

   # 这是一个注释

   plaintext

2. 忽略目录: 在模式的末尾加上斜杠 / 表示一个目录。Git 会忽略该目录下的所有文件和子目录。

   # 忽略 build/ 目录
   build/

   plaintext

3. 使用通配符:

• * 匹配零个或多个字符。

  # 忽略所有以 .log 结尾的文件
  *.log 
  
  # 忽略所有以 .o 结尾的文件
  *.o

  plaintext
• ? 匹配一个任意字符。

  # 忽略 a.cpp, b.cpp, 但不忽略 abc.cpp
  ?.cpp

  plaintext
• ** 匹配任意中间目录。

  # 忽略任何目录下名为 logs 的文件夹
  **/logs/
  
  # 忽略任何目录下以 .o 结尾的文件
  **/*.o

  plaintext

4. 否定模式 (例外规则): 在模式前加上感叹号 ! 表示不忽略，可用于为一个更广泛的忽略规则设置例外。

   # 忽略所有 .log 文件...
   *.log
   
   # ...但 important.log 文件除外
   !important.log

   plaintext

   注意：如果一个文件的父目录已经被忽略，那么你无法通过否定模式来单独保留这个文件。例如，build/ 被忽略后，!build/main.o 是无效的。

RECAP

核心概念

• .gitignore 的作用: 定义 Git 在扫描工作目录时应该忽略的文件和目录模式，防止不必要的文件进入版本控制。
• 只对未跟踪文件有效: .gitignore 无法忽略已经通过 git add 命令纳入版本控制的文件，因此最好在项目开始时设置好 .gitignore 文件。

关键操作

• 创建 .gitignore 文件: 在项目根目录创建名为 .gitignore 的文本文件。
• 添加忽略规则: 每行写一个模式，可以使用 # 添加注释，使用 * 等通配符等。

.gitignore语法速查表

• *[suffix，包括.log/.o/.exe等]: 忽略特定后缀文件。
• [case，如build]/: 忽略特定目录及内部所有内容。
• ![file]: 不要忽略某个文件。

任务卡

修改.gitignore文件，使仓库正确忽略指定的文件和目录，并确保重要文件仍然被跟踪和提交。

具体步骤如下：

1. 进入仓库~/dojo-ignore并编辑仓库中已存在的 .gitignore 文件，从而使如下文件被忽略：

   • 除 important.log 外所有以.log结尾的文件。
   • temp/ 目录下所有内容。
   • src 下的 .o 文件。
   • ignore.txt。

   同时请保证其他文件不被忽略。

2. 进行一次commit提交其他文件，请确保提交后工作区无未提交或未跟踪文件。

3. 运行 /challenge/submit 检查 .gitignore 是否生效，效果是否正确。

在讲解了 Git 的基本配置后，我们接下来要讨论的是分支管理。分支是 Git 中一个非常强大的特性，它允许你在不影响主干代码的情况下进行开发。类比的说，如果仓库是“时光机”，那么分支就是“平行宇宙的时间线”。你可以在一个分支上开发新功能，同时主分支保持稳定，等新功能开发完成并经过测试后，再将其合并回主分支。

在 Git 中，创建和管理分支非常简单。你可以使用以下命令来创建一个新分支：

git branch <branch-name>

然后，切换到新分支：

git checkout <branch-name>

有没有“只做一次”的脚本来切换分支呢？有的兄弟，有的：

git checkout -b <branch-name>

这条命令会同时创建并切换到新分支。你可以在新分支上进行开发，提交更改，就像在主分支上一样。所有之前你学到的命令，git add、git commit、git status，都可以在分支上使用。

当你完成了在分支上的开发，并且确认代码没有问题后，你可以将分支合并回主分支。合并回主分支这件事你既可以在本地完成，也可以在远程仓库中通过 Pull Request（PR）来完成。这里我们先介绍本地合并的方式：

git checkout main  # 切换回主分支
git merge <branch-name>  # 将指定分支合并到主分支

有时候，合并分支可能会遇到冲突（conflicts）。如果你同时在两个分支上修改了同一份代码（这在多人合作中事实上很常见！），那么到底是保留你的更改，还是保留另外一个人的更改？这时候需要你手动解决冲突，我们把这个话题留到 “Oh Shit, Git” 模块中详细讲解，毕竟它较为头疼。

我们再来提一嘴分支的命名规范。和 commit message 一样，为了让团队协作更加顺畅，建议大家在创建分支时遵循一定的命名规范。例如，可以使用以下格式：

feature/<feature-name>  # 新功能
bugfix/<bug-description>  # Bug 修复
hotfix/<hotfix-description>  # 紧急修复

我之前还说了 “你可以在 GitHub 上创建 Pull Request（PR）来合并分支”。通过 PR 来合并分支事实上它不止能干“合并”的事，它更重要的作用是一种协作方式，它允许你在合并代码之前，先对代码进行审查和讨论。通过 PR，团队成员可以查看你的更改，提出意见，甚至直接在你的分支上进行修改。如果你要贡献代码到一些大项目中，你一般来说只能通过 PR 来贡献代码，因为你没有他们代码库的写入权限。PR 在 Merge 意义上其实 Nothing Special。你在创建 PR 的状态栏上应该能看到类似这样的东西：

左边是你要合并的分支，右边是目标分支。这与你本地的操作是类似的。

最后，我还要介绍一下 git stash 命令。当然，你们现在不用掌握它，不过知道一下总归是好的。当你在运行 git checkout 切换分支时，如果工作区有未提交的更改，Git 会阻止你切换分支。这时你可以使用 git stash 命令将未提交的更改暂存起来，等切换到目标分支后再恢复。在你们看到这里的时候，大概率助教已经给你们讲了 栈 (Stack) 这个数据结构 （好吧可能他也只讲了讲STL的栈怎么用吧） 。事实上，git stash 就是利用栈的特性来保存和恢复工作区的状态。具体而言：

git stash push -m "some unsaved work" # 缓存这些未提交的更改
git checkout some_new_branch # 切换到新分支
...
# 当你新分支上的工作完成后
git checkout previous_branch # 切换回之前的分支
git stash pop # 看！这就是栈！push 进去的东西 pop 出来

RECAP

在本章中，你学习了如何利用分支隔离工作并安全地合并回主干。

核心概念

• 分支可以理解成平行时间线：在不打扰 main 的情况下开发新功能或修复问题。
• 分支命名规范：用 feature/、bugfix/ 等前缀，类似于 commit message 的规范。
• 临时存储工作区：git stash 用栈的方式保存未提交的改动，方便切换分支。

关键命令

• git branch <branch-name>：创建新分支
• git checkout <branch-name>：切换到指定分支
• git checkout -b <branch-name>：创建并切换分支
• git merge <branch-name>：把目标分支合并进当前分支
• git stash push -m "<note>" / git stash pop：暂存并恢复未提交更改

命令速查表

• git branch dev：新建 dev 分支
• git checkout -b dev：新建并切换到 dev 分支
• git checkout dev：进入该分支继续开发
• git checkout main && git merge dev：返回 main 并完成合并
• git stash push -m "WIP logs"：保存未完成的工作以便切换
• git stash list / git stash pop：查看并取回暂存的更改

一些 Tips

• 合并前记得回到目标分支（通常是 main）。
• 分支上的提交和主分支完全一样，放心使用 git add / git commit。

任务卡

现在轮到你来实践一次分支协作流程了！我们已经在 ~/dojo-branch 中准备好一个仓库，其中 main 分支上有一份日常进度日志，但第三天的记录还在草稿状态，且目前保持在未提交的工作区里。

请按照下面的步骤完成练习：

进入目录：cd ~/dojo-branch，创建并切换到新分支，名字叫 feature/progress-log。

打开 progress.md，新增一行 Day 3: learned branch.。使用 git add 和 git commit 提交更改，提交信息为 branch: ACM Dojo。

运行 /challenge/submit 检查结果。

人非圣贤, 孰能无过? 版本控制的很大一个用处就是: 在你 (或者你的队友) 犯错时, 帮助你的项目回到正确的状态.

在这节课程中, 你将学习使用 git reset 和 git revert 来撤销错误的提交.

Git Reset 的使用方法

让我们回忆一下 Git 的三大区域:

• 工作区 (Working Directory): 你正在编辑的文件所在的地方, 就是你的文件系统管理的目录.
• 暂存区 (Staging Area): 你准备提交的文件所在区域, 这是 Git 管理的.
• 本地仓库 (Local Repository): 你本地的 Git 仓库, 存储所有的提交历史. 其中 HEAD 指向当前分支的最新提交.

git reset 的操作, 就是基于之前的历史记录调整这些区域的信息.

git reset 有三个常用的模式: --soft, --mixed (默认), 和 --hard. 它们的共同特点是接受一个 commit 作为参数, 并将当前分支的 HEAD 指向该 commit. 比如:

git reset d1977cfba62fadd89e2f2f292256866d4da286a5
git reset HEAD (回退到 HEAD 自身, 也就是当前 commit)
git reset HEAD~1 (回退到 HEAD 的上一个提交, 也就是倒数第二个 commit)

其中, 参数的缺省值是 HEAD, 也就是默认对于 HEAD 指针不改变.

三种模式的区别在于它们对暂存区和工作区的影响.

Soft 模式

--soft 是 “温柔的” reset 模式. 它只会改变 HEAD 指针, 而对于暂存区和工作区都不做任何修改. 也就是说, 你回退到某个 commit 后, 该 commit 之后的所有更改都会被保留在暂存区和工作区中.

一个常见的用例是当你发现自己误打了 commit, 于是想回到 “执行 commit 之前一瞬间” 的状态, 你就可以使用:

git reset --soft HEAD~1

这会将 HEAD 回退一个 commit, 然后之后的所有操作都会被保留下来移动到暂存区 (因为你 commit 的是暂存区的内容). 你当前工作区的操作也不会被抹除.

Mixed 模式

--mixed 是 git reset 的默认模式. 它会改变 HEAD 指针, 并且将暂存区的内容重置为指定 commit 的状态, 但是不会修改工作区. 也就是说, 你回退到某个 commit 后, 该 commit 之后的所有更改会被保留在工作区中, 但是不再保留在暂存区.

如果你执行了

git reset HEAD~1

那么你也会回退到上一个 commit, 但是该 commit 之后的更改会被保留在工作区中, 不再存储在暂存区.

利用这个性质, 我们可以使用这个模式来 “unstage” 一些或全部文件:

git reset    # 相当于 git reset --mixed HEAD: 将暂存区所有文件都会移到工作区
git reset file1 file2  # 只将指定的文件从暂存区移到工作区

Hard 模式

--hard 是 “强硬的” reset 模式. 它会改变 HEAD 指针, 并且将暂存区和工作区都重置为指定 commit 的状态. 也就是说, 你回退到某个 commit 后, 该 commit 之后的所有更改都会被抹除, 无论是在暂存区还是工作区.

⚠️ 警告: 使用 --hard 模式会丢失所有未提交的更改, 包括工作区和暂存区的更改, 并且无法恢复. 请谨慎使用.

通常, 如果你想丢弃你从上一个 commit 以来你在工作区和暂存区的所有更改, 你可以使用:

git reset --hard HEAD

如果你想不保留痕迹地回到某个 commit, 你可以使用:

git reset --hard <commit-hash>

Git Revert: 以进为退的安全手段

在单人项目中, git reset 是一个非常有用的工具, 但是在多人协作的项目中, 它可能会引起混乱. 因为 git reset 会改变提交历史, 这会导致其他协作者的仓库与远程仓库不一致.

例如, 如果你做了 git reset --hard HEAD~1, 你将不能将这个操作 push 到 remote 仓库. 如果你强制使用 git push --force 这么做, 就会导致其他协作者的仓库出现问题.

为了避免这种情况, 我们可以使用 git revert 来撤销错误的提交. git revert 不会改变提交历史, 而是创建一个新的 commit 来撤销指定的 commit. 这样, 其他协作者的仓库不会受到影响.

git revert 同样接受一个参数 <commit>, 用来指示要撤销到的 commit, 使用方法和 git reset 类似:

git revert <commit-hash>
git revert HEAD~1

任务卡

我们在 /home/hacker 目录下创建了一个 git-reset 仓库, 请你完成以下任务:

1. 回退到倒数第二个 commit 的状态, 但请不要清空该状态之后的更改. 我们把这个 commit 记为 x;
2. 新建一个 commit, 消息任意: 提交在 x 之后对于文件 grimm.md 的更改, 并丢弃对于其他文件的更改.
3. 运行 /challenge/submit 来获取 /flag.

你们如果是因为标题吸引进来的，跳过了前面的介绍部分，建议先回去看看前面的内容。这里我要讲一些黑魔法，来减少你们 “删掉仓库重开” 的频率。

在这一章节我主要介绍：如果你在 Commit 之后发现问题（比如你不小心把密钥提交上去，又或者说你想要修改刚刚的 Commit 信息），你该怎么办？你显然不太希望别人看到你的错误，新建一个 Commit 是掩耳盗铃，毕竟 Git 是时光机。

修改最后一次提交

如果你刚刚提交了代码，但发现了一些小问题，比如拼写错误、忘记添加文件，或者想要修改提交信息，你可以使用：

git commit --amend

这个命令会打开文本编辑器让你修改提交信息，取决于你的配置，默认应该是 Vim。

如果你还想添加一些文件（或者修改一些文件）到这次提交中，你可以在运行 git commit --amend 之前先将文件添加到暂存区：

git add forgotten_file.txt
git commit --amend

这样，forgotten_file.txt 会被添加到上一次的提交中。

以下内容不需要掌握，但是了解一下总没有坏处。你事实上有可能在以后用到它们。

撤销提交但保留更改

如果你想撤销最后一次提交，但保留文件的修改：

git reset --soft HEAD~1

这样提交就被撤销了，但你的更改还在暂存区中。

完全撤销提交和更改

如果你想完全回到上一次提交的状态：

git reset --hard HEAD~1

⚠️ 警告：这会永久删除你的更改，请谨慎使用！

修改历史提交信息

如果你需要修改更早的提交信息，可以使用交互式 rebase：

git rebase -i HEAD~n

其中 n 是你想要回溯的提交数量。这会打开一个文本编辑器，列出最近的 n 次提交。你可以将 pick 改为 reword 来修改提交信息，或者 edit 来修改提交内容。

在最后我还是要提一嘴，如果你已经把错误的提交推送到远程仓库，并且其他人可能已经基于这些提交进行了工作，修改历史会导致问题。 因为你事实上不是简单的“修改了提交内容”，而是“创建了新的提交替换了旧的提交”，还记得 Git 的提交总有 “PARENT” 这回事吗？如果其他人基于错误的 PARENT 进行了工作，你修改了 PARENT 之后，他们的工作就会变得不可用。

RECAP

在本章中，你学习了如何在不丢失工作成果的情况下修补提交历史。

核心概念

• git commit --amend：重写最新一次提交的内容和信息。
• git reset 变体：--soft / --hard 分别回滚提交但保留或丢弃工作区改动。
• 历史重写的影响：每次重写都会生成新的提交 ID，需要与团队同步！改改自己的历史就算了，千万不能改别人的！

命令速查表

• git commit --amend：修正刚刚的提交信息或内容。
• git add README.md && git commit --amend：把漏掉的文件（这里是README.md）补进上一条提交。
• git reset --soft HEAD~1：撤销提交但保留暂存区。
• git reset --hard HEAD~1：彻底回滚到上一版本。

一些 Tips

• 先把修正内容 git add 再 --amend，否则不会被包含。
• git reset --hard 会删除工作区改动，务必确认无关键信息遗失。
• 修改历史会改变提交哈希，推送前确保没有人基于旧提交继续开发。这真的很重要，重要的事情说三遍！

任务卡

我们在 ~/dojo-amend 中准备好了一个只有一条提交的小仓库。那次提交的信息写得太含糊，而且 README 也不好。请按照下面的步骤修复它：

打开 README.md，把内容改成 # ACM Dojo。并且把提交信息改成 feat: I love dojo。

确保仓库依旧只有一条提交、工作区干干净净，然后运行 /challenge/submit 验证结果。

在上一章节的 “Branch” 里，我们学习了如何创建和切换分支，以及如何合并分支。不知道各位还是否记得，合并分支可能会遇到冲突（conflicts）？如果你同时在两个分支上修改了同一份代码（这在多人合作中事实上很常见！），那么到底是保留你的更改，还是保留另外一个人的更改？这时候需要你手动解决冲突。

什么是合并冲突？

Git 足够智能，可以自动合并很多情况（比如你在文件 A 的第 10 行做了修改，而另一个分支在文件 B 的第 50 行做了修改）。但当两个分支都对文件 A 的第 10 行进行修改时，Git 不知道该听谁的，它就会停下来，把决定权交给你。

当 Git 无法自动合并两个分支的更改时，就会发生合并冲突。这通常发生在：

• 同上面所说，两个分支修改了同一个文件的同一行
• 一个分支删除了文件，而另一个分支修改了该文件

识别冲突

当发生冲突时，Git 会在文件中插入冲突标记：

<<<<<<< HEAD
你当前分支的代码
=======
另一个分支的代码
>>>>>>> branch-name

事实上，冲突解决并不复杂，各位应该对它祛魅，解决过一次就会发现它其实并没有那么可怕。

各位可以在自己的终端里面随便新建一个文件夹试一试，我把命令贴在下面，逐行运行，你们现在应该已经能看懂这些命令了：

mkdir conflict-demo && cd conflict-demo

git init

echo "version=1" > app.txt

git add . && git commit -m "init"

# 在 test 分支修改同一行
git switch -c test

echo "version=2-from-test" > app.txt

git commit -am "test: update version"

# 回到 main，做不同修改
git switch main

echo "version=2-from-main" > app.txt

git commit -am "main: update version"

# 合并产生冲突
git merge test

你们应该会看到类似下面的输出：

Auto-merging app.txt
CONFLICT (content): Merge conflict in app.txt
Automatic merge failed; fix conflicts and then commit the result.

当你打开 app.txt 文件时，你会看到：

<<<<<<< HEAD
version=2-from-main
=======
version=2-from-test
>>>>>>> test

解决冲突的步骤

1. 查看冲突文件

   git status

   bash

2. 编辑冲突文件

   • 删除冲突标记（<<<<<<<, =======, >>>>>>>）
   • 保留你想要的代码
   • 或者合并两个版本的代码

3. 标记冲突已解决

   git add <文件名>

   bash

4. 完成合并

   git commit

   bash

还有一些其他「小技巧」：

「走为上计」：如果你觉得冲突太复杂，想要放弃合并，可以使用 git merge --abort 来取消合并操作，回到合并前的状态。

「言听计从」：如果你决定保留别人的更改，可以使用 git merge -X theirs ...；这里 -X theirs 表示在冲突时倾向于对方分支的改动，... 是你要合并的分支名。

「固执己见」：如果你决定保留自己的更改，可以使用 git merge -X ours ...；这里 -X ours 表示在冲突时倾向于当前分支的改动，... 是你要合并的分支名。

以上内容来源于 刘祎禹学长的博客 ↗，他取的这三个名字实在是太好了，所以我也搬过来了🤣。

RECAP

在本章中，你学习了如何识别并解决合并冲突，让两条时间线重新汇合。

核心概念

• 当 Git 无法自动决定同一位置的最终内容时，它会请求你介入。
• 冲突标记：<<<<<<<、=======、>>>>>>> 展示当前分支与目标分支的差异。
• 遇到冲突不要慌张：检查文件、删除标记、保留正确内容、重新提交。
• 必要时可以中止合并，或使用 ours/theirs 等策略快速决策。

命令速查表

• git status：在有冲突时，可以列出冲突文件清单
• git diff --merge：查看冲突双方的差异
• git merge --abort：出现混乱时快速撤退 🏳️

一些 Tips

• 打开冲突文件时先读懂标记，明确哪部分来自 HEAD、哪部分来自对方。
• 完成编辑后务必删除所有冲突标记，避免把 <<<<<<< 之类提交进历史。
• 记得提交你已经解决冲突后的文件哦！并且，提交前可以再次运行 git status，确认没有未解决的冲突或遗留文件。

以下内容不需要掌握，作为阅读材料即可。

你们在合并两个分支时，你还有可能看到 Git 如下的报错，然后说什么 --ff-only, --no-ff，--squash 之类的选项。别慌，以防你碰巧碰到了它们，我在这里也解释一下。你们可能看到这样的东西：

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge (the default strategy)
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

这个提示会在以下情况出现：

• 你本地的当前分支（比如 main）有了一些新的提交。

• 与此同时，远程仓库的同一个分支 (origin/main) 也有了别人推送的、你本地没有的新提交。

• 这时，你的本地分支和远程分支就“分叉（Diverged）”了。

Git 上面提到的 --ff-only, --no-ff，--squash 是“合并策略”。这些策略决定的是历史记录的结构，而不是代码内容的合并方式。代码内容的合并方式就是我们讲的那些东西。

• fast-forward：历史线性，但看不见合并点。
• —no-ff：保留合并节点，便于回溯特性分支。
• squash merge：把分支压成一次提交，整洁但丢失中间历史。
• rebase vs merge：
  • rebase：历史更线性；不要对已共享分支重写历史。
  • merge：保留自然历史；可能更“分叉”，但安全。

任务卡

我们已经在 ~/dojo-conflict 中准备了一份“正在撰写的小说”。main 分支和 feature/story 分支分别对第三章做了不同修改。当你尝试把特性分支合并回 main 时，一定会遇到冲突。

请进入练习仓库：cd ~/dojo-conflict，执行 git merge feature/story，观察 Git 报出的冲突信息。

打开 story.txt，消除冲突标记，把内容整理为：

Chapter 1: Arrival
Chapter 2: Tension builds
Chapter 3: Main timeline update.
Chapter 3 (feature): Alternate timeline reveal.
Chapter 4: Cliffhanger

使用 git add story.txt 标记冲突已解决，并通过 git commit 创建合并提交（默认的 Merge 信息即可）。

确认工作区干净、没有残留的冲突标记后，运行 /challenge/submit 验证结果。