月椰椰

图片来源米游社

Git 基础

什么是 Git？

Git 是一个分布式版本控制系统，用来记录文件的修改历史，尤其适合管理代码项目。

简单说，Git 可以帮你回答三个问题：

• 这个文件以前是什么样？

• 这次到底改了哪里？

• 如果改坏了，能不能回到之前的版本？

区别于普通的“复制文件夹备份”。Git 会把一次次有意义的修改保存成提交记录，每条记录都包含修改内容、提交者、提交时间和说明。以后你可以查看历史、对比差异、回退版本，也可以和别人基于同一份历史协作。

Git 的历史

Git 诞生于 2005 年，作者是 Linux 内核的创建者 Linus Torvalds。

当时 Linux 内核是一个非常庞大的开源项目，全世界有大量开发者一起参与。这样的项目需要一个工具来管理代码变化：谁改了什么、什么时候改的、不同人的修改怎么合并、出了问题怎么追溯。

在 Git 出现之前，Linux 内核项目曾经使用过 BitKeeper 这类版本控制工具。后来因为授权和使用上的原因，Linux 社区不能继续依赖原来的工具。于是 Linus Torvalds 决定自己写一个新的版本控制系统，这就是 Git。

Git 一开始就有几个明确目标：

• 速度快：大型项目也能快速提交、切换分支、查看历史。

• 数据可靠：每个版本都有校验机制，文件历史不容易被悄悄篡改。

• 支持分布式协作：每个人电脑上都有完整仓库，不必一直依赖中央服务器。

• 分支轻量：创建、切换、合并分支都很方便，适合多人并行开发。

后来，Git 逐渐成为软件开发领域最主流的版本控制工具。GitHub、GitLab、Gitee 等平台，本质上都是围绕 Git 仓库提供远程托管、团队协作、代码审查和项目管理能力。

模块一：动机与安装

1.1 什么是版本控制？

版本控制，就是帮你管理“文件变化历史”的工具。

如果没有 Git，你可能会这样管理文件：

• 论文.docx

• 论文-修改版.docx

• 论文-最终版.docx

• 论文-最终最终版.docx

• 论文-老师看过版.docx

• 论文-真的最终版.docx

这种方式有几个问题：

• 文件越来越多，不知道哪个是真的最终版。

• 改坏了之后，很难精准回到某一次修改。

• 多个人一起改同一个文件时，很容易互相覆盖。

• 不知道某一行是谁改的、什么时候改的、为什么改。

Git 就是为了解决这些问题而生的。

它可以记录：

• 哪些文件改了？

• 改了什么内容？

• 谁改的？

• 什么时候改的？

• 为什么这样改？

假设你写毕业论文或课程项目时，每改一次就复制一个新文件。短期看很直观，但时间一长就会出现几个问题：

文件名越来越像绕口令，很难判断哪个版本能交。

只知道“文件变了”，不知道具体哪几行变了。

想撤回某次修改，只能靠记忆或手工对比。

多人协作时，经常出现“你覆盖了我的版本”的情况。

Git 的价值就在于：它不只是保存文件，而是保存每一次有意义的变化。

1.2 Git 有什么用？

Git 最核心的作用是：记录变化、保护成果、支持协作。

常见用途包括：

1. 保存版本历史
   每次完成一个阶段，就可以提交一次。以后想知道项目如何一步步变成现在这样，可以直接查看提交历史。

2. 对比修改内容
   Git 能精确显示某个文件哪些行被添加、删除或修改，比手工对比多个文件版本可靠得多。

3. 撤销错误修改
   如果代码写坏了，或者某次改动方向不对，可以回到之前的版本，减少试错成本。

4. 多人并行开发
   不同成员可以在不同分支上开发功能，最后再把修改合并到主分支，避免互相覆盖。

5. 支撑远程协作
   配合 GitHub、GitLab 等平台，团队可以通过 push、pull、Pull Request 等方式同步代码、讨论修改、审查质量。

6. 记录责任和原因
   每次提交都会记录作者、时间和提交信息。以后遇到问题时，可以追踪某段代码是谁改的，以及当时为什么这样改。

所以，Git 不只是程序员的“备份工具”，更像是一套项目历史管理和团队协作系统。学会 Git 之后，你就能更安心地修改代码、更清楚地管理项目，也更容易参与真实团队开发。

