Git新手入门实战：从安装配置到分支合并的完整指南

我做技术这十几年，带过的实习生、转行的新人，也算不少了。几乎每个人第一次接触 Git 的时候，表情都差不多：代码不是已经存在本地了嘛，为什么还要学一套这么绕的命令？后来等自己改崩过代码、覆盖过同事的修改、翻遍文件夹找不到上一版的时候，又回来问我：Git 到底怎么才能快点用熟？

这篇不是写给资深工程师的，是写给所有已经知道 Git 很重要、但每次打开终端都头皮发麻的新手。我会把安装、配置、提交、回滚、分支、远程协作、还有那些你在 IDE 里见过的奇怪命令参数，全部拆开揉碎讲清楚。目标只有一个：你照着做一遍，就能独立在项目里用它干活，心不慌。

1. 为什么新手想学好 Git：先理解它要解决的三个痛点

1.1 没有版本控制的工作流有多痛苦

你可能也经历过这种场景：项目文件夹里躺着 论文_初稿.doc、论文_修改稿.doc、论文_最终版.doc、论文_打死也不改版.doc。代码项目里也一样，刚开始觉得名字起得很清楚，过两个星期自己都分不清哪个是最新的。

更糟的是多人协作。两个人同时改了同一个文件，后保存的人直接把前面那位的改动覆盖了，等发现问题的时候，之前那版代码已经找不到了。这不是能力问题，是工具问题。人的短期记忆和文件命名习惯，根本不适合管理频繁变化的内容。这也是为什么所有正规开发团队都默认用版本控制工具，而在当前所有工具里，Git 是绝对的主流。

1.2 Git 靠什么解决这些问题

Git 的核心思路，是把项目的每一次有效改动，都记录成一个"提交"（commit）。你可以把提交想象成游戏存档：每次完成一个小功能、修改一个 bug，就存一次档，写上一句话说明自己改了什么。哪天代码改坏了，直接读档回到任何一次提交时的状态，一切都能找回来。

它管理的不是某个文件的副本，而是整个项目在某个时刻的完整快照。这就引出了它的第一个核心概念：仓库（repository）。仓库里不仅存着当前文件的内容，还存着所有历史提交记录。第二个核心概念是暂存区（staging area），它是工作区和仓库之间的一层缓冲地带，让你可以挑着文件提交。第三个核心概念是分支（branch），允许你从主线上拉出多条平行开发线，各干各的，干完再合并回主线，互不干扰。

1.3 "分布式"到底是什么意思

我面试时候经常问新人，Git 和 SVN 这类集中式版本控制系统最大的区别是什么？很多人答不上来。简单说：集中式系统的中央服务器存着所有历史，你本地只有当前这一个版本的文件，一旦断网或者服务器挂了，历史记录就暂时没法查、没法提交了。而 Git 是分布式的，每个开发者本地 clone 下来的，都是整个仓库的完整镜像，包含全部分支和全部历史。

这带来的直接好处有两个：第一，离线照样能提交代码，等有网了再推送到远程；第二，远程仓库挂了，任何一个人的本地副本都能恢复整个项目。理解了这个，后面再学 push、pull、clone，就很容易想通：它们本质上是在本地仓库和远程仓库之间同步完整的历史快照，而不是简单上传几个文件。

2. 环境准备：从下载安装到首次配置一次搞定

2.1 不同系统下的 Git 安装方式

Windows 用户最简单，直接去 Git 官网（git-scm.com）下载安装包，一路 Next 装完。里面有几个选项新手容易犹豫，我把建议直接放在这里：默认编辑器选你顺手的，我建议 VS Code 或者 Notepad++；PATH 环境变量那一步，选第二项 "Git from the command line and also from 3rd-party software"；换行符转换那一步，如果只在自己电脑上写代码，选第一个 "Checkout Windows-style, commit Unix-style line endings" 即可。

macOS 用户，如果你装了 Homebrew，一条命令就能装完并保持最新版本：

bash复制brew install git

不装 Homebrew 也可以，直接装 Xcode Command Line Tools，系统会自带 Git，不过版本往往偏旧。Linux 用户则用系统自带的包管理器，Debian/Ubuntu 执行 sudo apt install git，CentOS/RHEL 执行 sudo dnf install git。装完统一验证版本：

bash复制git --version

能看到 git version 2.x.x 之类的输出，就说明装好了。

2.2 安装后先做这三件事

Git 装完不会自动知道你是谁。它做每一次提交的时候，都需要把作者信息写进记录里，所以第一件事是配置用户名和邮箱：

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

用户名建议用真实的姓名拼音或常用昵称，别用网名花名，因为多人协作时别人要通过这个名字在历史里找你。邮箱建议用你注册代码托管平台的那个邮箱。

