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 就是为了解决这些问题而生的。

它可以记录：

• 哪些文件改了？

• 改了什么内容？

• 谁改的？

• 什么时候改的？

• 为什么这样改？

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 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

它会显示每一次提交的：

• 提交编号

• 作者

• 时间

• 提交信息

如果想看简洁版：

git log --oneline

输出类似如下：

a1b2c3d add hello file

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

练习一下

#在当前路径下新建一个名为 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 diff：查看修改内容

你可以把 git diff 想象成“老师批改作文时的红笔”。

它会告诉你文件具体改了哪些内容。

先修改文件：

echo "第二行内容" >> note.txt

查看改动：

git diff

如果你已经 git add 了，普通 git diff 可能看不到内容，因为修改已经进入暂存区。

这时使用：

git diff --staged

含义：

git diff --staged
# 这里的意思是：查看已经放入暂存区、但还没有 commit 的修改

3.2 git restore：撤销工作区修改

如果你改了文件，但还没有 git add，可以这样撤销：

git restore note.txt

含义：

git restore note.txt
# 这里的意思是：放弃 note.txt 在工作区里的修改
# 文件会回到最近一次 commit 的状态

如果文件已经进入暂存区，想把它从暂存区拿出来：

git restore --staged note.txt

含义：

git restore --staged note.txt
# 这里的意思是：取消暂存
# 文件内容不会消失，只是不再准备进入下一次 commit

3.3 git reset：回退版本

git reset 用来把当前分支移动到某个历史提交。

你可以把它想象成游戏读档，但它有三种模式：

3.4 reset --soft

git reset --soft HEAD~1
# 这里的意思是：回退到上一个 commit
# 但是保留这次 commit 里的修改
# 并且这些修改还在暂存区里

适合场景：

刚提交完发现提交信息写错了，或者想把上一次提交重新整理一下。

3.5 reset --mixed

git reset --mixed HEAD~1
# 这里的意思是：回退到上一个 commit
# 保留文件内容
# 但把暂存区清空，需要重新 git add

--mixed 是默认模式，所以这两条命令效果一样：

git reset HEAD~1
git reset --mixed HEAD~1

适合场景：

我想撤销 commit，但代码内容还要留着，重新决定哪些文件要提交。

3.6 reset --hard

git reset --hard HEAD~1
# 这里的意思是：回退到上一个 commit
# 暂存区和工作区的修改都会被丢弃
# 这条命令有风险，执行前一定确认没有重要代码

适合场景：

我非常确定当前修改全部不要了，要彻底回到旧版本。

新手要特别小心：--hard 像“格式化当前存档”，不是普通撤销。

动手实验：体验 diff 和 reset

cd learning-git

# 修改文件
echo "这是第二次修改" >> note.txt

# 查看修改内容
git diff

# 加入暂存区
git add note.txt

# 查看暂存区里的修改
git diff --staged

# 提交
git commit -m "update note"

# 查看历史
git log --oneline

# 回退上一次 commit，但保留修改到暂存区
git reset --soft HEAD~1
# 这里的意思是：撤销最近一次提交，但修改还在暂存区

# 查看状态
git status

# 再次提交
git commit -m "update note again"

模块四：分支的核心奥义

4.1 什么是分支？

你可以把 Git 分支想象成游戏里的“平行世界”。

主线世界叫：

main

你想开发一个新功能，可以开一个新分支：

feature-login

这样你在新分支里随便尝试，不会影响主线。

4.2 git branch：查看和创建分支

查看当前所有分支：

git branch

创建新分支：

git branch feature-login

删除分支：

git branch -d feature-login

4.3 git switch：切换分支

切换到已有分支：

git switch feature-login

创建并切换到新分支：

git switch -c feature-login

含义：

git switch -c feature-login
# 这里的意思是：创建一个叫 feature-login 的新分支
# 然后立刻切换到这个分支上

4.4 为什么 Git 分支成本极低？

很多人以为创建分支就是复制一整份代码。

