Git核心操作详解：从版本管理到分支合并冲突解决

写Git操作这块，我其实犹豫了很久要不要动笔。网上教程铺天盖地，但多数要么停留在“记住这几条命令”的层面，要么一上来就扔出一堆概念把人劝退。真正困扰新手和不少刚转行同事的，往往是那些零碎的、不成体系的细节：为什么明明add了却commit不到，为什么push的时候被拒，为什么同事的代码一合并就冲突报警。这次借“git基本操作”这个题目，我把这些年实际用下来的理解、踩坑和习惯一次性梳理出来，尽量做到既讲命令，也讲命令背后的道理，看完你能直接照着用。

Git这东西，说到底就是个版本管理工具。它的核心价值不是帮你“存文件”，而是帮你“记录变化”和“回到过去”。我见过太多人用Git的方式是：每天上班第一件事git pull，下班前一顿git add .、git commit -m "update"、git push就完事。这样用不是不行，但等于把Git当成了网盘，完全丢失了版本管理最值钱的能力——可控、可回溯、可协作。下面的内容，我会从安装配置讲起，逐步拆解Git最常用、最核心的操作，中间穿插大量真实场景和排查经验，覆盖你日常开发中90%以上的需求。

1. 先搞清楚Git到底解决了什么问题

1.1 版本管理的本质：给代码“存档”

你可以把Git理解成一个极其强大的游戏存档系统。玩单机游戏的时候，你会在关键节点存档，打不过Boss就读档重来。写代码也一样，改崩了要能回退，这个需求在项目刚开始时感觉不明显，等代码量上万行、多人协作之后，没有版本管理几乎是寸步难行。

Git管理的不是文件副本，而是文件的变化历史。这意味着它存储的是每个版本之间的差异（Git内部用快照+索引的方式实现，这个细节先不管），所以仓库再大也能保持高效。给你一个直观对比：用普通方式，你可能会手动复制“项目备份_20240101”、“项目备份_20240108”这类文件夹，三个月后你根本分不清哪个对应哪个版本，而且磁盘占用巨大。用Git，你记录的是“1月1日改了什么功能”“1月8日修复了什么Bug”，每一条记录都带时间、作者、改动说明，这才是真正有价值的“存档”。

1.2 分布式和集中式的区别：为什么Git更主流

早些年主流的版本控制工具是SVN，属于集中式。所有版本都放在中央服务器上，每个人工作时从中央服务器拉取最新代码，提交也必须提交到中央服务器。缺点是显而易见的：一旦服务器挂了，所有人都没法提交；网络差的时候，提交一个版本能等半天。

Git是分布式的，每个人本地都有完整的仓库历史，绝大多数操作（提交、查看历史、分支切换）都在本地瞬间完成，只有push和pull才需要联网。平时该提交提交，该记历史记历史，完全不受网络影响。等代码稳定了，再一次性推送到远程仓库。这几年Git能全面取代SVN，分布式这个特性是决定性的。

1.3 Git的四个区：理解一切命令的钥匙

Git的操作之所以让新手觉得混乱，是因为同一个文件在不同阶段有不同状态。我习惯用一个简化模型来理解：

• 工作区：就是你电脑上看到的、正在编辑的文件目录。
• 暂存区：一个临时存放区，用来“挑选”哪些改动进入下一次提交。英文叫Index。
• 本地仓库：已经提交的记录就存在这里，也就是本地Git保存的所有历史版本。
• 远程仓库：放在服务器上的仓库，比如GitHub、GitLab、Gitee或者公司内部服务器。多人协作就是通过这个共享仓库进行的。

日常操作就是让文件在这几个区之间流转：工作区改文件，git add把改动放进暂存区，git commit把暂存区的改动固化成一条记录，git push把本地记录推到远程，git pull把别人推到远程的记录拉下来。这个流程被称为“五件事模型”，几乎所有基础操作都是这四个区之间的关系处理。想清楚当前操作的是哪个区到哪个区，命令就不会再用错。

2. 环境准备：从安装到初始化配置

2.1 各平台安装Git，别在第一步卡住

Windows用户最简单，去Git官网下载exe安装包，一路Next就行。如果你下载速度不理想，国内也有镜像站，比如阿里云、腾讯云等都有官方镜像，搜索“Git国内镜像下载”就能找到，速度会快很多。