第二件事，配置换行符处理。Windows 用的是 CRLF 换行，macOS 和 Linux 用的是 LF。如果不做任何处理，一个文件在 Windows 上被 Git 拉下来后，可能整个文件的每一行都被认为发生了改动，diff 结果惨不忍睹。Windows 下建议执行：

bash复制git config --global core.autocrlf true

macOS/Linux 下执行：

bash复制git config --global core.autocrlf input

意思是提交到仓库时自动转成 LF，Windows 拉出来时再转成 CRLF。第三件事，配置默认分支名。现在很多平台默认用 main 而不是 master，我建议统一：

bash复制git config --global init.defaultBranch main

2.3 SSH 免密配置：一劳永逸的关键一步

每次 push、pull 都要输账号密码，用不了几次就烦了。免密最推荐的方式是 SSH 密钥。原理很简单：你本地生成一对密钥，一把私钥自己留着，一把公钥交给代码托管平台。以后 Git 连接远程服务器时，服务器通过公钥验证你的身份。

先生成密钥：

bash复制ssh-keygen -t ed25519 -C "you@example.com"

一路回车即可，默认存在 ~/.ssh/id_ed25519 和 ~/.ssh/id_ed25519.pub。如果系统比较老不支持 ed25519 算法，就用 ssh-keygen -t rsa -b 4096。然后把公钥内容复制出来：

bash复制cat ~/.ssh/id_ed25519.pub

去你使用的代码托管平台，在个人设置里找到 SSH Keys 或 SSH 公钥管理入口，把输出内容整段粘贴进去保存。最后本地验证：

bash复制ssh -T git@github.com

如果看到欢迎语，恭喜，免密已经生效。如果你用的是 HTTPS 方式克隆的仓库，SSH 密钥不生效，需要改配 credential helper。Windows 上一般 git config --global credential.helper manager-core，macOS 则用 osxkeychain，存一次密码以后系统会自动管理。

3. 入门必会的核心命令：提交、查看与回滚

3.1 第一次提交：理解 init、add、commit 的流转关系

假设你有一个新项目文件夹，里面放着几个源码文件。在终端进入这个目录，执行：

bash复制git init

这个命令会创建一个隐藏的 .git 目录，Git 的所有历史记录都放在这里。注意，这个目录千万别删，删了等于整个项目的版本历史全部丢失。执行完 init 之后，项目还处于"未跟踪"状态，需要用 add 命令把文件加进来：

bash复制git add .

点号表示把当前目录下所有文件加入暂存区。这里建议养成好习惯，别总是无脑 git add .，先看看自己到底改了什么，尤其当项目里混着临时文件、日志文件的时候，用 git add 具体文件名 更稳妥。文件进入暂存区后，执行提交：

bash复制git commit -m "初始化项目，添加登录模块"

提交说明要写清楚这次改了什么、为什么改，别写 "update" 这种毫无信息量的话。等以后翻历史日志的时候，你会感谢当初认真写说明的自己。整个过程中间任何时候，都可以用：

bash复制git status

查看当前工作区与暂存区的状态。

3.2 查看历史和对比：log 与 diff 的使用方法

提交过几次之后，想看看项目演进过程，用：

bash复制git log --oneline --graph

--oneline 让每条提交压缩成一行显示，--graph 用字符画出分支拓扑图。看到的结果会是这样：最左边一列是提交的唯一标识，一串挺长的哈希值，一般取前 7 位就能唯一定位。

想查看某个文件相比上次提交改了哪些内容，不提交的情况下直接用：

bash复制git diff

注意，diff 只看工作区与暂存区之间的差异。如果你已经 add 过了，想看暂存区与上一次提交的差异，需要加上 --staged 参数：

bash复制git diff --staged

想查看某一次提交具体改了哪些文件，用 git show 加上那一次提交的哈希值：

bash复制git show abc1234

查看某个文件在某次提交里的具体改动，可以继续加文件路径。

3.3 改错了想反悔？先分清三个不同的"撤回"

撤回操作是新手最容易搞混的，因为不同状态下要用不同的命令，用错了后果还不一样。我先给你划一条清晰的线：

如果文件只是改了，还没 add，想放弃本次修改回到上一次提交的状态：

bash复制git restore 文件名

如果文件已经 add 进暂存区了，想把它移出来但保留工作区里的修改：

bash复制git restore --staged 文件名

如果提交已经完成了，但提交信息写错了，或者漏掉了一个文件没提交，可以用：

bash复制git commit --amend

它会修改最近一条提交，不会产生新的提交记录。已经推送到远程的提交，不建议用这条命令，因为会重写历史，导致其他协作者那边出现分叉。如果想把某次已经推送的提交撤销掉，最安全的是 revert：