1.3 在 Windows 上安装 Git

第一步：下载安装包

打开 Git 官网：

点击 Install for Windows，大多数普通 Windows 电脑选 x64 Setup 即可。

第二步：安装 Git

安装时大多数选项保持默认即可。

第三步：检查安装结果

打开 PowerShell，输入：

git --version

如果看到类似输出：

git version 2.x.x

说明 Git 已经可以使用了。

git --version

1.4 初次运行 Git 前的配置

Git 安装好之后，建议先做一次基础配置。
这些配置通常每台电脑只需要设置一次，Git 升级后也会保留。

Git 提供了 git config 命令，用来设置用户名、邮箱、默认编辑器等信息。配置文件大致分为三个层级：

Git 读取配置时遵循“就近优先”的原则：

.git/config > ~/.gitconfig > /etc/gitconfig

也就是说，当前仓库里的配置会覆盖用户配置，用户配置又会覆盖系统配置。
在 Windows 中，用户配置文件通常位于：

C:\Users\你的用户名\.gitconfig

设置用户信息

第一次使用 Git，最重要的是设置用户名和邮箱。
因为每一次提交都会记录提交者信息，这些信息会写进提交历史里。

git config --global user.name "chirabx"
git config --global user.email chirabx@qq.com

这里的 --global 表示配置对当前用户生效。设置一次之后，这台电脑上的大多数仓库都会使用这份信息。

git config user.name "Project Name"
git config user.email project@example.com

设置默认文本编辑器

有些 Git 命令会打开文本编辑器，让你填写提交信息或处理合并说明。
如果不配置，Git 可能会默认使用 Vim。新手如果不熟悉 Vim，第一次打开时可能会不知道怎么退出。

例如，你可以把默认编辑器设置为 VS Code：

git config --global core.editor "code --wait"

如果你使用的是其他编辑器，也可以按自己的习惯配置。

检查配置

查看当前 Git 能读取到的所有配置：

git config --list

查看某一项配置：

git config user.name
git config user.email

如果看到重复配置，不用太紧张。Git 可能同时读取到了系统配置、用户配置和仓库配置，最终会使用优先级最高的那一项。

模块二：基础操作

学习 Git 基础操作，我建议先理解它的三个区域，再学习命令。
因为接下来讲的这些命令，本质上都是在不同区域之间移动或查看文件状态。

2.1 Git 的三个核心区域

Git 管理文件时，主要会涉及三个区域：

工作目录是从 Git 仓库中取出的某个版本的文件。
这些文件被放在磁盘上，供你正常打开、阅读、修改。

暂存区域可以理解为一份“下次提交清单”。
它记录了哪些文件的哪些快照会进入下一次提交。暂存区域通常位于 Git 仓库目录中，也常被叫作“索引”。

Git 仓库目录通常就是项目里的 .git 文件夹。
它保存项目的元数据和对象数据库，是 Git 最核心的部分。你从别的电脑克隆一个仓库时，真正被复制下来的核心数据就在这里。

2.2 Git 的基本工作流程

Git 的基础流程可以分成三步：

1. 在工作目录中修改文件。

2. 使用 git add 暂存文件，把文件快照放入暂存区域。

3. 使用 git commit 提交更新，把暂存区域中的快照永久保存到 Git 仓库目录。

对应关系如下：

flowchart LR
    A[工作目录<br/>已修改 Modified<br/>文件已经改过来，但没add] -->|git add| B[暂存区域<br/>已暂存 Staged<br/>准备进入下一次提交]
    B -->|git commit| C[Git 仓库目录<br/>已提交 Committed<br/>版本已经保存]
    C -->|git log| D[提交历史<br/>查看版本记录]

文件在 Git 中也会有不同状态：

• 已修改（ Modified ）：文件改过了，但还没有放入暂存区域。

• 已暂存（ Staged ）：文件改过了，并且已经通过 git add 放入暂存区域。

• 已提交（ Committed ）：文件快照已经通过 git commit 保存到 Git 仓库目录。

修改文件 -> 已修改
git add -> 已暂存
git commit -> 已提交

git status

暂存区

git add 命令最主要的作用是将工作目录中的更改添加到 Git 的暂存区。