安装过程中有几个选项需要注意：

• “Select Components”界面，默认选项就行，但建议把“Git Bash Here”和“Git GUI Here”打上勾，这会在右键菜单里增加打开Git Bash的入口，非常方便。
• “Default editor”选项，建议选“Use Visual Studio Code as Git’s default editor”，前提是你装了VS Code。如果没装，系统会默认用Vim，对不熟悉Vim的人来说，万一误入编辑器界面会卡住不知道怎么保存退出。这条建议能帮你省掉一个大坑。
• “Adjusting your PATH environment”选项，一定选中间那个“Git from the command line and also from 3rd-party software”，这样你在CMD、PowerShell或者任何终端里都能直接使用git命令，否则只在Git Bash里能用。

macOS用户建议用Homebrew安装，一条命令：brew install git。不想用Homebrew也可以直接去官网下载pkg安装包。Linux用户对应发行版的包管理器装就行，Ubuntu/Debian用sudo apt install git，CentOS/RHEL用sudo yum install git。

2.2 Git Bash是什么，以及Windows用户建议使用它

Windows用户装完Git后，桌面上会出现Git Bash，很多人不理解“Bash”是什么意思。简单说，Git Bash是Git安装包自带的一个模拟Linux命令行的终端环境。为什么需要这东西？因为Git诞生在Linux社区，很多习惯、命令格式都偏向Unix风格，而Windows自带的CMD和PowerShell在路径写法、命令语法上有差异，在Git Bash里则能统一体验到类Unix的命令。

平时我用Git Bash用得最多，因为它支持常用的ls、cd、pwd等Linux命令，使用感受比CMD顺手太多。但你在PowerShell里其实也可以敲git命令，两者并不冲突。对新手来说，建议直接用Git Bash，少踩很多莫名其妙的坑。

2.3 初始配置：用户名、邮箱和换行符

安装完Git，第一件事是配置你的身份信息，否则提交代码时会提示“Please tell me who you are”：

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这个用户名和邮箱是记录在提交历史里的，将来你的每一次提交都会标注是谁写的。–global参数表示全局生效，对这台机器上的所有仓库生效。如果是某个特定仓库用不同身份，可以在仓库目录下不加–global再执行一次，覆盖全局配置。

还有一个Windows用户必须重视的配置，那就是换行符处理。因为Windows的文本换行是CRLF，而Linux/macOS是LF，如果不处理，你在Windows上编辑的文件推到服务器后，别人在Mac上打开会发现每一行都是乱码或异常。推荐配置：

bash复制git config --global core.autocrlf true   # Windows用户

这个配置意味着签出代码时Git会把LF转成CRLF，提交时再把CRLF转回LF，保证仓库里存的始终是LF，既兼容本地编辑器，又不污染仓库文件。macOS/Linux用户则建议设置input：git config --global core.autocrlf input。

到这里，Git已经装好并可正常使用了。验证一下：打开终端输入git --version，能看到版本号就说明安装成功。

3. 核心操作：从零到一掌握日常高频命令

3.1 初始化仓库：git init 还是 git clone

有两种方式获得一个Git仓库。第一种是全新项目，在项目目录下执行：

bash复制git init

执行完成后目录里会多出一个隐藏的.git文件夹，这就是Git的“仓库”本体。所有历史记录、配置、指针都存在这里。注意，这个文件夹不要手动去改它，删了它等于毁了全部历史。如果你只想把这个目录变成普通文件夹，删除.git就能脱离Git管理，但历史也就没了。

第二种是已有远程仓库，把代码复制到本地：

bash复制git clone https://github.com/用户名/仓库名.git

git clone会自动初始化本地仓库、设置远程地址（origin）、拉取默认分支的最新代码，相当于一步到位。日常工作上，如果加入一个已有项目，基本都是git clone。

3.2 提交的三部曲：add、commit、status

这是Git出现频率最高的操作流程，也是每个新手必须形成肌肉记忆的动作。

假设你刚刚在项目里新建了一个main.py文件，现在想把它纳入Git管理：

bash复制# 1. 查看当前仓库状态
git status

