Git，这东西写过几行代码的人基本都绕不开。我见过太多刚入行的同事，项目文件从“最终版”一路命名到“最终版终极版打死不改版”，直到某天删错了文件才发现已经回不去了。这篇参考就是写给Git新手的，从安装配置讲到日常操作、分支合并、远程协作和避坑实战，每个命令我都尽量讲清楚“为什么要这么写”，而不是让你死记硬背。不管你之前有没有接触过版本控制，按着这个顺序走一遍，Git的基本使用逻辑就能串起来了。
1. 为什么要用Git：版本控制到底解决了什么问题
1.1 从一个真实的项目事故说起
先讲个我身边的真实例子。有个前端同事，做项目从来不提交代码到仓库，全靠压缩包备份，目录长这样：project_0323.zip、project_0329_ok.zip、project_0402_final.zip、project_0402_final2.zip。某天上午他改完一个样式文件，下午需求又改回去，但“final2”里面已经是回不去的状态，他只能对着屏幕一点点手改。折腾了大半天，浪费的时间比写代码还多。
Git解决的就是这一类问题。它会把你每个阶段的文件状态记录下来，相当于给项目装了一台“时间相机”，随时可以回到任意一次保存过的状态，还可以对比不同版本之间到底改了什么。更重要的是，这份记录不是一个人在本地拍脑袋，它可以被多个人共享，大家在同一套代码上并行工作，最后再把各自的结果合并起来。
1.2 Git和传统版本控制的本质区别
如果你听说过SVN、CVS，可以先有个对比。这类工具属于集中式版本控制，所有版本信息都存在一台中央服务器上，你需要联网才能提交、获取历史。Git是分布式版本控制，每个开发者本地都有一份完整的仓库副本，包括全部历史记录。
用一句话概括差异：SVN是“所有人围着一块黑板记笔记”，Git是“每个人手里都有一本完整的笔记，黑板只是用来同步内容的”。这意味着你在没有网络的环境下照样能提交代码、查看历史、创建分支，全部操作都在本地完成，等有网了再把结果推送到远程仓库。
分布式带来的好处不仅是离线可用，还有安全性。中央服务器挂了或者仓库损坏，任何一个人的本地克隆都能把整个项目恢复出来。这也是现在主流开源项目几乎全部迁到Git平台的原因。
1.3 三个区域、三种状态，先记住这张地图
理解Git最关键的入口，是记住它把代码分成了三个区域：
- 工作区（Working Directory）：你平时写代码时看到的那个目录。
- 暂存区（Staging Area / Index）：存放你准备提交的改动，像是上菜前先放在台面上的备料。
- 版本库（Repository / .git目录）：保存所有已经提交的历史快照。
对应的，一个文件的改动会经历三种状态：modified（已修改但还没存进暂存区）、staged（已暂存）、committed（已提交到版本库）。日常操作的循环就是“改代码 → git add把改动放进暂存区 → git commit把暂存区的内容打包成一个历史记录”。
很多新手觉得Git难，就是因为没搞清楚这三个区的关系。比如有人执行了git add之后又改了文件，却没重新add，提交上去的只是之前add的那个版本，后面的改动还在工作区里飘着。类似的细节，后面讲到具体命令时会再展开。
2. Git安装与初始配置：一分钟装好，十分钟配好
2.1 不同系统的安装方式与安装后的验证
先说Windows。到Git官网（git-scm.com）下载Windows安装包，一路点击Next安装即可。要注意的是安装过程中会让你选择编辑器、调整PATH环境变量，新手直接用默认选项就行，唯一建议改的是终端字体和行尾转换策略，不过这些后面也都能用命令改回来，选错不致命。
macOS上最简单的方式是brew install git，前提是你装了Homebrew。没有装的话，也可以直接去官网下载安装包。Linux用户更简单，Debian/Ubuntu用sudo apt install git，CentOS/RHEL用sudo yum install git。不管哪种系统，装完统一用下面这条命令验证：
git --version能看到版本号输出，就说明装好了。我个人的习惯是，装完第一个小时先不急着建仓库，先把下面要讲的全局配置做掉，因为配置缺失是新手最常遇到的第一个报错来源。
2.2 必做的三项基础配置
安装完成后，第一件事是告诉Git“你是谁”。这里配置的用户名和邮箱会写进每一次提交记录里，是代码署名的依据。
git config --global user.name "你的名字" git config --global user.email "你的邮箱"--global表示这个配置对当前用户的所有仓库生效。如果你想针对某个项目单独使用另一个身份，可以在那个仓库目录里不加--global再执行一次，Git会优先使用更局部的配置，这个优先级规则后面会反复用到。
第三项建议设置默认编辑器。因为后面执行git commit不带-m参数时，会弹出编辑器让你写提交说明，如果没配置，Windows下可能直接打开一个你根本不熟悉的Vim，进去之后不知道怎么退出。我习惯设成VS Code：
git config --global core.editor "code --wait"实在不想折腾编辑器的，每次提交老老实实加-m参数也完全可以，不是非配不可。
2.3 中文显示、换行符这类容易被忽略的细节
国内用户经常遇到的一个问题是，文件名或提交说明里有中文时，git status显示出来的是一串\344\273\243\347\240\201之类的转义字符。这是因为Git默认把非ASCII字符做了转义显示。解决方法是关掉这个转义：
git config --global core.quotepath false配置完之后，中文文件名就能正常显示了，这个配置在Windows、macOS、Linux下通用，建议一上来就加上。
另一个细节是换行符。Windows用的是CRLF，Linux/macOS用的是LF，如果多人跨平台协作，会出现“明明没改内容，diff却显示整行都变了”的情况。常见的处理是在Windows上设置git config --global core.autocrlf true，提交时自动转成LF，检出时转成CRLF；macOS/Linux上一般保持默认或设为input。具体选哪个可以按团队规范来，但一定要让整个团队的配置口径保持一致，否则纯文本文件里的改动对比会让你非常头疼。我在实际项目里就见过因为换行符问题，一次pull下来几千行diff全是假变更，排查半天才找到原因。
3. 日常开发必会的核心命令
3.1 从零开始第一次提交
假设你刚拿到一个项目目录，还没用Git管理，第一步是初始化仓库：
git init这会在当前目录生成一个隐藏的.git文件夹，之后的所有版本信息都存放在这里面。注意平时不要手动去改.git里面的内容，也别把它当普通文件上传到什么网盘，它跟你的工作目录是两回事。
写代码之前，应该先准备一个.gitignore文件。它是Git的“忽略名单”，用来排除不需要纳入版本控制的文件，比如IDE的配置目录、node_modules依赖文件夹、编译产物、日志文件等。
node_modules/ dist/ *.log .DS_Store接下来就是核心的两步：
git add . git commit -m "first commit: 初始化项目结构"git add .会把当前目录下所有未被忽略的改动加入暂存区。提交成功后，可以用git log --oneline看到一条提交记录了。有的同学喜欢一个命令把所有事干了，比如git commit -am "xxx"，这个写法等价于“自动把所有已跟踪文件的改动加入暂存区再提交”，但对于新文件它不会处理，新手容易踩坑，所以前期老老实实分两步写。
3.2 用status、log、diff看懂仓库状态
我见过最快上手Git的方式，不是背命令，而是养成“先看状态再动手”的习惯。git status会告诉你当前仓库处于什么状态，哪些文件被改了、哪些已暂存、哪些还没跟踪。几乎每个操作之前先跑一遍它，能避免九成误操作。
git log看历史记录。推荐一个追加参数组合：
git log --oneline --graph --all--oneline把每条记录压成一行，--graph用线条画出分支走向，--all把本地和远程所有分支都显示出来。配合起来，仓库的变化轨迹一目了然，尤其是后面讲到分支合并时，这个命令几乎是必备的。
git diff用来查看改动内容。不带参数时，显示工作区与暂存区之间的差异；加上--cached参数，显示的是暂存区与上次提交之间的差异。想回看某次提交改了什么，用git show <commit的hash>。
如果改错了想撤销，几个常用命令要分清：想放弃工作区的改动用git checkout -- <文件>；想把已经add的改动从暂存区撤出来用git reset HEAD <文件>；想直接回退到上一个提交用git reset --hard HEAD~1。最后一个命令会丢弃提交和所有相关改动，务必确认无误后再用，它的危险性也是新手最容易忽视的，我见过有人一不留神把写了一整天的工作全部抹掉了，连后悔药都没得吃。
3.3 git commit --amend的正确使用姿势
git commit --amend是新手进阶时一定要掌握的“后悔药”。它的作用是把本次提交和上一次提交合并，重新生成一条提交记录，主要用在两个场景：一是提交说明写错了想改文案；二是上次提交漏了文件，或者提交内容有误，不想多出一条“fix typo”的冗余记录。
用法很简单。先看一个改提交说明的例子：
git commit -m "fix: 修复登录接口的bug" # 发现说明写错了，想改成 git commit --amend -m "fix: 修复登录接口超时的问题"执行完以后，git log里只会保留后面这一条提交，之前的错误说明就像不存在过一样。
漏文件的场景更常见。比如你提交了代码，结果发现一个关键配置文件忘了加进去，正常做法是：
git add 漏掉的文件 git commit --amend --no-edit--no-edit的意思是复用原来的提交说明，不再重新弹编辑器，非常适合“就是补个文件”这种场景。
注意，--amend本质上是把原先的提交记录替换掉了，所以绝对不要去修改已经推送到远程、并且别人也在使用的提交。一旦改完再push，会和远程历史对不上，协作时会导致别人的仓库出现一堆冲突。如果你改的是还没push的本地提交，那就完全没问题，这也是最推荐的用法。
4. 分支管理与合并：团队协作的地基
4.1 分支到底是什么，以及如何创建和切换
分支是Git里最漂亮的设计之一。你可以把它理解成一条独立的时间线，在主线上开发时开辟出一条支线，在支线上做实验、改功能，等验证没问题后再合并回主线。它让多个人协作开发同一套代码成为可能，也让“在安全的隔离环境里试错”被写进工作流。
创建一个分支并切换过去，最常用的写法是：
git branch feature-login git checkout feature-loginGit较新的版本里也提供了语义更清晰的命令：
git switch -c feature-login-c表示创建并切换，一条指令完成两件事。查看当前在哪个分支，用git branch，带*号的就是当前分支。
这里要理解一个关键点：分支本质上只是一个指向某个提交的指针。创建分支的开销极低，所以Git鼓励频繁创建分支、频繁提交，而不是攒了一大坨改动才想着怎么保存。我见过不少新手在master上直接改，改到一半需求变了又不敢回退，整个仓库一团乱麻，就是没有用好分支。
4.2 merge与fast-forward的差异
分支开发完了，要把它合并回主线：
git checkout master git merge feature-login如果主线自打创建分支之后一直没有新提交，那么合并时Git会直接把master的指针移动到feature-login的顶端，这种没有产生合并提交的合并叫fast-forward合并，历史是线性的，非常干净。
如果主线在这期间也有了自己的新提交，那么合并时Git会把两条线的改动整合起来，生成一个额外的合并提交。这种合并会在git log --graph里呈现出一个分叉再汇合的图形，团队review的时候更容易看到功能分支的完整来龙去脉，所以正式团队项目里，merge这种方式用得很多。
新手理解fast-forward只需要记住一句话：它只是指针快进，不会产生新的提交。正因如此，Git默认在合并时如果满足fast-forward条件就直接快进，不想快进、想强制生成合并提交的话，可以用git merge --no-ff feature-login。实际团队里，很多规范会要求功能分支必须--no-ff合并，就是为了在历史上留下一个清晰的功能汇合点，方便回溯和review。
4.3 冲突并不可怕，按步骤解决就好
冲突是新手最怕、但完全绕不开的东西。它本质上是说：两边的修改都动了同一个文件的同一区域，Git判断不了该听谁的，需要人工裁决。记住一个原则，冲突不是错误，是正常协作的一部分，遇到冲突说明流程在按预期运转。
模拟一个场景：你和同事都在改config.js的同一行配置，他先推送到远程，你在本地也改了同一行，于是pull的时候就冲突了。Git会把冲突标记直接写进文件里：
<<<<<<< HEAD apiUrl: "http://old.example.com" ======= apiUrl: "http://new.example.com" >>>>>>> feature/configHEAD到=======之间的内容是你当前分支的版本，=======到>>>>>>>之间是对方分支的版本。解决方式就是打开文件，人工决定保留哪一边、删除哪一边，或者两边都改一改，然后把冲突标记全部删掉。
处理完之后依次执行：
git add 冲突文件 git commit记住，解决冲突时不要在提交说明里写一堆没有意义的废话，保留Git自动生成的merge提示即可。如果发现自己解决得太乱、想重新来，直接git merge --abort，Git会放弃这次合并，回到合并之前的状态，整个过程没有任何心理负担。
5. 远程仓库与SSH密钥配置
5.1 克隆、推送、拉取的基本流程
本地仓库再强大，没有远程协作的配合，价值也发挥不出来。常见的代码托管平台，国内用得最多的是Gitee（码云），国际上最主流的是GitHub，很多团队内部还会自己部署GitLab。这些平台做的事情一样：帮你把远程仓库托管在服务器上，并提供权限管理、代码审查、Issues等功能。
从一个空仓库开始，最常用的两个操作是clone和push。clone是把远程仓库完整复制到本地：
git clone https://gitee.com/yourname/my-project.git这个命令执行完，本地会多出一个以项目名命名的目录，里面除了文件外还带着完整的Git历史和远程地址配置。要注意clone下来的仓库，远程地址变量名默认叫origin，这个地址信息用git remote -v可以查看。
如果你是在本地git init之后想把代码推送到远程新建的空仓库，需要手动把远程地址加进来：
git remote add origin https://gitee.com/yourname/my-project.git git push -u origin main-u的意思是把本地的main分支和远程的main分支建立关联，之后在本地分支上执行git push和git pull，Git就知道该跟哪个远程分支通信，不用每次带完整参数。
5.2 Gitee SSH密钥配置全过程
用HTTPS地址操作远程仓库，每次push都要输入用户名和密码（或访问令牌），麻烦不说，还容易记错。更推荐的做法是配置SSH密钥，配置之后push、pull都免密，安全性和便利性都更好。
SSH密钥的原理是一对钥匙：公钥放在代码托管平台，私钥留在本地。向远程发起连接时，平台用公钥验证你的身份，整个过程不传送密码本身，所以不用担心明文密码泄露。
生成密钥的命令通用，在本地命令行执行：
ssh-keygen -t rsa -b 4096 -C "你的邮箱"执行后一路回车即可，默认会生成到~/.ssh/id_rsa（私钥）和~/.ssh/id_rsa.pub（公钥）。然后查看公钥内容：
cat ~/.ssh/id_rsa.pub接下来打开Gitee，进入“设置 → SSH公钥”，把cat命令输出的完整内容粘贴进去，起个名称保存即可。
验证是否配置成功：
ssh -T git@gitee.com如果是Gitee官方认证，会返回类似“Hi yourname! You've successfully authenticated”的提示，看到这个就说明密钥生效了。之后把远程地址改成SSH格式：
git remote set-url origin git@gitee.com:yourname/my-project.git再以后push、pull就再也不用输密码了。这里提醒一点：id_rsa私钥文件绝对不要发给别人，也不要传到代码仓库里，谁拿到它，谁就能冒充你访问所有配置了这个公钥的代码仓库。
5.3 fetch、pull、push的常见细节
很多新手分不清git fetch和git pull。简单说，fetch只负责把远程的更新下载到本地，但不会自动合并到当前工作区，你可以先看看远程改了什么，再决定怎么处理；pull等于fetch加merge，一步到位。对新手来说，git pull更直观，但建议养成先git status再git pull的习惯，确认本地没有未提交的改动，避免拉取时被提前拦停。
push也有个常见坑：当你本地落后于远程时直接git push，会被拒绝，提示类似“failed to push some refs”。Git很安全，它不允许你用自己的旧历史覆盖远程的新提交。解决办法是先git pull把远程更新合并到本地，解决可能出现的冲突，再重新git push。
远程协作的完整工作流基本长这样：拉最新代码 → 创建功能分支 → 在分支上开发、提交 → 切回主分支并拉取最新 → 合并功能分支 → 推送 → 发起代码审查或合并请求。多人协作时，保持主干干净、功能分支独立，会省掉大量不必要的冲突处理时间。
6. 新手踩坑实录与排查技巧
6.1 几个高频报错的排查过程
把新手期最常见的几个报错整理成一张速查表，遇到时对号入座：
| 报错信息 | 原因 | 解决办法 |
|---|---|---|
| fatal: not a git repository | 当前目录没有初始化仓库 | 确认在正确的目录，或执行git init |
| Please tell me who you are | 没配user.name和user.email | 按2.2节配置全局信息 |
| failed to push some refs | 本地落后于远程 | 先git pull合并再push |
| Permission denied (publickey) | SSH密钥没配好或公钥没上台 | 检查~/.ssh下的密钥和Gitee设置，重新执行5.2验证 |
| Unable to lock file | 上次操作异常中断，锁没释放 | 删除.git/index.lock后重试，前提是确认没有正在运行的Git进程 |
第一条最常见，我见过好多人开了终端就敲git status，却忘了先cd到项目目录。第二条则出现在换新电脑后，配置和仓库已经拷贝过来，但全局身份信息没带过来。
第二条我还想多提醒一句：换电脑之后，记得先检查这几项是否齐全——SSH密钥是否拷贝、全局配置是否设置、远程地址是否正确。新手换一次电脑等于做一次环境的从头搭建，提前整理好一个清单会省很多时间。另外很多人以为把项目文件夹复制过来就算“迁移完成”了，其实.git目录和全局配置才是最重要的部分，丢了它们，历史记录和身份信息都会出问题。我在公司帮同事处理过好几次类似的问题，基本都是换新电脑后第一推就报权限错误，排查一圈才发现是密钥没带过来。
6.2 IDE里那一长串git参数是什么意思
很多新手是从VS Code或者JetBrains系列IDE里的图形界面开始接触Git的。如果你在IDE的日志或集成终端里观察过，可能见过这样的命令：
git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status这一长串看起来吓人，其实就是IDE在调用Git时捎带传了一些额外参数，目的是让输出更符合IDE的解析习惯，不影响Git的真正行为。简单拆解：
-c key=value是Git的通用写法，意思是临时覆盖某个配置项，只对这次命令生效。diff.mnemonicprefix=false：关闭diff输出里的记忆化前缀，让a/、b/这类符号恢复成普通的前缀表示，便于IDE统一解析。core.quotepath=false：就是我们前面手动配过的中文路径显示开关，IDE自动帮我们带上了。--no-optional-locks：告诉Git在运行这条只读命令时不要给仓库加可选的锁，避免和用户正在进行的其他Git操作发生阻塞。
看到这些参数不用慌，它们不是神秘魔法，都是“临时改配置+关锁”的组合。理解了这个逻辑，下次在IDE里看到任何带-c的长命令，你都能一眼看穿它到底做了什么。
6.3 坚持几个好习惯，让Git成为帮手
最后分享几个我自己长期用下来最见效的习惯。
第一，提交要小而勤。一次提交只做一件事，说明用清晰的动词加名词，比如feat: 新增用户注册接口、fix: 修复分页越界问题。这样以后查git log或者定位某个改动时，效率会高非常多。我见过有人一天只提交一次，说明只写“update”，到月底查历史时完全不知道当时改了什么，回退更是无从下手。
第二，动手之前先看status和log。不管是要提交、要合并、还是要回退，先花十秒看一眼当前仓库状态，能避免绝大多数的误操作。这就像出门前看一眼天气预报，成本极低，收益极大。
第三，set一个自己的常用命令别名。Git本身支持配置短命令：
git config --global alias.st status git config --global alias.lg "log --oneline --graph --all"配好之后，输入git st、git lg就能快速查看状态和历史，能明显减少日常操作的琐碎感。我自己在新建环境的第一件事就是把这几个别名配好，实测下来每次敲命令都省心不少。
最后说一句题外话，也是我这些年带新人最深的感受：Git不是一门需要背语法的编程语言，它是一套解决协作问题的思维方式。你不需要记住所有命令，甚至不需要记住所有选项，只要理解了工作区、暂存区、版本库这三个区域的关系，理解了提交、分支、合并各自的用途，遇到不会的命令查一下文档就能上手。把上面这些基础打扎实，剩下的就都是时间问题。
