Git完全上手指南：版本控制、分支管理与团队协作实战

我早期带团队的时候，最头疼的不是业务逻辑写不对，而是代码版本乱成一锅粥。项目文件夹里存着“最终版”“最终版2”“真最终版”“打死不改版”，每次合并都得手动打开对比工具，来回核对哪个文件是最新的。后来被同事拉着用Git管理项目，才意识到以前那些所谓的“版本管理”根本就是在裸奔。Git这东西，本质上就是一个把你的代码每一次改动都记录在案的时间机器。改坏了能回滚，多人并发开发不会互相覆盖，谁在什么时间改了什么，一查一个准。

这篇博文不是什么高深的理论课，而是一份我实际用下来的Git上手指南。我会从安装配置讲起，把日常开发最常用的命令、分支协作流程、以及那些你大概率会踩进去的坑，全部掰开揉碎讲清楚。内容不分前后端、不论平台，只要你的工作要碰代码、要跟别人协作，这套Git的基本玩法就一定能派上用场。新手照着敲一遍就能上手，有经验的也能从我踩坑实录里帮你避掉几个雷。

1. 内容整体设计与思路拆解

1.1 Git到底解决的是什么问题

Git是一个分布式版本控制系统，这是它官方定义的“户口本”名字。听起来很学术，但你只需要记住它的核心价值：记录项目文件的历史状态。想象一下你在玩一款自带存档功能的游戏，每通一个关卡就存一次档，哪天不小心把小怪打崩了，可以随时读档回到之前的状态重新挑战。Git就是你在写代码这个游戏里的存档系统，而且它特别慷慨，允许你在任何一个存档点分支出去，走一条完全不同的剧情线，感觉不对还能再切回来。

它最大的特色是“分布式”这三个字。传统的版本控制工具比如SVN，是集中式的，所有历史记录都存在中央服务器上，服务器一挂，整个团队的协作就瘫痪了。Git不一样，每个开发者本地都有一份完整的仓库副本，包括全部的历史提交记录。这意味着你可以在没网的高铁上、在信号不好的咖啡馆里，照常提交代码、创建分支、查看日志。等到有网络了，再把自己本地的成果同步到远程仓库。

从团队协作的角度看，Git解决的是“并行开发不打架”的问题。两个同事同时修改同一个文件的不同功能，传统方式是A改完传给B，B再改，中间极其容易覆盖。Git的做法是每个人都基于最新版本在自己的分支上干活，完成后把分支合并回主干。如果确实存在冲突，Git会明确告诉你这个文件的哪几行有冲突，等你手工处理完再提交。这个过程完全透明、可控，不会发生任何静默覆盖的惨剧。

1.2 基本使用需要掌握的核心概念图谱

学习Git最忌讳的就是照抄命令，却不知道每个命令背后在干什么。你得先建立起一套心智模型，搞清楚Git内部那几张“桌子”是怎么摆的。

这里有三个最基本、最核心的概念，请务必记牢：工作区、暂存区、版本库。工作区就是你在电脑上看到的那个项目文件夹，你的代码改动最先体现在这里。暂存区是一个临时存放改动的地方，它的存在有点像一个“蓄水池”，让你可以分批次、有选择地把你改动过的文件打包成一个个提交。版本库则是Git真正保存历史记录的地方，里面存放着一个又一个提交（commit），每个提交都是一次完整的项目快照。

操作流程大概是这样的：你在工作区里改代码，Git会感知到文件被修改了；然后你用 git add 把这些改动放进去暂存区；接着 git commit 将暂存区里的内容生成一个新的版本，存入版本库。这三个步骤串起来，就是Git最基本的“提交铁三角”。很多人刚学Git时会困惑：“我明明改了文件，为什么 git status 还是提示有变更？”答案往往就是：你只动了工作区，还没执行 git add 把改动挪进暂存区。

另外一个重头戏是分支（branch）。分支可以理解成平行宇宙。主分支（默认叫main或master）是你项目的“主干现实”，而其他分支是从某个时间点分叉出去的替代宇宙，你在替代宇宙里怎么折腾都不会影响主干。等你在分支上的功能开发完成、测试通过了，再把它合并（merge）回主干，你的改动才正式成为项目的一部分。每当你想尝试一个新想法，请养成先开新分支的习惯，这等于给项目穿了一层防弹衣。