bash复制git revert 提交哈希

它会生成一条新的提交，把那次提交的改动反着再改一遍，历史保持完整。请记住：revert 才是远程分支上推荐的撤销方式，reset --hard 这种危险操作，只适合在本地分支上使用。

4. 分支与远程协作才是 Git 的核心玩法

4.1 分支的创建、切换与合并：新手最容易懵的一块

前面说过，分支是 Git 最强大的设计之一。默认情况下，你的提交都发生在 main 分支上。团队开发不会直接在主分支上乱改，而是每个功能拉一个分支出来，开发测试完再合并回主线。

创建并切换到新分支：

bash复制git switch -c feature/login

这条命令等价于老写法 git checkout -b feature/login，新手直接用新命令 switch 就好，语义更清晰。切回主分支：

bash复制git switch main

在分支上工作完以后，把主线更新到最新，然后合并：

bash复制git merge feature/login

merge 的意思，是把另一个分支的提交历史并入当前分支。如果两个分支各自修改了不同文件，或者不同区域，Git 会自动合并，不产生任何干扰。这也正是分支能提高并行效率的原因。

4.2 合并冲突：别怕，按这四个步骤就能解决

两个分支改了同一个文件的同一个区域，合并时 Git 就不知道该听谁的了，这时会产生冲突（conflict）。新手第一次见到冲突标志符往往很慌，其实处理流程是固定的，不用怕。

第一步，用 git status 查看哪些文件冲突了；第二步，打开这些文件，你会看到类似这样的内容：

code复制<<<<<<< HEAD
你当前分支上保留的代码
=======
另一个分支带进来的代码
>>>>>>> feature/login

<<<<<<<、=======、>>>>>>> 这些是冲突标记，不是代码的一部分，最终提交前必须清理干净。第三步，跟同事商量或者自己判断，每个块保留需要的部分，删掉标记符号。强烈建议这种操作别在纯终端里硬改，用 VS Code 或 IDEA 这类带可视化冲突解决界面的编辑器，可以直接选择"保留当前""保留传入""两者都保留"，直观得多。第四步，冲突解决完成后，把文件加入暂存区，然后提交：

bash复制git add 冲突文件
git commit -m "解决合并冲突：保留登录校验逻辑"

就这样，一次冲突解决完毕。

4.3 远程协作：clone、push、pull、fetch 怎么配合

团队协作时，项目一般托管在 GitLab、GitHub 或 Gitee 这种远程平台上。第一次拿到项目，不是 init，而是把远程仓库完整复制到本地：

bash复制git clone git@github.com:user/project.git

克隆下来的项目自带远程仓库地址信息。本地改完代码，提交之后，推送到远程：

bash复制git push

第一次推送新分支时，Git 会提示你要不要带上游参数，直接按它提示执行：

bash复制git push -u origin feature/login

把本地新分支和远程分支绑定起来。要拉取别人推送到远程的新提交：

bash复制git pull

pull 的本质是 fetch 加 merge：fetch 把远程的提交拉到本地但不动你的工作区，merge 再把它们合并到当前分支。如果你希望工作区保持整洁、想先看看远程改了什么再决定怎么合并，可以分两步：

bash复制git fetch
git diff main origin/main
git merge origin/main

日常开发中，push 之前一定先 pull，这个习惯能帮你挡住大量冲突。

5. 你可能见过的三个奇怪参数：IDE 自动附加的"高深配置"

5.1 core.quotepath=false：中文文件名乱码之谜

很多人在 IDEA 或者 VS Code 的集成终端里，偶尔会看到一条类似这样的命令前缀：

bash复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status

先别慌，这不是什么高深的黑客命令，而是 IDE 在调用 Git 时不希望你看到的内部细节。它把一些设置以 -c 配置名=值 的形式临时附加在命令前，只对这一次执行生效，不会修改你本地的全局配置。三者各有各的含义。

core.quotepath 默认是 true，它会导致 Git 在处理非 ASCII 文件名（比如中文）时，把路径转义成一串八进制数字，你在终端里就会看到 "\346\265\213\350\257\225.txt" 这种没法读的输出。加上 core.quotepath=false 以后，Git 就会直接展示中文文件名。如果你平时在 Git 输出里看到一堆转义后的八进制，根本不想 debug，就把它加进全局配置：

bash复制git config --global core.quotepath false

这是一行性价比极高的配置，强烈建议所有人设置。

5.2 diff.mnemonicprefix=false：diff 输出里的 a/ 与 b/ 前缀

执行 git diff 时，你可能会看到输出头部写着：

bash复制diff --git a/README.md b/README.md