这个操作允许你把紧密相关的几份更改合并成一份快照，而不是直接提交所有新的更改。也就是说你可以同时进行多个无关的更改，最后分成几次将相关更改添加到暂存区并提交。对于任何版本控制系统来说，保持提交的原子性非常重要，这有利于追踪 bug 以及用最小的代价撤销更改。

2.3 git init：初始化仓库

git init 的作用是：将当前的目录转换成一个 Git 仓库。它在当前的目录下增加了一个 .git 目录，于是就可以开始记录项目版本了。

mkdir learning-git
cd learning-git

# 初始化 Git 仓库
git init

执行后，文件夹里会出现一个隐藏目录 .git ：

这个 .git 文件夹就是 Git 的“大脑”，里面保存着版本历史、分支信息等内容。

2.4 git status：查看当前状态

git status 的作用是：告诉你当前文件处于什么状态。你可以看到哪些更改被缓存了，哪些还没有，以及哪些还未被 Git 追踪。

git status

它会告诉你：

• 哪些文件还没被 Git 管理

• 哪些文件已经修改

• 哪些文件已经放入暂存区

• 当前在哪个分支上

新手练习 Git 时，可以多运行 git status。
它会帮你判断下一步应该 git add、git commit，还是先处理其他问题。

2.5 git add：加入暂存区

新建一个文件：

echo "Hello Git" > hello.txt

查看状态：

git status

Untracked files表示 Git 发现了新文件，但这个文件还没有被 Git 正式管理。

把文件加入暂存区：

git add hello.txt

也可以一次性添加当前目录下所有修改：

git add .

注意：git add 不是最终保存，它只是说：

“这部分修改，我准备放进下一次存档。”

2.6 git commit：正式提交版本

提交到本地仓库：

git commit -m "add hello file"

-m 后面的内容叫提交信息，用来说明这次改了什么。

好的提交信息应该像这样：

git commit -m "add login page"
git commit -m "fix navbar layout"
git commit -m "update user profile validation"

不建议这样写：

git commit -m "update" # 更新了啥？你猜
git commit -m "111" # 密码还是暗号？
git commit -m "change something" # 改了点什么不可描述的东西

2.7 git log：查看提交历史

git log

它会显示每一次提交的：

• 提交编号

• 作者

• 时间

• 提交信息

如果输出超过一屏，你可以用 空格键 来滚动，按 q 退出

如果想看简洁版：

git log --oneline

输出类似如下：

a1b2c3d add hello file

前面的 a1b2c3d 是提交编号的缩写。

更多详细内容请看：git log

练习一下

#在当前路径下新建一个名为 learning-git 的文件夹

#进入该文件夹

# 把普通文件夹变成 Git 仓库

# 创建一个文件

# 查看当前状态

# 把 hello.txt 放入暂存区

# 正式提交一个版本

# 查看提交历史

#在当前路径下新建一个名为 learning-git 的文件夹
mkdir learning-git

#进入该文件夹 
cd learning-git

#把普通文件夹变成 Git 仓库 
git init

#创建一个文件 
echo "hello" > hello.txt

#查看当前状态 
git status

#把 hello.txt 放入暂存区 
git add hello.txt

#正式提交一个版本 
git commit -m "add hello.txt"

#查看提交历史 
git log --oneline

模块三：回滚错误的修改

这一模块专门处理一个真实开发里绕不开的问题：

我改错了，现在怎么把它救回来？

错误发生的位置不同，应该用的命令也不同。先看一张总表：

3.1 先准备一个可练习的仓库

下面的内容默认你已经完成过第一次提交。

确认当前仓库是干净的：

git status

如果看到类似：

说明现在可以开始练习回滚了。

3.2 git checkout -- <文件>：撤销工作区修改

第一种情况最简单：

我改了文件，但还没有 git add，现在想把这个修改丢掉。

先故意改一下 hello.txt：

查看状态：

git status

你会看到 hello.txt 被修改了，但还没有进入暂存区：

这时可以查看具体改了什么：

git diff

如果确认这次修改不要了，执行：

git checkout -- hello.txt

这条命令的意思是：

把 hello.txt 恢复到最近一次提交时的版本。

再查看状态：

git status

如果工作区重新干净，说明撤销成功。

3.3 git reset <文件>：取消暂存

第二种情况：

我已经执行了 git add，但突然发现这个文件暂时不想提交。

在原来的基础上进行如下操作：