我把每天必用的核心命令整理成了下面的表格，你这个阶段不需要全部背下来，但要能看懂它们各自是干什么的：

1.3 为什么我推荐你用命令行而不是图形界面

现在市面上有非常多好用的Git图形化工具，比如SourceTree、GitKraken、GitHub Desktop，包括很多IDE内置的Git面板。我承认，这些工具确实降低了Git的上手门槛，按钮点一点就能完成操作。但我还是强烈建议你至少在初期阶段，把命令行操作作为你的主要学习路径。

理由有两点。第一，命令行是Git的“母语”。所有图形化界面本质上都是在帮你包装命令行的执行过程。当你遇到图形界面解决不了的诡异问题，或者你在无图形界面的服务器上操作，你就不得不回到命令行。第二，命令行让你对每一步操作有清晰的掌控感。点按钮的时候你可能并不知道背后执行了哪几条命令，但逐条敲命令的时候，你被迫思考自己到底在做什么，这对建立正确的Git心智模型至关重要。

这不是让你完全抛弃图形界面。我的实践是：命令行用来学习、理解和处理复杂操作，图形界面用来快速查看历史树、diff对比细节、解决合并冲突，两者结合效率最高。但起步阶段，请你老老实实把命令行用顺了再谈其他。

2. 安装配置与环境准备

2.1 各平台Git安装与验证

Git的安装本身不算复杂，但不同操作系统之间有一些细节差异，这里一个个过一遍。

Windows用户，推荐直接从官网下载安装包。安装的时候有几个选项容易让人犯迷糊，我这里给你标注几个需要留意的点：第一，在选择“Adjusting your PATH environment”这一步，务必选第二个“Git from the command line and also from 3rd-party software”，这样Git才能正确加入系统环境变量，命令行里才能识别到git命令。第二，行结束符转换那一项，如果你纯Windows环境，选“Checkout Windows-style, commit Unix-style line endings”是稳妥的默认项；如果团队跨平台协作，建议统一采用“Checkout as-is, commit Unix-style line endings”，避免因为换行符差异导致的文件变动误报。第三，尽量选择“Use Windows' default console window”的终端选项，而不是Git Bash自带的那个，日常操作更顺手。

macOS用户就简单多了，Git是很多开发工具的底层依赖，你大概率已经装过。没装的话，装了Xcode Command Line Tools之后系统就会自动带上Git，这也是Apple官方推荐的方式。你也可以用Homebrew安装更新版本，两条路都可行，我个人习惯是后者，因为可以精确控制版本。

Linux用户更不用多说，你的发行版软件源里一定有Git，以Ubuntu为例，一条 apt install git 就能搞定。安装完成后，在任何终端里输入 git --version，如果能正常回显版本号，说明你已经成功装好了。这时候走一个初始的体检流程，确保后续操作的灵活性。

提示：安装完成后打开终端输入 git --version，看到形如 git version 2.39.2 (Apple Git-145) 的输出就代表OK。如果提示“command not found”，别急着卸载重装，大概率只是环境变量没配好或安装时漏了勾选PATH选项。

2.2 首次使用前的全局身份配置

安装完Git，第一件要做的事情不是急着建仓库，而是告诉Git“你是谁”。每次提交代码时，Git都会把你的身份信息一并写入提交记录里，所以团队成员才能知道某段代码出自谁手。

这里需要配置两个全局变量：用户名和邮箱。终端里依次执行：

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

注意，这里的名字和邮箱不是注册某个平台的账号，而是你希望展示在提交记录里的身份标识。但如果你用的是GitHub、GitLab、Gitee这类代码托管平台，强烈建议邮箱填你注册平台时用的那个，这样平台能把你的提交记录正确关联到你的账号头像上，否则你辛苦敲的代码在贡献图上永远不会亮起来。

验证配置是否成功，可以执行 git config --list，它能列出所有当前生效的配置项。如果想只看全局用户名，可以执行 git config --global user.name 精确输出。

还有一个我认为极其好用的配置项，值得现在就设置好：

bash复制# 让Git在输入命令时自动开启颜色高亮
git config --global color.ui true