这里的 a/ 代表修改前的文件，b/ 代表修改后的文件。mnemonicprefix 如果设为 true，Git 会用更形象的 1/ 2/ 来替代没有语义的 a/ b/。IDE 加 -c diff.mnemonicprefix=false 的原因，是让所有工具和命令的 diff 输出格式保持统一，避免某些脚本因为前缀格式不统一而解析出错。对普通用户来说，不必专门去管它，知道它的存在和含义就够了。

5.3 --no-optional-locks：避免命令悄悄锁库

Git 在执行某些只读操作时，默认会顺手刷新一下索引文件，这个刷新动作会尝试获取一个可选锁（optional lock）。正常情况下没问题，但在 IDE 频繁调用 Git 的场景下，多个进程同时尝试刷新索引，有可能会互相等锁，造成不必要的阻塞。

加了 --no-optional-locks 之后，Git 就跳过这个自动刷新动作，只做纯读取，速度更快，也不容易与后台进程冲突。这个参数的使用场景基本局限在 IDE 集成里，手动敲命令时加上它的收益不大，因为手敲命令的频率远没有 IDE 高。

6. 新手最容易踩的坑与自查手册

6.1 误提交、误删除的急救流程

我见过太多新手在提交完代码、推送到远程之后，突然发现把不该提交的文件一起推上去了。如果只是本地提交，处理起来很简单：把要移出跟踪的文件从暂存区移除，并加入 .gitignore：

bash复制git rm --cached 文件名

这个命令只移除文件的 Git 跟踪状态，不会删除本地文件。执行完后，再提交一次：

bash复制git commit -m "移除误提交的配置文件"

如果已经把敏感信息推到远程了，那就不是一条命令能解决的事，需要去远程平台删除历史记录，或者直接让仓库管理员协助处理。所以 push 之前一定用 git status 检查一下，尤其是涉及密钥、密码、.env 文件的场景。

一个更常见的翻车现场是分支删错了。Git 的分支本质上只是一个指向提交的指针，删除分支只是删了指针，历史提交并没有被立刻清掉。用下面这个命令找到最近的操作记录：

bash复制git reflog

reflog 里记录了 HEAD 指针的每一次移动，找到误删分支之前的那个提交哈希，然后重建分支：

bash复制git branch 分支名 提交哈希

分支和提交就能找回来。这条经验关键时刻真的能救命。

6.2 .gitignore 为什么一直不生效

很多人的 .gitignore 写了半天，Git 还是照样跟踪那些文件，第一反应是规则写错了。但其实最大的可能是：规则本身没写错，但这个文件在 Git 的跟踪列表里已经存在了。.gitignore 只管"尚未被跟踪的文件"，一旦某个文件已经被 add 或 commit 过，它就在版本控制里生根了，之后你再写多少 ignore 规则都管不到它。

解决办法是把它们从 Git 的跟踪列表里移除，但不删物理文件：

bash复制git rm -r --cached .

然后重新添加、重新提交：

bash复制git add .
git commit -m "重新应用 .gitignore 规则"

执行完这条之后，被忽略的文件就真正从版本控制里退出了。建立新项目之前就写好 .gitignore，能省掉后面非常多麻烦。

我整理了一个新手期高频问题的自查表，建议直接截图存一份：

6.3 终端还是 GUI？我的最终建议

很多新手会纠结要不要背命令，还是干脆用可视化工具代替。我的态度很明确：刚开始可以借助 GUI 理解概念，但最终一定要能在终端里跑通基础命令。因为 Git 的很多功能，GUI 里藏得深，终端里反而一目了然。终端下所有操作都有迹可循，报错信息也完整，出了问题方便排查。而 GUI 可能把一些错误自动帮你"处理"掉了，反而让你学不到东西。

推荐新手阶段用 VS Code 自带的源代码管理面板，它能直观展示工作区改动、暂存区内容，同时左下角也能随时打开终端敲命令。等用熟了，再换 SourceTree 或者 GitKraken 这种更完整的 GUI 工具也不迟。服务器上排查问题、处理线上代码时，终端操作是躲不掉的，早点习惯终端的反馈方式对你没坏处。

说了这么多，核心命令总结下来其实就十几个，我这里用最精简的速查表再帮你收拢一次：

最后再分享一个我用得最实在的技巧：每次开始一天的工作前，先敲一遍 git pull；每次准备提交之前，敲一遍 git status 和 git diff 看下自己到底改了什么；每次遇到莫名其妙的 git 问题，别瞎猜，先输入 git status 看 Git 自己怎么说。把这三个习惯保持三个月，你会发现自己对 Git 的掌控力完全上一个台阶。等到哪一天你能顺畅地在终端里完成从拉代码、建分支、提交到推送合并的完整循环，回头再看这篇文章，你会发现，Git 也不过如此。