# 2. 将文件加入暂存区
git add main.py

# 3. 提交到本地仓库，并写清楚这次改了什么
git commit -m "新增主入口文件"

git status是所有操作前都应该执行一遍的命令，它会告诉你当前哪些文件被修改、哪些新增、哪些已经被暂存。红色表示不在暂存区的改动，绿色表示已经在暂存区、可以提交。养成随时git status的习惯，能帮你清楚地知道自己在做什么。

git add命令有三个常用姿势：

• git add 文件名：精确添加一个文件。
• git add dir/：添加某个目录下所有改动。
• git add .：把所有改动全部加入暂存区。这个最省事但最容易误提交临时文件，不建议养成无脑add .的习惯。

git commit需要一个-m参数来写提交说明。提交说明是对这次改动的高度概括，别写“update”“修改”这种没信息量的话。推荐格式是动词开头：fix(修复Bug)、feat(新功能)、refactor(重构)、docs(文档)。例如git commit -m "fix: 修复首页登录按钮点击无响应问题"，将来回顾历史时一目了然。

3.3 查看历史与比对差异：log、diff、show

提交了几次之后，你想知道之前改过什么、谁改的、什么时候改的，用：

bash复制git log

默认会列出所有提交记录，最上面是最新提交，显示commit哈希值、作者、日期和提交说明。如果记录太多，git log --oneline会压缩成一行一条，更清晰。git log --graph可以图形化展示分支合并历史，多人协作时排查问题非常好用。

想看某个文件具体改了什么内容，而不是只看提交说明，用git diff。git diff默认比较工作区和暂存区之间的差异，git diff --cached比较暂存区和上一版本之间的差异，git diff HEAD比较工作区与当前版本之间的全部差异。差异会显示成行级别的增删标记，加号表示新增，减号表示删除。

配套的还有一个命令：git show commit的哈希值，查看某次提交的详细内容和改动。比如git show abc123，就能看到那次提交变了哪些文件、每处改了什么。排查“这个代码是谁加的、什么时候加的、为什么这么写”时，git log和git show是我必用的组合。

3.4 后悔药：restore、checkout和undo操作

写代码永远会有误操作，Git的魅力之一就是给后悔药。

先看最典型的场景：你改了个文件，发现改坏了，想放弃改动恢复成上一次提交的状态：

bash复制git restore 文件名

这条命令会把工作区的这个文件恢复到最近一次commit时的内容，未提交的改动会全部被覆盖，无法找回。所以在跑restore之前，务必想清楚你确实不需要这些改动了。

另一个场景：你git add之后想反悔，把这个文件从暂存区撤回来：

bash复制git restore --staged 文件名

老版本Git或用惯SVN的人可能见过git reset HEAD 文件名，效果一样。区别是restore语义更清晰，专门用于恢复文件，而reset除了撤销暂存还可以移动HEAD指针，涉及更多高级场景。建议新手从restore学起，不容易混。

还有个偶尔碰到的场景：你用git add .把不该提交的文件加进了暂存区，但还没有commit，上面两条命令组合就能解决——先restore --staged把它撤出来，再restore丢掉工作区改动。如果已经完全commit了，那就用git reset --soft HEAD~1回退提交并保留改动，或者git reset --hard HEAD~1直接回退且丢弃改动。reset --hard杀伤力极大，本地所有未提交的改动和那条提交记录都会消失，不要在执行前没有备份的情况下随便用。

3.5 远程仓库协同：push、pull、fetch

一个人本地玩转Git只是起步，实际工作必须和远程仓库打交道。远程仓库通常称为origin，这是git clone时默认设置的远程仓库名称。

把本地提交推送到远程：

bash复制git push origin main

origin表示远程仓库，main表示分支名。新版本Git默认分支名一般是main，老版本是master，看clone下来的实际分支名即可。

把远程更新拉下来：

bash复制git pull

git pull实际上是两个操作的合并：先从远程拉取最新数据（git fetch），再把最新的远程分支合并到当前分支（git merge）。还有一个命令是git fetch只拉取不合并，适合你想先看看远程改了什么、再决定怎么处理的时候用。git pull是“拉下来并自动整合”，git fetch是“先拉下来看看再说”，两者适用场景不同。