开启之后，git status 的输出文字会按文件状态显示不同颜色，红色表示未跟踪，绿色表示已暂存，一眼就能看清当前仓库处于什么状态。这个小习惯能让你的命令行体验好上不止一倍。

2.3 初始化你的第一个仓库

一切配置妥当，来找一个空目录开始正式起步。假设你有一个叫 my-project 的文件夹，里面已经放了一些还没被管理起来的代码文件，现在需要让它变成Git仓库。

bash复制cd my-project
git init

执行完 git init 后，Git会在当前目录下创建一个隐藏的 .git 文件夹，这才是Git仓库的“本体”，你的所有版本历史、分支信息、配置选项都存在这里面。这也是Git分布式特性的根基——这个文件夹里存着整个项目的完整时间线。

这里必须提醒一个新手极其容易犯的错误：.git 文件夹只是本地仓库的元数据，不要手动去改它里面的文件，更不要把它上传到什么云盘或者通过聊天软件发给别人。它一旦损坏，你整个项目的历史记录就灰飞烟灭了。日常操作中，你也完全不需要关心里面的具体结构，知道它的存在和作用就够了。

初始化仓库后，建议立刻执行一次 git status 看看当前状态。此时你会看到类似这样的输出：On branch master 或者 On branch main，并且下面列出了项目里的所有文件，显示为“未跟踪”（untracked）状态。这代表Git已经看到了这些文件，但还没开始记录它们的变化。到了这一步，你的Git之旅就正式启航了。

3. 日常核心操作：把改动变成历史

3.1 修改文件与暂存区机制

初始化完仓库，我来带你走一遍最日常的工作流。假设你项目里有一个 index.html，你打开它修改了首页的标题文字，然后关闭编辑器回到终端，执行 git status。这时候Git会告诉你 modified: index.html，意思是这个文件发生了变更，但变更还没有被正式记录。

下一步，你需要执行 git add index.html。这条命令的完整作用是“把工作区的改动移动到暂存区”。为什么中间非要隔一层暂存区，直接提交不行吗？这是Git设计上的一个精妙之处：它允许你拆分提交。比如你一个下午改了三个不同的功能，分别涉及三个文件，你可以先 git add 文件A，提交一次；再 git add 文件B，提交一次；最后提交文件C。这样的好处是提交历史非常干净，每个提交只做一件事，将来排查问题时可以直接定位到对应功能的提交节点。

实际项目中，你不太会一次只提交一个文件，更多时候是：

bash复制# 把所有已修改和未跟踪的文件全部加入暂存区
git add .

或者，只加入某个文件夹下的改动：

bash复制git add src/

但全量 git add . 也是一把双刃剑。一不小心会把一些临时文件、日志文件、配置文件都加进暂存区，这些本来不该被提交的东西一旦提交进了仓库，后续处理起来相当麻烦。等后面讲到 .gitignore 的时候，我会详细说明如何用规则提前屏蔽这类文件，现在你心里有个概念就行。

如果你想确认暂存区里的内容跟工作区是否一致，可以用 git diff --cached 查看已暂存的改动详情。这里需要区分两个diff命令：git diff 是看工作区里改了什么（还没暂存的改动），git diff --cached 是看暂存区里改了什么（已暂存待提交的改动）。理解这层区别，对你的日常操作判断会很有帮助。

3.2 提交记录的正确写法与查看日志

暂存区的使命是“打包改动”，而真正让改动变成历史的一步，是提交。执行：

bash复制git commit -m "修复首页标题显示异常的bug"

-m 参数后面跟的是你的提交说明，就像是给这个版本打的标签，告诉未来的你（或者同事）这次改动做了什么。提交信息的质量直接决定了项目历史的可读性。我自己看到过太多“update”“修改”“aaa”这种毫无信息量的提交说明，一旦项目出问题需要回溯，看到这种说明头都要大了。

一个能大幅提升协作体验的提交信息规范是“类型+描述”的结构。比如：

• fix: 修复登录接口超时的问题
• feat: 新增用户注册功能
• docs: 更新README文档
• style: 调整代码格式，不涉及逻辑变更

这种规范演进自业界知名的约定式提交（Conventional Commits），它让提交历史像一份有序的项目日志，什么时间做了什么功能、修了什么bug，一清二楚。

提交完成后，查看历史的命令就是 git log：