echo "这一行先不要提交" >> hello.txt
git add hello.txt

查看状态：

git status

这时 hello.txt 已经进入暂存区，准备被下一次 commit 保存。

如果你现在想取消暂存，使用：

git reset hello.txt

这条命令的意思是：

把 hello.txt 从暂存区拿出来，但文件内容还留在工作区。

再查看状态：

git status

你会发现：文件没有丢，只是从“已暂存”变回了“已修改”。

如果你想取消所有已经暂存的文件，可以直接写：

git reset

3.4 git reset --hard：丢弃工作区和暂存区修改

上一节的 git reset hello.txt 只是取消暂存，不会删除文件内容。

如果你想连工作区里的修改也一起丢掉，可以使用：

git reset --hard

它的意思是：

让暂存区和工作区都回到最近一次提交的状态。

先回到最初版：

git checkout hello.txt

在原来的基础上进行如下操作：

echo "XXXXXXXX" >> hello.txt
git add hello.txt
git status

如果确认这些修改全部不要：

git reset --hard

显示：

这样，工作区和暂存区都成功改回去了，再查看状态：

git status

• git reset：重置状态。

• --hard：强制让暂存区和工作区都回到最近一次提交。

3.5 git revert HEAD：撤销已经提交的修改

第三种情况：

我已经 commit 了，后来发现这次提交是错的。

这时有一个办法：git revert。

git revert 不会删除原来的提交。它会新增一个提交，用来抵消之前那个错误提交。
可以把它理解成记账：账本上写错了一笔，不撕账本，而是在后面补一笔冲正记录。

先制造一次错误提交：

git add hello.txt
git commit -m "add wrong content"

查看历史：

git log --oneline

如果要撤销最近一次提交，执行：

git revert HEAD

这里的 HEAD 表示当前最新提交。

执行后，Git 可能会打开一个编辑器，让你确认这次撤销提交的说明。如果不想改，直接保存退出即可。

如果你暂时不想进入编辑器，也可以写：

git revert --no-edit HEAD

--no-edit 表示直接使用 Git 默认生成的撤销提交说明。

再查看历史：

git log --oneline

你会看到多出了一条新的提交，通常提交信息里会带有 Revert。

git revert <提交编号>

• git revert：撤销某一次提交造成的修改。

• <提交编号>：要撤销哪一次提交。

如果要撤销最近一次提交，可以写：

git revert HEAD

如果要撤销某个指定提交，可以先查历史：

git log --oneline

然后复制提交编号：

git revert a1b2c3d

3.6 git reset HEAD~1：撤销最近一次提交，但保留文件内容

git reset 也可以撤销提交，但它和 git revert 不一样。

先学最温和的一种：

git reset HEAD~1

它的意思是：

撤销最近一次提交，但把这次提交里的文件修改留在工作区。

我刚刚提交了，但发现这次提交不够好，想拆开重新 add、重新 commit。

git reset HEAD~1

• HEAD：当前最新提交。

• HEAD~1：当前提交的上一个提交。

• git reset HEAD~1：让当前分支回到上一个提交。

注意下述区别：

核心区别：revert 的 HEAD 是“要撤销的内容”，reset 的 HEAD~1 是“要退回的目标位置”。

练习：

echo "这次提交想重新整理" >> hello.txt
git add hello.txt
git commit -m "messy commit"
git log --oneline

撤销这次提交，但保留文件内容：

git reset HEAD~1

查看状态：

git status

你会看到：提交被撤销了，但修改还在。

接下来，我们从干净状态继续，可以把这次留下的工作区修改丢掉：

git checkout -- hello.txt

3.7 git reset --soft HEAD~1：撤销提交，但保留暂存状态

--soft 比默认的 git reset HEAD~1 更温和一点。

git reset --soft HEAD~1

它的意思是：

撤销最近一次提交，但修改仍然留在暂存区。

适合场景：

我刚提交完，发现提交信息写得太随意，想马上重新提交一次。

练习：

echo "修改提交信息练习" >> hello.txt
git add hello.txt
git commit -m "update" #这个update太随意了，要改

撤销提交，但保留暂存：

git reset --soft HEAD~1

重新提交：

git commit -m "add note update"

语法拆开看：

git reset --soft HEAD~1

• --soft：只移动提交位置，不动暂存区和工作区。