push被拒绝是新手最常见也最慌的报错之一，提示错误usually非fast-forward等。原因很简单：在你commit的这段时间内，别人已经向远程推送了新提交，你的本地仓库落后于远程仓库。这时候不要硬推，先git pull，把远程的新提交合并到你本地，解决冲突后再git push。原理上Git要求你的提交能“叠”在远程最新提交之上，不允许覆盖别人的提交。

4. 分支与协作：多人开发的正确姿势

4.1 分支的本质，为什么Git分支这么“轻”

分支可以说是Git里最值钱的设计。用一句话解释：分支是独立的工作空间，让你的代码修改可以并行而不互相干扰。

我用一个生活类比。你写一篇文档，主版是终稿。你想试验一种新写法，担心改坏了会影响终稿，于是复制了一个副本在副本上大改。改完了如果觉得好，就把副本里的内容合并回主版；改得不行，副本直接删除，主版毫发无损。在Git里这个“副本”就是分支。

Git内部实现分支的方式非常巧妙，分支本质上只是一个指向某个提交的指针。新建一个分支就是创建了一个新指针，成本极低，所以创建和删除分支几乎是一瞬间的事。这也是Git鼓励“多用分支、每做一个功能开一个分支”的技术底气。

4.2 分支实操：创建、切换、合并、删除

整套分支操作围绕下面几条命令展开：

bash复制# 创建并切换到一个新分支，相当于两步合并为一步
git checkout -b feature/login

# 等价的老式写法
git branch feature/login    # 创建分支
git checkout feature/login  # 切换分支

注意，新版本Git已经推荐用git switch替代checkout来切换分支：git switch -c feature/login。不过现在大多数教程和团队习惯仍以checkout为主，两种都能用，理解就行。

在这个分支上正常工作，该add就add，该commit就commit。功能完成后，切回主分支合并：

bash复制git checkout main
git merge feature/login

git merge会把feature/login分支上的改动合并到当前的main分支。合并完成后，feature/login分支通常就没用了：

bash复制git branch -d feature/login

-d表示删除已合并的分支，如果分支还没有合并，Git会拒绝删除并提示错误，此时如果确定不要了，需要改成-D强制删除。

4.3 合并冲突是怎么发生的，怎么解决

要说Git哪里对新手最不友好，绝对是合并冲突。但它其实远没有想象中那么可怕。

冲突发生的前提很简单：两个分支修改了同一个文件的同一块区域，Git不知道该听谁的。Git会在合并时自动暂停，把冲突标记写进文件，等待你手动决定保留哪边。

假设文件index.html里有一行标题，分支A改成了“登录页”，分支B改成了“注册页”，合并时Git会在文件里生成类似这样的内容：

html复制<<<<<<< HEAD
<title>登录页</title>
=======
<title>注册页</title>
>>>>>>> feature/login

=======上面是当前分支（HEAD）的内容，下面是正在合并进来的分支（feature/login）的内容。你要做的就是把冲突标记删掉，保留最终想要的内容。可以全要、可以只留一边、也可以改成第三种写法。改完保存，然后：

bash复制git add index.html
git commit -m "merge: 解决index.html标题冲突"

注意一点：解决冲突后，如果两边修改本身没有逻辑重叠，Git是能自动合并的，不会产生任何冲突提示。只有一个文件同一处被两边同时改动时才会冲突。所以平时尽量做到“提交小、频率高、各改各的”，冲突概率会低很多。

我给大家一个解决冲突时的实操建议：冲突文件不要靠猜，最好和对面分的同事沟通一下，确认彼此的意图。自动合并已经帮人类解决了90%的劳动，剩下的冲突往往是双方对功能理解不一致导致的，代码工具解决不了人的沟通问题。

4.4 团队协作的简单工作流：从个人到多人的过渡

一个人开发，分支用得不多，一个main分支就够了。但一旦进入团队，必须养成一些好习惯。最基础也是最重要的三条：

第一，永远不要直接在main/master分支上写代码。main分支应该保持稳定、可发布的状态。每做一个新功能或修一个Bug，都从main拉一条新分支，在分支上完成开发、测试、合并，再把写好的代码合并回main。这样就算分支上的代码烂成一锅粥，也不会污染主分支。