但 Git 不是这样。

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

你可以把它想象成书签：

• 一本书是提交历史

• 分支是夹在某一页上的书签

• 创建分支不是复印整本书，只是多放了一个书签

所以 Git 创建分支非常快，成本也很低。

4.5 场景：紧急修复线上 Bug

假设你正在开发新功能：

git switch -c feature-payment

突然老板说：

线上登录页面炸了，马上修！

这时你不应该在当前功能分支里直接修线上 Bug，而是：

# 先提交或暂存当前工作，保证工作区干净
git status

# 切回主分支
git switch main

# 从 main 创建一个紧急修复分支
git switch -c hotfix-login

# 修改 bug 文件
echo "fix login bug" >> login.txt

# 提交修复
git add login.txt
git commit -m "fix login bug"

# 切回 main
git switch main

# 把修复合并回 main
git merge hotfix-login

# 删除已经完成的 hotfix 分支
git branch -d hotfix-login

# 回到原来的功能开发分支
git switch feature-payment

这个流程的好处是：

• 新功能不会污染线上修复

• Bug 修复可以快速上线

• 修复历史清晰可追踪

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

cd learning-git

# 查看当前分支
git branch

# 创建并切换到新分支
git switch -c feature-note-title

# 修改文件
echo "标题：Git 学习笔记" >> note.txt

# 提交修改
git add note.txt
git commit -m "add note title"

# 切回 main
git switch main

# 查看 note.txt 内容
cat note.txt

# 再切回功能分支
git switch feature-note-title

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

模块五：合并与冲突解决

这一模块是 Git 新手最容易紧张的地方。

先记住一句话：

冲突不是事故，而是 Git 在提醒你：“同一个地方有两种改法，请你决定保留哪一种。”

5.1 merge：合并分支

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

git switch main
git merge feature-note-title

你可以把 merge 想象成“合并红绿灯”：

• 如果两条路没有抢同一个车道，直接通行

• 如果两辆车都要占同一个位置，就需要人工指挥

• 这个人工指挥，就是解决冲突

5.2 rebase：变基重演

rebase 的作用是：把你的提交“搬到另一个基础之上重新播放”。

你可以把它想象成拍短视频：

• 你原本在旧背景前录了三段视频

• 现在主线更新了背景

• rebase 会把你这三段动作，在新背景上重新演一遍

示例：

git switch feature-login
git rebase main

含义：

git rebase main
# 这里的意思是：把当前 feature-login 分支上的提交
# 放到 main 最新提交后面重新应用一遍

5.3 merge 和 rebase 的区别

简单记忆：

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

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

5.4 模拟一次冲突

我们来制造一个冲突。

第一步：准备文件

cd learning-git

# 确保在 main 分支
git switch main

# 创建一个文件
echo "今天吃米饭" > dinner.txt

git add dinner.txt
git commit -m "add dinner plan"

第二步：创建分支并修改同一行

# 创建并切换到 feature 分支
git switch -c feature-dinner

# 修改 dinner.txt
echo "今天吃面条" > dinner.txt

git add dinner.txt
git commit -m "change dinner to noodles"

第三步：回到 main，也修改同一行

git switch main

# 在 main 分支修改同一个文件的同一行
echo "今天吃火锅" > dinner.txt

git add dinner.txt
git commit -m "change dinner to hotpot"

第四步：合并，触发冲突

git merge feature-dinner

这时 Git 可能会提示冲突。

打开 dinner.txt，你会看到类似内容：

<<<<<<< HEAD
今天吃火锅
=======
今天吃面条
>>>>>>> feature-dinner

含义是：

• <<<<<<< HEAD 到 =======：当前分支的内容

• ======= 到 >>>>>>> feature-dinner：被合并分支的内容

5.5 手动解决冲突

你需要手动编辑文件，比如决定改成：

今天吃火锅和面条

保存文件后，继续执行：

# 查看冲突状态
git status