• HEAD~1：回到上一个提交。

3.8 git clean -n 和 git clean -f：删除未追踪文件

第四种情况：

我新建了一些临时文件，它们还没有被 git add，现在想清理掉。

先在当前目录创建一个临时文件temp.txt，并且写入“临时文件”几个字：

继续查看状态：

git status

temp.txt 出现在 Untracked files 下面，说明它是未追踪文件。

删除前先预览：

git clean -n

-n 的意思是演习一次，只告诉你会删什么，不真的删除。

确认可以删除后，再执行：

git clean -f

-f 表示 force，也就是确认删除。

语法拆开看：

git clean -n
git clean -f

• git clean：清理未追踪文件。

• -n：预览，不删除。

• -f：真的删除。

如果要连未追踪目录一起删除：

git clean -df

3.9 小结：先按状态选命令

现在不用把所有回滚命令混在一起背。先按状态判断：

操作习惯：

git status
git log --oneline

先看状态，再选命令。

模块四：分支

4.1 什么是分支？

你可以把 Git 分支想象成一条独立的开发路线。

前面你已经学过一次基础流程：

修改文件 -> git add -> git commit

如果所有修改都直接写在主线上，项目很快会变乱。比如：

• 你正在写一个新功能，但还没写完。

• 你想试一个大胆想法，但不确定能不能成功。

• 你希望保留主线代码的稳定状态。

这时就可以创建一个分支。

主分支通常叫：

main

新功能分支可以叫：

example1

这样你就可以在 example1 上修改、提交，而 main 暂时不受影响。

4.2 git branch：查看分支

先进入前面练习用的仓库：

cd learning-git

查看当前所有分支：

git branch

输出如下：

这里的 * 表示：

你现在正在这个分支上。

如果看到：

* master

说明你当前分支叫 master。

4.3 git branch <分支名>：创建分支

创建一个新分支：

git branch example1

这条命令的意思是：

创建一个叫 example1 的新分支。

注意，它只是创建分支，不会自动切换过去。

再查看分支：

git branch

这说明：

• example1 已经创建成功。

• * main 表示你现在仍然在 main 分支。

语法拆开看：

git branch <分支名>

• git branch：管理分支。

• <分支名>：你想创建的新分支名称。

4.4 git switch <分支名>：切换分支

切换到刚才创建的分支：

git switch example1

再次查看：

git branch

你可能会看到：

这说明你已经站在 example1 分支上了。

语法拆开看：

git switch <分支名>

• git switch：切换分支。

• <分支名>：要切换到哪个分支。

还有一种办法也可以实现切换分支：

git checkout example1

git checkout 和 git switch 在这里效果是一样的。不过 git checkout 是个“多功能”命令，除了切分支还能做别的事，所以现在更推荐用 git switch，语义更清晰。

4.5 在新分支上提交一次修改

现在你已经在 example1 分支上。

修改文件：

echo "this is an example" >> example1.txt

查看状态：

git status

提交修改：

git add example1.txt
git commit -m "add an example"

查看历史：

git log --oneline

这次提交会记录在当前分支，也就是 example1 上。

4.6 切回主分支看看区别

切回主分支：

git switch main

你可能会发现：刚才在 example1 上添加的文件 example1.txt 消失了！

不是文件丢了，而是因为你回到了 main 分支。
main 还停留在创建分支之前的状态，这个状态是没有存example1.txt的。

再切回example1分支：

你发现文件又回来了，这就是分支最直观的效果，也就是：

不同分支可以保存不同的文件状态。

4.7 git switch -c <分支名>：创建并切换分支

实际开发中，创建分支后通常马上切过去。

所以可以把两步合成一步：

git switch -c new-branch1

它等价于：

git branch new-branch1
git switch new-branch1

语法拆开看：

git switch -c <分支名>

• git switch：切换分支。

• -c：create，表示创建新分支。

• <分支名>：新分支的名字。

如果使用git checkout，常见写法是：

git checkout -b new-branch1

它和 git switch -c new-branch1 类似。
但是，建议优先使用 git switch -c。

4.8 为什么 Git 分支很轻量？

很多人第一次听到“创建分支”，会以为 Git 复制了一整份项目文件。

但 Git 不是这样。

Git 分支本质上更像一个指针，它指向某一次提交。

可以这样理解：