第二，提交要“原子化”，一次提交只做一个逻辑改动。别把修Bug、加功能、改格式混在一条提交里。将来排查问题时，一条提交对应一个目的，用git log时你能快速定位哪次提交导致了什么问题。

第三，push之前先pull。很多人习惯写完代码直接git push，结果被拒绝。正确的流程是：git pull（或git fetch + git merge），解决冲突，再git push。尽量让每次push操作时本地和远程的分叉不要太大，分叉越大，解决冲突的痛苦越大。

这套工作流虽然不是Git Flow那种“高级规范”，但对大多数中小型团队来说完全够用。上手之后再接触更复杂的Git Flow模型，理解成本也会变得更低。

5. 疑难杂症速查：报错、误操作与排查实录

5.1 常见的Windows报错：无法识别git命令

热词里有条信息很典型：“git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这个报错看着吓人，其实原因特别简单：你的系统不知道到哪儿去找git程序。

解决办法是重新配置环境变量，把Git的安装目录下的cmd文件夹加进系统的PATH。路径和你安装位置有关，一般是C:\Program Files\Git\cmd。操作步骤：

1. 右键“此电脑” → “属性” → “高级系统设置” → “环境变量”。
2. 在“系统变量”里找到Path，双击编辑，点击“新建”，把上面的路径加进去。
3. 一路确定，重新打开一个终端窗口，再输入git --version验证。

如果你用的是较早版本的Git安装包，还有一种更省事的修复方式：重新运行安装包，选择“Modify”，确保PATH选项是Git from the command line and also from 3rd-party software，安装器会自动帮你配好环境变量。

5.2 fatal: not a git repository (or any of the parent directories): .git

热词里的另一条典型报错：“fatal: not a git repository (or any of the parent directories): .git”。这个报错的意思是：当前目录不是Git仓库，Git在它的父目录里也没有找到仓库。

通常发生在两种场景。一是你新打开一个终端，但没有进入项目目录就执行了git命令。解决方式是确认自己确实在项目根目录内部，或者任意在项目目录内的子目录，Git会向上查找.git目录。二是这个目录从来没有git init过，也没通过git clone拉取过，自然不是仓库，那就先git init。

排查思路：执行pwd看当前所在路径，再执行ls -a看当前目录下有没有.git。都没有的话，要么cd到正确的项目路径，要么先初始化。

5.3 push失败的几个原因排查

push被拒的消息我见过太多次，总结起来主要就四类原因：

第一，远程比本地新。报错信息里会出现“non-fast-forward”或“Updates were rejected”，按上面说的，git pull后再push。

第二，权限不够。HTTP方式出现类似“Authentication failed”“403”的提示，说明你的凭证过期或没权限访问这个仓库。先检查GitLab或GitHub账号是否还有权限，再考虑重新配置凭证。

第三，SSH密钥不匹配。Repository地址是git@xxx形式的，但本机没有添加SSH公钥，或者公钥没加到账号下。报错通常是Permission denied (publickey)。解决方法是生成密钥并添加：ssh-keygen -t rsa -b 4096 -C "你的邮箱"，然后把~/.ssh/id_rsa.pub的内容粘贴到代码托管平台的SSH Keys设置里。

第四，仓库里有.git目录被误提交或.gitignore配置不对，把不应该提交的目录提交上去了，别人clone下来又push不回去。这种情况通常需要git rm -r --cached 目录名把缓存里的大文件/目录撤出来，再加进.gitignore，重新提交。

如果你用IDE或者小乌龟这类GUI工具操作Git，热词里还有一条“git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks”，这其实是IDE在背后调用Git命令时附加的参数，不是你自己需要记住的命令。当你看到这种长串命令出现在日志里时，知道是IDE在跑就行，不用慌。

5.4 git目录泄露问题，以及为什么.git不能乱传

热词里有“git目录泄露如何下载”和“ctfhub git泄露”，这是网络安全CTF比赛里常考的一类题目，但在真实开发中也是必须注意的安全隐患。.git目录里保存了整个仓库的完整历史、配置信息、甚至包含被删除过的文件内容。如果网站部署时不小心把.git目录暴露在Web根目录下，攻击者就能通过访问.git目录还原出整个项目的源代码、配置密钥等敏感信息。