# 告诉 Git：冲突已经解决
git add dinner.txt

# 完成合并提交
git commit -m "resolve dinner conflict"

如果你合并到一半后后悔了，可以取消合并：

git merge --abort
# 这里的意思是：放弃这次 merge
# 尽量回到 merge 开始之前的状态

动手实验：亲手解决一次冲突

请你完整执行下面流程：

cd learning-git

git switch main

echo "颜色是红色" > color.txt
git add color.txt
git commit -m "add color file"

git switch -c feature-blue
echo "颜色是蓝色" > color.txt
git add color.txt
git commit -m "change color to blue"

git switch main
echo "颜色是绿色" > color.txt
git add color.txt
git commit -m "change color to green"

git merge feature-blue

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

颜色是蓝绿色

最后执行：

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

恭喜你，解决过一次冲突后，Git 就没那么吓人了。

模块六：远程协作（GitHub/GitLab）

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

远程仓库，比如 GitHub、GitLab，可以把代码放到网上，让团队一起协作。

你可以把它想象成：

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

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

• push：上传

• pull：下载别人最新修改

• PR：请同事帮你审稿

6.1 git clone：克隆远程仓库

如果远程已经有项目，你可以复制到本地：

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

或者使用 HTTPS：

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

克隆后会自动带上远程地址。

6.2 git remote：管理远程地址

查看远程仓库：

git remote -v

添加远程仓库：

git remote add origin git@github.com:username/project.git

含义：

git remote add origin git@github.com:username/project.git
# 这里的意思是：给当前本地仓库添加一个远程地址
# origin 是这个远程地址的默认名字

6.3 git push：推送到远程

第一次推送当前分支：

git push -u origin main

含义：

git push -u origin main
# 这里的意思是：把本地 main 分支推送到 origin 远程仓库
# -u 表示建立本地 main 和远程 main 的默认关联
# 以后在这个分支上可以直接使用 git push

之后可以简写：

git push

6.4 git pull：拉取远程更新

git pull

它通常相当于：

git fetch
git merge

你可以把 pull 想象成：

先把远程的新内容拿回来，再尝试合并到你当前分支。

如果别人改了同一处代码，就可能产生冲突。

6.5 配置 SSH 密钥

SSH 密钥可以让 GitHub/GitLab 识别你这台电脑。

你可以把它想象成“家门钥匙”：

• 私钥：只能放在你电脑上，不能给别人

• 公钥：可以放到 GitHub/GitLab，用来验证身份

生成 SSH 密钥：

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

一路回车即可。

查看公钥：

cat ~/.ssh/id_ed25519.pub

复制输出内容，然后：

1. 打开 GitHub 或 GitLab

2. 进入 Settings

3. 找到 SSH Keys

4. 新增 SSH Key

5. 粘贴公钥并保存

测试连接：

ssh -T git@github.com

如果看到类似欢迎信息，说明配置成功。

6.6 标准团队协作 PR 流程

一个常见团队流程是：

flowchart TD
    A[从 main 拉最新代码] --> B[创建功能分支]
    B --> C[本地开发并 commit]
    C --> D[push 到远程分支]
    D --> E[发起 Pull Request]
    E --> F[同事 Code Review]
    F --> G[修改问题]
    G --> H[合并到 main]

对应命令：

# 1. 切到 main
git switch main

# 2. 拉取最新代码
git pull

# 3. 创建功能分支
git switch -c feature-user-profile

# 4. 开发完成后提交
git add .
git commit -m "add user profile page"

# 5. 推送到远程
git push -u origin feature-user-profile

然后去 GitHub/GitLab 页面创建 PR。

PR 的目的不是“找茬”，而是：

• 让别人理解你的改动

• 提前发现问题

• 保证主分支稳定

• 留下团队讨论记录

动手实验：模拟远程协作

如果你已经有 GitHub 账号，可以这样练习：

# 创建本地仓库
mkdir remote-demo
cd remote-demo
git init