bash复制# 查看完整提交历史
git log

# 简化版，一行显示一条记录
git log --oneline

git log --oneline 是我用得最频繁的查看方式，简洁明了。每条记录会显示一个由字母和数字组成的短哈希值（比如 2f3a4b1），这就是该提交的唯一身份证号。当你以后需要回滚到某次提交、对比某两次提交的差异时，都需要用到这个哈希值。

3.3 撤销操作与后悔药

人非圣贤，孰能无过。Git之所以让人有安全感，是因为它给了你充分的“后悔”空间。我把日常会用到的撤回命令按“后悔程度”从小到大给你捋一遍。

如果只是改了文件但还没执行 git add，你突然觉得改错了想撤回：

bash复制# 丢弃工作区中指定文件的全部改动，恢复到最近一次提交的状态
git checkout -- index.html

注意这个操作是“不可逆”的，文件会直接恢复到上一次提交时的样子，工作区中的改动彻底没了。执行前建议先 git diff 看一眼到底改了什么，确定不要了再撤。

如果已经 git add 进了暂存区，但还没提交，你想把文件从暂存区退回来：

bash复制# 取消暂存，文件保留在工作区的改动状态
git reset HEAD index.html

这个操作相对温和，只是把文件从暂存区“退票”，实际内容一点没动，你还有机会重新调整后再 git add。

最头疼的情况是：已经 git commit 提交了，结果发现提交信息写错了，或者少提交了一个文件。这时候可以用：

bash复制# 修正上一次提交，不会产生新的提交记录
git commit --amend -m "修正后的提交说明"

如果你用了 --amend 但没带 -m，Git会打开默认编辑器让你修改提交信息，新手常在这里卡住不知道怎么退出编辑器。Vim编辑器下，按 i 进入编辑模式，输入新说明，然后按 Esc，再输入 :wq 回车保存退出。或者干脆都用 -m，省得跟编辑器纠缠。

如果已经提交了，而且提交完还做了别的事，想回到过去某个状态，就要动用 git reset 的时间旅行能力了：

bash复制# 回退到指定的提交，同时保留工作区改动
git reset --soft <commit哈希>

# 回退到指定的提交，暂存区和工作区都会恢复到该提交的状态（危险）
git reset --hard <commit哈希>

--hard 是名副其实的“核弹级”操作，它会把你工作目录的内容全部替换成指定提交时的样子，任何没提交的改动都会消失。使用前请务必确认你清楚自己在做什么。

注意：上面的撤销操作有一个前提——它们只适用于你还没把提交推送到远程仓库的情况。一旦已经推到远程，别人可能已经拉取了你的提交，这时候做 reset 再强推会带来很多协作上的麻烦。针对这类“已经推送到远程”的误操作，我的建议是尽量用 git revert（生成一个新的反向提交来抵消错误）而不是 reset，这样不重写历史，对其他人的影响最小。

4. 分支管理：多人协作的定海神针

4.1 为什么分支是Git的灵魂

如果说提交记录是Git的躯体，那分支就是Git的灵魂。多人协作开发同一代码库时，如果所有人都直接在主干上提交，很容易出现互相踩脚的情况：你改到一半的功能代码提交上去，我拉取代码一运行，项目直接报错，因为你的功能还没写完。

分支机制完美解决了这个问题。每个开发任务（新功能、修bug、实验性探索）都可以单独开一个分支，在分支上随意提交代码，不会干扰主干和其他人的工作。等功能开发完成、测试稳定后，再把分支合并回主干，主干始终保持一个可以随时发布上线的健康状态。

实际开发中，一个典型的流程是这样的：

• 主分支（main）上的代码永远是可运行的正式版本。
• 开发新功能时，从 main 拉一个新分支：git checkout -b feature/login-page。
• 在 feature/login-page 分支上正常开发、提交。
• 功能完成后，切回 main，执行 git merge feature/login-page，把功能合并回主干。
• 最后删除已经没用的功能分支。

这套模式业内称为“Git Flow”的精简版，团队再大一点还可以增加 develop、release、hotfix 等分支角色，但工具逻辑和思想完全一致。

4.2 分支的创建、切换与合并实操

分支相关的命令是日常操作的基础，我来演示一遍完整流程。