所以实操上有两条铁律：第一，部署生产环境时，绝不要把.git目录复制到服务器上的Web根目录；第二，仓库里的敏感配置（数据库密码、API Token、密钥文件）绝不允许提交进Git仓库，应该用环境变量或配置文件管理，配合.gitignore排除。日常写代码时，我也习惯定期检查一下git status，确认没有意外把敏感文件提交进来。

5.5 免密设置：HTTPS凭证和SSH密钥，怎么选

“git免密”是高频需求。每次push都输入账号密码，时间久了真的很烦。Git提供两种主流方案。

方案一，HTTPS方式下保存凭证。Windows上执行：

bash复制git config --global credential.helper store

这样第一次输入账号密码后，Git会把凭证明文保存在~/.git-credentials文件里，之后不再询问。安全性稍差但方便。如果用的是Windows自带的凭据管理器，也可以配置为manager，系统会帮你安全保存。

方案二，SSH密钥方式。GitHub、GitLab、Gitee都支持。原理是你本地生成一对密钥（公钥和私钥），把公钥上传到平台，服务器和本地通过密钥配对验证身份，之后push和pull再也不用输入任何账号密码，而且是加密传输，也相对安全。生成和添加步骤如下：

bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"
# 一路回车，生成默认的 id_rsa 和 id_rsa.pub
cat ~/.ssh/id_rsa.pub

复制输出的公钥内容，到GitLab/GitHub的Settings → SSH Keys页面粘贴保存。然后把仓库远程地址换成SSH格式（git@开头），之后就能免密推送。个人强烈推荐SSH方式，一劳永逸。

5.6 遇到IDE里clone失败或连接超时怎么办

热词里有“idea clone git项目”，这里的坑也不少。在IntelliJ IDEA里操作Git时，如果选择File → New → Project from Version Control，填仓库URL后长时间卡住或超时，原因往往有两种。

一种是网络问题，尤其是远程仓库在海外的情况，clone大仓库时很容易超时。解决方式可以配置代理（前提是你在网络环境中有可用的代理服务），或者在Git配置中加大超时时间和缓冲：

bash复制git config --global http.lowSpeedLimit 0
git config --global http.lowSpeedTime 999999
git config --global http.postBuffer 524288000

另一种是认证失败。公司内部常用的GitLab，如果版本比较老或API Token过期，IDE可能会报“login failed. check api token or gitlab version”。这种提示是说IDE插件版本与GitLab版本不匹配，或者你填入的访问令牌（Personal Access Token）已失效。解决方法：重新生成Token，并在IDEA的Settings → Version Control → GitLab中更新。

5.7 看图工具和GUI：给不习惯命令行的你

热词里多次出现“git小乌龟”“git gui设置中文界面”。TortoiseGit（即小乌龟）是Windows下老牌的Git图形界面工具，在文件夹右键就能操作，用起来非常直观。下载安装时记得同时装中文语言包，安装后在Settings里把Language切换成中文即可。

不过我的观点是：GUI工具适合浏览状态、查看历史、对比文件，这些场景下图形界面确实更清晰；但涉及复杂分支操作、冲突解决、命令排查时，命令行依然是效率更高、信息更准确的工具。二者可以搭配使用，我觉得完全不冲突。

如果你主要用IDEA或VS Code，它们的Git集成其实比大多数独立GUI工具更好用。在IDEA里，分支切换、合并、提交都有可视化操作入口和颜色提示，配合右侧的Local Changes和Git Log面板，新手也能很快上手。学习阶段可以一边用IDE一边对照着看命令行输出，慢慢你就能理解每条命令在界面里对应什么操作。

6. 进阶心得：几个很少人提但你迟早遇到的细节

6.1 restore之外，还有几种“后悔药”值得记住

除了前面讲的git restore，还有几个超实用但很多教程不讲的操作。

第一个是git commit --amend。你刚执行完一次commit，发现提交信息写错了，或者漏了一个文件，想补进上一次提交而不增加一条新记录：

bash复制git add 漏掉的文件
git commit --amend -m "修改后的提交说明"