# 创建文件
echo "远程协作练习" > README.md

git add README.md
git commit -m "add README"

# 添加远程地址，替换成你自己的仓库地址
git remote add origin git@github.com:yourname/remote-demo.git

# 推送到远程
git push -u origin main

如果你还没有 GitHub 账号，也没关系。先掌握本地 Git，再学习远程协作会更稳。

Git 常用命令速查表

git init
git status
git add .
git commit -m "init project"
git log --oneline

git status
git diff
git add <文件名>
git commit -m "说明这次修改"
git log --oneline

git switch main
git pull
git switch -c feature-name
git push -u origin feature-name

新建类

修改类

撤销类

分支类

同步类

口诀：记住 add、commit、push

你可以这样记：

挑菜 add，装袋 commit，送到云端 push。

对应关系：

• git add：从工作区挑选这次要提交的修改

• git commit：把挑好的修改打包成本地版本

• git push：把本地版本送到远程仓库

再换成写论文的类比：

• add：选中本次要交的段落

• commit：生成一个正式版本

• push：发给导师或团队

新手避坑指南

1. 手贱执行了 git reset --hard，代码没了怎么办？

先别慌，立刻查看 Git 的操作记录：

git reflog

reflog 会记录 HEAD 移动历史。找到你想回去的提交编号，比如：

abc1234 HEAD@{2}: commit: update note

然后恢复：

git reset --hard abc1234
# 这里的意思是：把当前仓库强制恢复到 abc1234 这个历史位置
# 如果你不确定，不要立刻执行，可以先请有经验的人帮你看

注意：如果代码从来没有 commit 过，也没有被其他工具保存，那恢复难度会很高。

所以新手要养成习惯：

小步修改，频繁 commit。

2. pull 时发生冲突怎么办？

不要关闭窗口，也不要乱删文件。

按这个流程走：

# 1. 查看哪些文件冲突
git status

# 2. 打开冲突文件，找到 <<<<<<<、=======、>>>>>>> 标记

# 3. 手动修改成你真正想保留的内容

# 4. 标记冲突已解决
git add <冲突文件>

# 5. 完成合并
git commit

如果你还没准备好处理冲突，可以尝试：

git merge --abort
# 这里的意思是：取消这次合并过程

如果是 git pull 触发的合并冲突，本质上也是 merge 冲突，处理方式类似。

3. 忘记先 pull，直接 push 被拒绝怎么办？

这通常说明远程仓库比你的本地更新。

处理方式：

git pull
# 这里的意思是：先把远程的新修改拉下来并合并

git push
# 这里的意思是：合并成功后，再把你的修改推上去

如果 pull 产生冲突，就按照上一节解决。

4. 提交信息写错了怎么办？

如果只是最近一次提交信息写错：

git commit --amend -m "新的提交信息"

含义：

git commit --amend -m "新的提交信息"
# 这里的意思是：修改最近一次 commit 的提交信息

如果这个 commit 已经推送到远程并且别人可能基于它开发了，修改前要先和团队确认。

5. 不小心把不该提交的文件 add 了怎么办？

比如你把 secret.txt 加进了暂存区：

git restore --staged secret.txt

含义：

git restore --staged secret.txt
# 这里的意思是：把 secret.txt 从暂存区拿出来
# 文件本身还在，只是不进入下一次 commit

如果这个文件以后永远不想提交，可以放进 .gitignore。

最后的学习路线建议

你现在不需要一次记住所有命令。

建议按这个顺序练：

1. 先熟练：init、status、add、commit、log

2. 再理解：工作区、暂存区、本地仓库

3. 然后练习：diff、restore、reset

4. 接着掌握：branch、switch、merge

5. 最后进入团队协作：clone、push、pull、PR

你可以把 Git 想象成一门“存档与协作的语言”。
刚开始不用追求命令背得多，先把“我现在在哪个区域、我要把修改送到哪里”想清楚，Git 就会越来越顺手。

推荐继续阅读

ProGit