bash复制# 查看当前所有分支，当前所在分支会以星号标记
git branch

# 创建新分支（但不切换过去）
git branch feature/login-page

# 创建并切换到一个新分支（常用）
git checkout -b feature/login-page

# 切换分支
git checkout main

我建议你养成一个习惯：每次开新功能前，先确认自己在哪个分支上。因为 git checkout -b 新分支名 是基于“当前所在分支”来创建新分支的，如果你本来应该在 main 上拉分支，但实际却站在 dev 分支上，拉出来的新分支就会带着 dev 的代码底子，后续合并时会引入大量无关的代码变动。检查当前分支用 git branch 或 git status 都能看到。

等你在功能分支上的工作完成，需要把改动并回主干时，分两步走：

bash复制# 第一步：切回主干
git checkout main

# 第二步：把功能分支合并到主干
git merge feature/login-page

合并操作执行后，Git会把两个分支的历史记录拼接在一起，主干上新增一个合并提交。如果合并过程中出现冲突，Git会明确提示你哪些文件发生冲突，需要手工处理。

失败的典型例子是：两个分支都修改了同一文件同一位置的代码，Git无法判断到底该保留哪个版本。此时打开冲突文件，你会看到类似这样的标记：

code复制<<<<<<< HEAD
这是当前分支的代码
=======
这是被合并分支的代码
>>>>>>> feature/login-page

你需要手工决定保留哪边（或两边都保留），把标记符号清理掉，然后重新 git add 和 git commit，一段冲突的合并就算处理完了。新手遇到冲突不要慌，这是协作开发的正常环节。有经验的开发者的建议是：合并前先用 git diff 对比一下两个分支的区别，提前预判可能冲突的位置，处理起来会从容很多。

4.3 分支合并策略的选择：merge还是rebase

在分支合并这件事上，Git提供了两种主要策略：merge 和 rebase。两者的目的都是把分支的改动合到一起，但实现路径和最终效果大相径庭，这也是Git学习者最容易纠结的一个点。

git merge 是“记录合并”，它会保留两个分支的开发历史，并在合并点生成一个新的合并提交，完整地保留分支的时间线。优点是历史真实可靠，发生了什么一目了然；缺点是历史线会变得错综复杂，尤其多个分支频繁合并时，日志会像一团毛线。

git rebase 是“变基合并”，它会把当前分支的提交“移植”到目标分支的最新提交之上，让历史看起来是一条直线，非常整洁。但副作用是：它会重写提交历史，原来分支上的提交哈希值会全部改变。所以对于已经推送到远程、并且其他人可能已经拉取过的分支，绝对不要随意rebase，否则你会让同事的本地仓库陷入一片混乱。

我的个人实践是这样一个取舍标准：对于个人开发的功能分支，在合并回 main 之前，我会先 git rebase main 让自己分支基于最新的主干代码，这样在本地解决潜在冲突，再切回 main 做 git merge --no-ff 功能分支，保留一个清晰的合并记录。如果是几个同事长时间共同维护的共享分支，我更倾向于直接merge，不搞变基，避免无谓的历史重写。

提示：如果你还是分不清该用哪个，初期保守策略就是无脑merge，它最安全、最能保留真实历史。等你对Git的理解足够深了，再去玩rebase的花活儿也不迟。

5. 远程仓库协作：让代码跨设备流动

5.1 什么是远程仓库以及它存在的意义

本地仓库的版本管理能力再强，也只是单机游戏。真正让Git释放威力的，是远程仓库。远程仓库本质上是放在服务器上的一个Git仓库，它扮演着“中央枢纽”的角色：大家各自把本地提交推送到远程仓库，再拉取别人推送的更新到本地，从而完成协作。

代码托管平台选哪个看你个人喜好：GitHub是国际最主流的开源社区，Gitee在国内访问速度快，GitLab适合企业内部私有化部署。不管用哪个，底层的Git命令完全一致，这也体现了Git与平台解耦的设计优势。我换个平台时完全无感知，只是换了一个remote地址而已。

在远程协作模型下，你有两个基本操作需要牢牢掌握：push（推送）是把本地提交上传到远程仓库；pull（拉取）是获取远程仓库的最新提交并合并到本地。这两个命令涵盖了日常90%的协作场景。

5.2 克隆仓库、关联远程与推送代码