• 提交历史像一本书。

• 每一次 commit 是书里的一页。

• 分支像书签，夹在某一页上。

• 创建分支只是多放了一个书签。

所以 Git 创建分支通常非常快。

gitGraph
    commit id: "A"
    commit id: "B"
    commit id: "C"
    branch new-branch1
    checkout new-branch1
    commit id: "D"
    checkout main

4.9 git branch -d <分支名>：删除分支

如果一个分支已经不需要了，可以删除它。

先切回主分支：

git switch main

为了安全演示，先创建一个临时分支：

git branch delete-branch1

然后删除它：

git branch -d delete-branch1

语法拆开看：

git branch -d <分支名>

• git branch：管理分支。

• -d：delete，删除分支。

• <分支名>：要删除的分支。

-d 是相对安全的删除。
如果这个分支里有还没有合并的提交，Git 通常会阻止你删除。

如果你非常确定这个分支不要了，可以强制删除：

git branch -D <分支名>

-D 是强制删除。

4.10 git branch -m：重命名分支

如果当前分支名字不合适，可以重命名。

把当前分支改名：

git branch -m new-branch-name

把某个指定分支改名：

git branch -m old-branch-name new-branch-name

语法拆开看：

• -m：move，也可以理解为 rename。

• 第一个名字是旧分支名。

• 第二个名字是新分支名。

4.11 小结

动手实验：创建并切换分支

请按顺序执行下面命令，观察每一步的 git branch 和 note.txt 内容变化。

cd learning-git

# 1. 查看当前分支
git branch

# 2. 创建分支，但不切换
git branch feature-branch-demo

# 3. 再次查看分支，观察星号在哪里
git branch

# 4. 切换到新分支
git switch feature-branch-demo

# 5. 修改文件并提交
echo "标题：Git 学习笔记" >> note.txt
git add note.txt
git commit -m "add note title"

# 6. 切回 main
git switch main

# 7. 查看文件内容
cat note.txt

# 8. 再切回功能分支
git switch feature-branch-demo

# 9. 再查看文件内容
cat note.txt

你会发现：不同分支上的文件内容可能不一样。

模块五：合并与冲突解决

上一模块我们已经会创建分支、切换分支，并在分支上提交修改。

现在问题来了，分支是要服务于主分支的：

当我们在分支上的开发做好了，怎么放回主分支？

这就是本模块要讲的内容：merge、冲突解决，以及先了解一下 rebase。

5.1 合并前先确认当前分支

git merge 有一个非常重要的规则：

它会把别的分支，合并到你当前所在的分支。

所以合并前先看自己在哪个分支：

git branch

如果你想把功能分支合并回 main，就应该先切到 main：

git switch main

5.2 git merge <分支名>：合并分支

merge 的作用是：把另一个分支的修改合并到当前分支。

语法是：

git merge <分支名>

注意：这里的 <分支名> 是“要被合并进来”的分支。

例如：

git switch main
git merge merge-demo

含义是：

把 merge-demo 分支上的修改，合并到当前的 main 分支。

先做一个简单尝试。

创建并切换到一个功能分支：

cd learning-git
git switch main
git switch -c merge-demo

在功能分支上创建一个文件并提交：

echo "this is merge demo" > merge-demo.txt
git add merge-demo.txt
git commit -m "add merge demo file"

切回主分支：

git switch main

执行合并：

git merge merge-demo

你通常能看到以下内容：

查看历史：

git log --oneline

如果没有冲突，Git 会直接把功能分支上的提交接到主分支上。

5.3 快速向前合并是什么？

刚才这个合并通常会出现类似 Fast-forward 的提示。

这叫快速向前合并。

不用被名字吓到，它的意思很简单：

main 分支在你开发功能期间没有新的提交，所以 Git 只需要把 main 的指针往前移动一下。

可以这样理解：

合并前：

main
  |
  A --- B
        \
         C  feature-merge-demo

合并后：

main
  |
  A --- B --- C

合并完成后，如果功能分支不再需要，可以删除：

git branch -d merge-demo

5.4 什么是冲突？

有时候 Git 不能自动合并。

最常见的情况是：

两个分支修改了同一个文件的同一行。

这时 Git 不敢替你决定保留哪一版，于是会停下来，让你手动处理。

5.5 制造一次冲突