这个操作会把上次提交“覆盖”成新提交，历史里不会留下两条。注意，只有上一次提交还没push时可以用amend。如果已经push到远程，再用amend会改变提交哈希，导致push被拒，属于“改了历史”，尽量别干。

第二个是git stash，中文叫“暂存”或“贮藏”。当你正在分支A开发，临时被叫去处理分支B的紧急Bug，而此时分支A的改动还没做完、不想提交怎么办？git stash会把工作区和暂存区的改动保存到一个临时栈中，让工作区变成干净状态，之后切到分支B干完活，再切回来执行git stash pop，之前改动的文件原封不动地恢复出来，非常香。

第三个是git reflog，这是我个人认为Git里最神的命令。Git在你执行reset、rebase等操作后，不再被引用的“丢失”提交并不会被马上删除，而是会留在reflog记录里。即使你误reset --hard丢掉了一大堆提交，也不要慌张，执行git reflog，找到你想回退到的那个提交的哈希，执行git reset --hard 哈希，全部找回来。我救过同事的分支好几次，这条命令对老手来说都是救命级的。

6.2 分支名的来源和远程分支变量，别被术语吓到

你可能听说过HEAD这个名词。理解它能帮你少困惑很久。HEAD在Git里表示“当前所在位置”的指针。切换分支的本质就是移动HEAD指向另一个分支。HEAD通常指向一个分支名，分支名又指向某个具体提交。在冲突提示里看到的HEAD，就代表“当前分支”。

远程分支的概念也不难。git branch -a可以查看所有本地和远程分支，远程分支会显示成remotes/origin/main这种形式。当你git clone时，本地会自动生成一个main分支，跟踪远程的origin/main。所谓“跟踪”，意思是你在main分支上执行git pull / git push时，Git默认知道要和哪个远程分支同步，无需每次指定。这个自动关联关系正是git pull不用写远程分支名的原因。

6.3 提交规范与.gitignore：让项目更健康的小习惯

.gitignore文件的作用是告诉Git哪些文件不该纳入版本控制。典型的忽略对象包括：编译产物（target/、dist/、build/）、依赖目录（node_modules/）、IDE本地配置（.idea/、.vscode/，这个看团队规范）、系统文件（.DS_Store、Thumbs.db）以及本地环境变量文件（.env）。

在项目创建初期就配好.gitignore，收益巨大。否则一旦把node_modules提交进仓库，仓库体积会膨胀到几百MB，clone、pull慢到怀疑人生。如果你已经错误提交了大文件，前面提到的git rm -r --cached步骤就派上用场，这条命令只从缓存中移除文件，不影响本地磁盘上的文件。

提交信息规范也一样。好的实践是提交说明第一行用动词+摘要，50个字符以内，空行后补充更多上下文。例如：

bash复制git commit -m "fix: 修复订单列表在异常数据下的崩溃问题

原因是status字段可能为空，获取length时抛异常，增加空值保护"

这种规范的提交历史在几个月后回查时，价值会显现得十分明显。

6.4 实测自己的一个推荐：小步快跑式开发流程

最后分享一个我经过长期实践总结出的开发流程，适合大多数人和小团队。做法很简单：在主分支上只接受成熟代码；开发新功能时从最新的main拉分支，命名为feat/功能名或fix/问题描述；尽量把功能拆小，每完成一个可运行的单元就commit一次；提交前先git status和git diff看看改了什么；一天至少push一次到远程分支，做好备份；功能完成并自测通过后再合并回main。

这套流程看似普通，但它避开了大多数冤案：误删代码、找不到历史、合并冲突一大堆、代码丢了没法恢复，几乎都不会再发生了。Git的底层原理很复杂，但日常使用完全可以建立在一套简单的规则之上，规则越稳，用起来越安心。

从第一天的git init，到熟练操作分支合并、解决冲突、使用git reflog救场，这是一个熟悉的过程。说真的，很多人劝退在最初两周，因为它确实和以前“复制文件夹备份”的方式相差太远。但只要坚持用上一个月，形成命令行和分支思维的习惯，你就会发现Git其实没那么难——它不完美，却是当下最值得投资的开发基本功。遇到报错不要慌，先理解系统在背后做了什么，大多数问题都能靠git status、git log和搜索引擎解决。///