加入一个已经存在的项目，最常见的方式是克隆：

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

执行完这条命令，你会得到一个包含完整项目文件和全部历史记录的本地仓库，并且自动配置好了远程仓库地址，用 git remote -v 可以查看已关联的远程地址。

如果是你自己从零初始化的本地仓库，想关联到远程，需要先在平台网页上新建一个空仓库，然后执行：

bash复制# origin 是远程仓库的别名，可以起别的名字，但origin是行业默认
git remote add origin https://github.com/用户名/仓库名.git

# 推送本地 main 分支到远程，并设置上游追踪关系
git push -u origin main

-u 这个参数的作用是绑定本地分支与远程分支的追踪关系，以后你在这个分支上只需 git push 就能直接推送到对应的远程分支，不用每次都写完整的 origin main。第一次推送时加上 -u 是业界惯例。

如果你在功能分支上开发完，想也推送一份到远程供同事检视代码，可以：

bash复制git push -u origin feature/login-page

推完之后，如果功能已经合并到main，就可以把这个远程分支删掉了，保持仓库整洁（在分支合并后执行 git push origin --delete feature/login-page 即可）。

5.3 拉取更新时的两种方式与冲突处理

你不可能一直拉别人的最新代码，总要做自己的开发，所以“如何把远程更新合入本地开发线”是你一定会面对的课题。

git pull 其实是一个组合命令，它等于 git fetch（获取远程更新到本地）加 git merge（把远程更新合并到当前分支）。在你提交本地代码之前，尤其是开始一天的工作时，先 git pull 拉一次最新代码，是避免大规模冲突的重要习惯。

但如果你本地已经改了某个文件的某几行，远程恰好也改了同一个位置，执行 git pull 时就会触发冲突。Git会停止自动合并，提示你解决冲突。处理过程跟在分支合并时遇到冲突一模一样：打开文件，删除 <<<<<<<、=======、>>>>>>> 标记，保留正确内容，然后 git add 冲突文件，最后 git commit 完成合并提交。

很多新手在这里容易心态爆炸，以为把代码搞坏了。其实冲突不是错误，而是Git在保护你——它在无法替你判断哪个版本正确的情况下，主动请求人工介入，总比静默覆盖、丢失代码要强一万倍。

为了尽量减少冲突，我给自己定了几条规矩：第一，开始改代码前一定先pull最新代码；第二，每次提交尽量小而清晰，避免一个文件攒了十几处改动才提交；第三，多人同时改同一文件时，提前沟通好各自负责的代码区块。

5.4 常用远程仓库协作命令速查

git fetch 和 git pull 的区别需要单独提一句：fetch只是把远程的提交记录和文件下载到本地，但不改变你当前的工作区，你可以先看看远程改了什么，想清楚再决定是否合并；pull则是立刻执行合并。心态不稳、怕出乱子的时候，fetch是你的安全气囊：先拉下来再说，什么时候合由你控制。

6. 常见问题排查与实战避坑指南

6.1 文件被误删了还能找回吗

开发过程中偶尔会发生误删文件的悲剧，比如 rm -rf src/components 回车、窗口一关，整个人都傻了。这时候Git是你的第一位抢救医生。

如果误删的文件在之前的某个提交里已经存在过，而你还没提交这次删除操作，那恢复非常简单：

bash复制git checkout -- src/components/Button.jsx
# 或者用新版语法
git restore src/components/Button.jsx

文件会从当前分支最近一次提交中恢复到工作区。哪怕你误删的是整个文件夹，也照样能恢复。

更严重的情况是：你删了文件，然后还不小心提交了这次删除操作。那也不用慌，找到删除之前那一次提交的哈希值，然后用reset回到那个提交，或者用revert生成一个反向提交。由于Git保存了全量历史，任何“曾经存在过”的代码都有机会找回，这就是版本控制带来的底气。

6.2 .gitignore 为什么总是失效

很多初学者一上来就写了一大堆 .gitignore 规则，把 node_modules、dist、.env 这些目录全都忽略掉了，结果过两天发现这些文件还是被提交进了仓库。原因通常是：这些文件在被加入 .gitignore 规则之前，已经被 git add 过，甚至已经提交过了。Git的忽略规则只对“未被跟踪”的文件生效，已经被跟踪的文件无论如何写 .gitignore 都不会被忽略。