下面我们故意制造一次冲突。先回到主分支：

git switch main

创建一个文件并提交：

echo "eat rice today" > dinner.txt
git add dinner.txt
git commit -m "add dinner plan"

创建并切换到新分支：

git switch -c feature-dinner

在功能分支上修改同一行：

echo "eat noodles today" > dinner.txt
git add dinner.txt
git commit -m "change dinner to noodles"

切回主分支：

git switch main

在主分支上也修改同一行：

echo "have hot pot today" > dinner.txt
git add dinner.txt
git commit -m "change dinner to hotpot"

现在合并功能分支：

git merge feature-dinner

这时 Git 会发现：两个分支都改了 dinner.txt 的同一行。它不知道该选火锅还是面条，于是会提示冲突。

5.6 看懂冲突标记

打开 dinner.txt，你会看到：

这几个标记的意思是：

• <<<<<<< HEAD 到 =======：当前分支的内容，也就是 main 里的内容。

• ======= 到 >>>>>>> feature-dinner：被合并分支的内容，也就是 feature-dinner 里的内容。

• 这些标记只是 Git 放进去的提示，最后不能留在文件里。

现在你要手动决定最终内容。

例如，你决定改成：

Today we have hot pot and noodles

保存文件。

5.7 标记冲突已解决

修改并保存文件后，还需要告诉 Git：这个冲突已经处理好了。

先查看状态：

git status

显示如下：

把解决后的文件加入暂存区：

git add dinner.txt

完成合并提交：

git commit -m "resolve dinner conflict"

再查看状态：

git status

如果工作区干净，说明冲突解决完成。

5.8 git merge --abort：取消这次合并

如果你合并到一半发现不想继续了，可以取消本次合并：

git merge --abort

适合场景：

我还没想好怎么解决冲突，先撤回这次合并，等准备好了再来。

5.9 rebase

rebase 也能把一个分支上的修改放到另一个分支后面。

语法是：

git rebase <目标分支>

例如：

git switch example2
git rebase main

含义是：

把当前 example2 分支上的提交，重新放到 main 最新提交后面。

可以把它想象成：

• merge：把两条路接起来，保留路口。

• rebase：把你的路重新铺到最新主路后面。

日常学习和团队协作，优先掌握 merge。

已经推送给别人的分支，不要随便 rebase。

更多详细内容你可以看：代码合并：Merge、Rebase 的选择

5.10 merge 和 rebase 的简单区别

动手实验：合并并解决一次冲突

请你完整执行下面流程：

cd learning-git

# 1. 回到主分支
git switch main

# 2. 准备一个文件
echo "the color is red" > color.txt
git add color.txt
git commit -m "add color file"

# 3. 创建功能分支，并修改同一行
git switch -c feature-blue
echo "the color is blue" > color.txt
git add color.txt
git commit -m "change color to blue"

# 4. 回到主分支，也修改同一行
git switch main
echo "the color is green" > color.txt
git add color.txt
git commit -m "change color to green"

# 5. 合并功能分支，制造冲突
git merge feature-blue

然后手动打开 color.txt，把内容改成：

the color is blue-green

最后执行：

git add color.txt
git commit -m "resolve color conflict"

最后查看状态：

git status

如果显示工作区干净，说明你已经完成了一次完整的冲突解决。

5.11 小结

模块六：远程协作（GitHub）

本地 Git 只管理你自己电脑上的版本。

远程仓库，比如 GitHub，可以把代码托管上去。

类似于：

• 本地仓库：你电脑里的论文草稿

• 远程仓库：云端共享文档

• push：推送到云端

• pull：拉取到本地

6.1 SSH 密钥

GitHub 需要知道：这台电脑是不是你本人在操作。

SSH 密钥就是用来证明身份的。它分成两部分：

• 私钥：留在自己电脑上，不能发给别人。

• 公钥：放到 GitHub，用来让 GitHub 识别你的电脑。

先检查电脑上是否已经有 SSH 公钥，打开powerShell，运行：

ls ~/.ssh

如果你看到类似下面的文件：

id_ed25519
id_ed25519.pub

说明你可能已经有 SSH 密钥了。

如果没有，就生成一个：

ssh-keygen -t ed25519 -C "your_email@example.com"

这里的邮箱建议填写你 GitHub 账号使用的邮箱。

执行后一路回车即可。Git 会把密钥保存到默认位置。

6.2 把公钥添加到 GitHub

运行完上述命令后，会在~/.ssh目录下生成id_ed25519和id_ed25519.pub两个文件，其中id_ed25519.pub是公钥，id_ed25519是私钥，我们需要将公钥上传到GitHub上。

查看公钥内容：

在C:\Users\你的用户名\.ssh下打开id_ed25519.pub文件，

全选并复制。它通常以 ssh-ed25519 开头，最后带着你的邮箱。

然后打开 GitHub：

1. 点击右上角头像。

2. 进入 Settings。

   

3. 找到 SSH and GPG keys。

4. 点击 New SSH key。

5. Title 写一个容易识别的名字，比如 My Windows Laptop。

6. Key 粘贴刚才复制的公钥。

   

7. 点击 Add SSH key。

6.3 测试 SSH 是否配置成功

回到终端，执行：

ssh -T git@github.com

第一次连接时，可能会问你是否继续连接，输入：

yes

如果看到类似下面的提示：

说明 SSH 配置成功。

这句话的意思是：

GitHub 已经认出你了，但它不会给你一个远程服务器命令行。

6.4 在 GitHub 上创建一个空仓库

接下来我们尝试创建远程仓库。

在 GitHub 页面操作：

1. 点击右上角 +。

2. 选择 New repository。

3. 填写仓库名，比如 git-demo。

4. 选择 Public 或 Private。

5. 先不勾选 Add a README file。

6. 点击 Create repository。

这里建议先创建一个空仓库。
因为我们要练习的是：把本地已有项目推上去。

6.5 在本地创建一个项目

我们可以看到：

可以看到，GitHub为我们提供了两种创建的方法，我们先尝试第一种：

回到终端，创建一个新的本地项目：

mkdir git-demo
cd git-demo

创建一个 README 文件：

echo "# git-demo" > README.md

初始化 Git 仓库：

git init

提交第一个版本：

git add README.md
git commit -m "first commit"
到这里，你已经有了一个本地GitHub仓库。

6.6 将远程仓库与本地连接起来

我们刚刚已经配置了SSH密钥，回到 GitHub 刚创建的仓库页面。

复制远程仓库的 SSH 地址，注意选择 SSH，不是 HTTPS。：

现在把本地仓库和 GitHub 仓库连接起来。

命令格式：

git remote add origin <远程仓库地址>

以我的仓库为例：

git remote add origin git@github.com:chirabx/git-demo.git

含义拆开看：

• git remote：管理远程仓库地址。

• add：添加一个远程地址。

• origin：给这个远程地址起的名字，默认常用这个名字。

• git@github.com:...：GitHub 仓库的 SSH 地址。

添加后检查：

git remote -v

能看到：

6.7 第一次推送

现在本地已经有提交，远程地址也配置好了，可以第一次推送：

git push -u origin main

含义拆开看：

• git push：把本地提交上传到远程仓库。

• origin：远程仓库的名字。

• main：要推送的本地分支。

• -u：建立本地 main 和远程 main 的默认关联。

第一次推送成功后，以后在这个分支上可以简写，若不是，则不可简写：

git push

6.8 回到 GitHub 页面检查结果

推送成功后，刷新 GitHub 仓库页面。

如果看到 README.md 出现在页面里，说明本地项目已经成功上传到 GitHub。

6.9 以后怎么继续更新 GitHub？

以后每次修改代码，流程仍然是熟悉的三步加一步：

git status
git add .
git commit -m "说明这次修改"
git push

也就是：

查看状态 -> 暂存修改 -> 提交版本 -> 推送到 GitHub

6.10 如果 GitHub 上已经有项目怎么办？

如果远程仓库已经有项目，你不是从本地上传，而是想把 GitHub 上的项目复制到电脑里，就用 git clone：

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

这段代码会执行：

• 下载远程仓库里的文件。

• 下载完整 Git 历史。

• 自动配置远程地址 origin。

6.11第二种情况

当本地项目已完整，已有多次提交，而远程仓库刚创建时，直接运行下述内容，即可完成推送：

最后的学习建议

Git 常用命令速查表

多上手，多写项目，菜就多练（bushi）。

推荐视频

一小时Git教程bilibili

推荐继续阅读

高质量的Git中文教程GitHub