解决办法也很简单：先把这些文件从Git的跟踪中移除，但保留在本地磁盘上：

bash复制git rm -r --cached node_modules
git commit -m "chore: 移除已被跟踪的node_modules目录"

--cached 参数的作用是只把文件从暂存区移除，不删除本地磁盘上的实际文件。执行完这次提交后，再加上 .gitignore 规则，Git就不会再跟踪这些目录了。

写 .gitignore 时，有一些规律可以把握：语言相关的依赖目录（node_modules、vendor、pycache）、构建产物（dist、build、out）、环境配置文件（.env、.env.local）、IDE本地配置（.idea、.vscode）都属于典型的应该忽略对象。仓库里建议保留一份通用的 .gitignore 模版，团队统一使用，避免不同成员各自维护导致规则满天飞。

6.3 提交到了错误的分支怎么办

这种情况我敢说每个程序员都经历过不止一次：在 main 分支上开发新功能，写了大半天，提交了好几笔，然后一抬头发现“坏了，我应该在 feature/x 分支上写才对”。不用捶胸顿足，切换分支可以优雅救场。

bash复制# 从当前 main 分支新建一个功能分支（包含之前所有提交）
git branch feature/x

# 把 main 分支回退到创立功能分支之前的状态
git reset --hard <main分支原来的提交>

# 切到功能分支继续开发
git checkout feature/x

这套操作的本质是：先用 git branch 创建分支把当前提交“保存”下来，再把原分支重置回之前的状态，最后切到新分支继续干活。实际执行下来，只要代码没有已经推送到远程，整个过程都能安全完成。推送到远程的话就麻烦一些，需要跟团队沟通，尽量避免犯这种错。

6.4 想对比两个版本之间的差异

排查bug、看同事改了什么东西时，对比差异是刚性需求。Git提供的对比工具有几个层次：

• git diff：对比工作区与暂存区的差异。
• git diff --cached：对比暂存区与最近一次提交的差异。
• git diff <提交A> <提交B>：对比任意两次提交之间的差异。
• git diff <分支A>..<分支B>：对比两个分支之间的差异。

比如我今天下午发现有同事把一个函数改了，但不确定他具体改了什么逻辑，执行 git diff 3d2f1a..9c8b7e -- src/utils/format.js 就能只查看这一个文件的变更细节。输出中会以 + 标记新增的行，以 - 标记删除的行，定位精确到行号。配合IDE里图形化的diff视图，排查问题的效率会高很多。

6.5 一张表搞定高频报错的含义与对策

针对切换分支时未提交改动被阻断的情况，git stash 是一个非常实用的工具。它能把当前工作区的改动临时保存到一个“暂存区外的收纳箱”里，让你可以干净地切换到其他分支，回来时再用 git stash pop 恢复改动。我经常用它来处理“临时要去看另一个分支上的东西，但手头的改动不想丢”的场景，比强行提交一个半成品要安全得多。

7. 最后再分享一点我的实际体会

Git这东西，学的时候觉得命令又多又杂，但用顺了以后，你真的会怀疑没有版本控制的日子是怎么撑过来的。我看过很多新手同事刚开始为了省事在一台服务器的同一目录里多人直接改文件，最后线上代码不知道被谁覆盖了，整个团队花了两天时间才把功能恢复回来。那之后全组才痛下决心把协作切到Git上，再也没有发生过类似的事故。

我个人在架设团队Git规范时最看重两件事：一是提交信息的质量，二是分支命名的规范。提交信息按约定式提交来，功能、修复、文档区分得清清楚楚，回溯问题时效率极高；分支命名按 feature/、fix/、docs/ 前缀区分，看一眼分支名就知道这是做什么的，配合CI自动构建还能省去大量沟通成本。

如果你正准备把Git引入团队的日常工作，我的建议是先从一小块业务开始，让几位核心成员率先使用并产出规范示例，跑顺了再全员推广，不要一上来就制定特别复杂的流程。工具永远是为流程服务的，而流程永远是为人的协作服务的，这一点在Git身上体现得尤为明显。翻来覆去把上面这些基本功练扎实，你已经比大多数“把Git当网盘用”的开发者要专业得多了。