Git基础操作这件事，说起来门槛很低，任何一个写过几行代码的人都能在半小时内学会git add、git commit、git push这三板斧。但真正在项目里跑上几个月，你会发现很多人其实一直站在坑里：提交信息写得乱七八糟，分支乱成一锅粥，改错文件只能靠复制粘贴找回，合并冲突处理得像拆炸弹。
这篇东西我不想写成一本命令手册，而是想以我这些年实际使用 Git 的经验，把核心操作背后的逻辑讲清楚，再给出直接能落地的命令、参数和习惯。不管你是刚接触版本控制的新手，还是已经用了一阵子但总觉得哪里不对劲的开发者，应该都能从这里拿走一些能马上用上的东西。
1. 版本控制到底解决了什么问题
1.1 没有版本控制时的痛点
你看过那种文件夹里堆着一排“报告_最终版”“报告_最终版2”“报告_真最终版”的混乱场面吗？代码项目的混乱程度只会更严重。没有版本控制的时候，几个人协作一个项目，最常见的操作是：A把整个项目压缩成zip发给B，B改了几个文件再压缩发回去。过了三天，谁都不记得这个zip和那个zip之间到底改了什么，中间哪些改动已经丢了。更可怕的是，两个方向同时修改了同一个文件，最后只能靠人工比对，一个几千行的文件，眼睛看一遍下来基本就瞎了。
版本控制就是专门解决这些问题的：它能记录每次改动的来龙去脉，能让你随时回到任何一个历史状态，还能让多个人并行开发互不干扰。Git 是目前这个领域事实上的标准，原因很多，但最核心的一点是它的分支模型特别好用，能够支撑非常灵活的协作流程。
1.2 Git 的核心理念：快照而非差异
这里有个概念需要先捋清楚，因为它直接决定了你后续对很多命令的理解。传统的版本控制工具（比如老牌的 CVS、SVN）记录的是“差异”，也就是这次提交相对于上次到底改了哪些行。Git 不一样，它每次提交保存的是整个项目的“快照”——你在某个时刻把所有文件的状态打包记录下来，如果有的文件没变动，Git 就只保留一个指向上次快照的指针，并不真正复制一份内容。
这个设计带来的直接后果是：几乎所有的 Git 操作都是本地完成的，因为每个开发者本地都有一份完整的历史快照。你不联网也能看历史、建分支、做提交，这比那些依赖中央服务器的老工具体验好太多了。另外也正因为是快照，Git 做分支合并时会精确地知道两边的共同祖先在哪里，从而能高效地计算合并结果。
提示：理解“Git 存的是快照”这一点之后，你就明白为什么 .git 文件夹会越来越大，以及为什么有些人会在项目里误把 node_modules 之类的大目录提交进去，导致仓库膨胀到无法直视。
2. 环境准备与初始配置
2.1 环境安装与验证
安装这一步其实没什么好说的，各个主流操作系统都有成熟的安装方式。装完之后打开终端（Windows 上我推荐用 Git Bash 或 Windows Terminal，体验比 CMD 好太多），先跑一下版本确认：
git --version能正常输出版本号，说明 Git 已经装好了。这一步可能遇到的问题是系统里原本就有 Git，但版本较老。Git 的版本迭代往往带来性能和安全性的提升，老旧版本对新代码托管平台的一些认证方式支持得不好，我个人的建议是保持到一个近两年内的版本。
2.2 提交身份的优先级设计
安装完的第一件事不是急着 commit，而是配置你的身份信息。Git 每次提交都会记录提交者是谁，这个信息会永久写入历史，所以最好第一次就配置正确。
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里的--global表示这是全局配置，应用到你当前用户的所有仓库。Git 的配置其实是分层的，优先级从高到低是：仓库级（local） > 全局（global） > 系统级（system）。仓库级配置存放在项目根目录的.git/config里，适合临时覆盖某些设置。比如某开源项目要求提交邮箱必须是你绑定的邮箱，而全局配置里用的是另一个邮箱，那你可以在那个仓库里单独设置一个局部邮箱，不影响其他项目。
验证配置是否生效：
git config user.name git config user.email还有一个很多人忽略的配置是换行符处理和编码，跨平台协作时尤其重要。我在实践中通常建议 Windows 开发者配置autocrlf相关选项，避免每台机器 checkout 代码时因为换行符不同导致整个文件都被判定为修改。这里不展开太细，但你可以留意一下.gitattributes文件，它能在仓库层面把换行符规则固定下来，比靠每个人自觉要可靠得多。
配置完成之后，就可以正式进入 Git 的日常循环了。
3. 日常循环：从工作区到仓库
3.1 工作区、暂存区、仓库区三区模型
我用一句话说明三区关系：工作区是你肉眼看到的、正在编辑的文件；暂存区是一个中间过渡地带，放着你已经告诉 Git“我准备提交这些改动”的文件；仓库区是历史快照的存档点。
这个设计初看觉得多此一举，但实际上是 Git 非常聪明的地方。它让你可以把一次提交拆分成多个逻辑单元：你在一个功能分支里改了三个文件，其中两个是功能代码，一个是拼写错误的注释，那你完全可以只把前两个文件加入暂存区提交，第三个文件留到下一次提交。这样历史记录里的每一步都是清晰、有逻辑的，而不是一大坨“改了一堆东西”。
3.2 日常操作的命令序列
创建一个新项目并纳入版本控制：
git init这个命令会在当前目录下生成一个.git文件夹，里面保存着这个仓库所有的版本历史、配置和索引信息。不用去动它，出了问题往往也都是这个文件夹的问题，最简单粗暴的修复方式就是把.git删掉重新init（这只在你还没怎么提交时有价值，如果已有提交历史，请先备份或者别这么干）。
查看当前仓库状态：
git status这是我用得最多的命令，没有之一。它告诉你现在处于哪个分支、哪些文件被修改了、哪些文件是新加的、哪些已经进入了暂存区。初学阶段，我建议你每次操作前都敲一遍git status，它会像导航一样告诉你下一步该干什么。
把文件加入暂存区：
git add 文件名 git add . # 把当前目录下的所有改动加入暂存区这里有一个很多人踩过的坑：git add .会把当前目录下所有未忽略的改动全部加进暂存区，包括你可能根本没想提交的临时文件、配置文件里的本地私有改动。我的建议是，可以用git add指定具体文件，或者先git status看清楚再批量操作。真有拿不准的情况，可以用git diff看看详细改动内容：
git diff # 工作区与暂存区的差异 git diff --cached # 暂存区与上次提交的差异确认无误之后，提交：
git commit -m "提交说明"3.3 提交信息怎么写才不被人骂
提交信息是这整个环节里看似最不起眼，实际上最影响团队协作质量的东西。我见过太多提交信息是“update”“fix”“aaa”“111”这种，三个月后再看，根本不知道这次提交到底干了什么。写提交信息有几个实用原则：
- 用祈使句，简洁说明这次提交做了什么改动。比如“修复登录时 token 过期未跳转的问题”
- 如果是团队协作，可以在信息里加上类型前缀，比如
feat:表示新功能，fix:表示修 bug，docs:表示文档改动。这就是常见的 Conventional Commits 约定 - 不要混入大量无关改动。一次提交只做一件事，这是纪律，不是技巧
我的习惯是分两行写：第一行概括主题，控制在 50 个字符以内，第二行空一行之后写细节，说明为什么做这个改动、影响范围是什么。具体看团队约定，但至少要让一个没参与过开发的后来人能看懂“这个改动解决了什么”。
提交完成之后，用git log查看提交历史：
git log --oneline --graph --decorate -10--oneline让每条提交只显示一行摘要，--graph用字符画出分支图，--decorate显示分支名和标签，-10只看最近十条。这是我日常排查问题时最常用的命令组合，信息密度高，不会刷屏。
4. 分支操作：从单线到多线
4.1 为什么分支是 Git 的设计精髓
分支说穿了就是一个指向某次提交的可移动指针。Git 里创建分支的成本极低，这让“为每件事创建一个分支”成为可能。你在主分支上写代码，同时想试一个新方案，那就拉一个分支出来，随便折腾，不合适就删掉，主分支一点不受影响。
基于这个机制，团队的协作方式就非常灵活了。常见的主干开发模型是：一条主干分支（比如main或master）始终保持可发布状态，所有新功能开分支开发，开发完成并测试通过后再合并回主干。这样主干上的历史永远是清晰的，任何时刻拉下来都能跑。
4.2 分支的常用操作
创建并切换到新分支：
git checkout -b feature/user-login这条命令相当于git branch feature/user-login加git checkout feature/user-login的合并写法。功能分支命名我建议用feature/、fix/这类前缀，一眼就能看出这个分支的用途，配合类似feature/user-login这样带模块名和用途的方式，团队里找起来非常方便。
查看所有分支：
git branch -a-a表示同时也显示远程分支。当前所在分支会前面带一个星号（*），并且在git status里也能看到。
切换分支：
git checkout main注意：切换分支时，工作区中未提交的改动会跟着你走。如果两个分支对同一个文件有不同的版本，Git 会阻止你切换，并提示你先提交或暂存这些改动。这里有一个非常实用的命令：
git stashgit stash会把当前未提交的改动临时保存起来，让你能干净地切换分支，回头再通过git stash pop恢复。我经常在“这个分支还没做完，但主分支有个紧急 bug 要先修”的场景下用，体验非常好，相当于给你的工作台加了一个抽屉。
4.3 合并分支与冲突处理
把分支 A 合并到当前分支：
git merge A如果两个分支改的文件互不相关，合并会很顺利，自动完成。但如果两个分支同时改了同一个文件的同一处地方，就产生了冲突。冲突产生时，Git 会在冲突文件里插入类似这样的标记：
<<<<<<< HEAD 当前分支（目标分支）的内容 ======= 被合并分支的内容 >>>>>>> feature/your-branch手动编辑这个文件，把冲突部分修改成你想要的结果，然后删除这些标记行，最后：
git add 冲突文件 git commit处理冲突需要在场的人有一定判断能力，建议相关的双方都确认一下最终结果。一个原则是：冲突不是“谁改得对就听谁的”，而是要理解两边各自的意图，合并出一个兼顾两者的方案。很多坑都来自“直接把别人的改动删掉”或者“只保留自己的版本”，这种粗暴处理往往埋下隐患。
注意：处理冲突时，不要用
git checkout --ours或git checkout --theirs这类命令一股脑取一边，除非你非常清楚另一边的改动确实可以完全丢弃。
5. 远程仓库：团队协作的关键环节
5.1 理解“远程”并不是“上级”
很多新手会下意识把远程仓库想成“中央服务器”，但其实 Git 是分布式设计，每个仓库都是平等的。远程仓库只是你当前仓库之外的一个副本，大家约定俗成地用它来同步、共享代码。
把本地仓库和远程仓库关联起来：
git remote add origin <仓库地址>origin是远程仓库的默认别名，这是行业约定，看到它就知道说的是“那个主要的远程仓库”。查看当前关联了哪些远程：
git remote -v5.2 push、pull、fetch，三兄弟的分工
把本地提交推送到远程：
git push origin main把远程的最新改动拉下来并合并到当前分支：
git pullgit pull实际上是git fetch加git merge的快捷方式。git fetch只把远程的提交下载到本地，但不会动你当前的工作区。很多人分不清这两者的区别，其实很简单：fetch是“先看看别人改了什么”，pull是“直接把我这边也更新到最新”。
首次推送一个新分支到远程时，需要设置上游：
git push -u origin feature/user-login-u的作用是把本地分支和远程同名分支关联起来，之后在这个分支上直接输入git push或git pull就行，不用每次都敲完整的参数。
5.3 团队协作中的一些好习惯
协作场景下，最痛的一件事就是冲突集中爆发在提交阶段。其实很多冲突是可以通过频繁 pull 来避免的：你的分支在持续修改，同时主分支也在前进，隔一段时间就git fetch+git merge main（或者git pull origin main）把自己的代码同步到最新，这样每次合并进来的差异量都足够小，冲突即使出现也容易解决。
另外一个值得养成的习惯是，每次开始新功能前，先确认自己的分支是从最新主干拉出来的。不要在过时的代码上开发，然后再经历一场天翻地覆的合并困难。
还有一点，代码托管平台（比如常见的 GitHub、GitLab、Gitea 等）上的 Pull Request 或 Merge Request 流程，本质上是“在远程仓库上执行一次合并”。所以在把分支推送到远程后，你可以去平台上发起合并请求，让代码审查人看过之后再合入，比直接把人家的主干改掉要规范得多。
6. 撤销操作：后悔药也得按方抓药
6.1 三个容易混的命令：checkout、reset、revert
写代码没有不犯错的，Git 的强大之处在于它给了你足够多的后悔药。但药不能乱吃，不同的后悔药覆盖不同的场景。
场景一：工作区某个文件被我改坏了，还没 add，想放弃修改。
git checkout -- 文件名这条命令会用暂存区（或 HEAD 里的版本）覆盖工作区。注意：它只影响工作区，不会动暂存区。如果你已经 add 了，需要先 reset。
场景二：已经 add 进暂存区，但想取消暂存，回到“改了但没 add”的状态。
git reset HEAD 文件名这个命令现在更推荐写成git restore --staged 文件名，语义更清晰。它只把暂存区里的东西撤销，工作区不变，文件内容还在，安全得很。
6.2 reset 的三个模式：soft、mixed、hard
这个命令值得单独拎出来讲，因为它是初学阶段最容易造成“心理阴影”的命令。
git reset --soft HEAD~1--soft模式：只是把 HEAD 指针往回移动一位，暂存区和工作区都不动。效果就是“最新的这次提交被我撤销了，但文件内容还在暂存区里，我可以重新编辑后再提交”。这是最安全的 reset 方式。
git reset --mixed HEAD~1--mixed模式（默认）：把 HEAD 指针往回移动，同时重置暂存区，但工作区不动。效果是“最新提交被撤销了，改动还留在我的工作区里，只是不再是待提交状态”。这也是安全的。
git reset --hard HEAD~1--hard模式：把 HEAD 指针、暂存区、工作区全部回到过去的状态。这是最危险的操作，所有未提交的改动会直接丢失，不可恢复。使用--hard之前务必确认是否真的不要当前状态了。我见过有人想撤销提交结果误加了--hard把一天的劳动成果全部毁掉。真发生了还有救，可以用git reflog找回，但那是另一套操作，并不保证百分之百成功。
提到reflog，这里顺便说一句：git reflog记录的是 HEAD 指针的每一次移动历史，哪怕你用--hard把分支指针回退了，reflog 里依然能看到回退前指向哪个提交，用git reset --hard <那个提交>能找回。我把这个当作救命稻草备着，但对你而言最好的策略是“永远别让局面走到需要救的程度”。
6.3 revert：把伤害留给后来人
如果代码已经推送到了远程仓库，而且其他人已经基于你的提交做了新的工作，这时候用reset改写历史是非常危险的：其他人 pull 的时候会经历大量冲突，甚至把远程仓库搞乱。
正确的做法是git revert。它不会删除历史，而是生成一次新的提交，把之前某次提交的改动反向操作一遍。
git revert <提交哈希>效果是：原来的提交还在历史记录里，上面叠加了一个“反向”的提交，代码状态回到了修改之前。这样远程仓库的历史是线性增长的，大家 pull 下来也能正常合并。虽然看起来多了一条记录，稍微“不够干净”，但在多人协作场景下，安全性远胜于改写历史。
我个人的选择标准是：本地还没推送，用reset，把历史修干净再推；已经推送并且可能被别人基于它工作，用revert，安全第一。
7. 常见问题与避坑实录
7.1 常见错误速查表
| 问题现象 | 常见原因 | 解决办法 |
|---|---|---|
| 提交时提示 “Please tell me who you are” | 没有配置 user.name 和 user.email | 按 2.2 节的命令配置 |
| 提交后 push 时报权限错误 | 远程仓库地址写错或认证过期 | 检查git remote -v，重新配置认证方式 |
| 代码改了但 status 不显示 | 文件可能被.gitignore忽略了 | 检查.gitignore文件中的规则 |
| pull 时提示 “cannot pull with rebase” | 本地有未提交的改动且与远程冲突 | 先git stash或提交本地改动 |
| 误删了分支 | 没有合并就删了 | 用git reflog找到分支指向的提交，重建分支 |
| 大文件把仓库撑爆 | 无意提交了构建产物或依赖目录 | 用git filter-repo或 BFG 清理历史（操作前备份） |
7.2 几个实战中总结出来的习惯
第一，提交之前一定要看git diff。我见过太多人提交了一堆“没想到会提交进去的东西”，比如数据库连接字符串、本地编译缓存、临时测试文件。你敲了git add .之后，先git diff --cached扫一眼，确认每个进入暂存区的文件都是你真正想提交的。这个习惯能让你避免大量社死现场。
第二，给提交、分支命名时多花十秒钟想清楚。有一天你会需要在一个半年前的项目里找出“当初是哪次提交改了登录逻辑”，如果提交信息写得是“fix”或“aaa”，那一刻你会后悔的。反过来，若有类似fix: 修复 token 过期后仍能跳转到工作台的问题这样的信息，git log --oneline扫一眼就能定位。
第三，.gitignore一定要从项目创建第一天就配好。把node_modules/、dist/、build/、*.log、.env、操作系统生成的.DS_Store等逐一加进去。否则它们被提交进仓库之后，清理起来非常麻烦，即使后面删除了文件，历史里依然留着它们的快照，仓库体积永远回不来。网上有很多维护好的.gitignore模板，直接抄作业即可，但记得结合你自己的项目类型删减补充。
第四，遇到吃不准的命令，先用git status和git log确认当前状态，再动手。很多“我把仓库搞坏了”的案例，其实只是操作者没有意识到自己站在哪个分支、有哪些未提交改动、远程和本地差多少。Git 的命令本身都不可怕，可怕的是在状态不明的情况下盲目操作。
最后再说一个我自己的习惯
我每个新项目建完仓库后，都会随手把远程地址配好、.gitignore配好、首次提交打上 tag。然后每次开始一项新功能之前，都会先 pull 一下主干，拉一个带名字的分支出来，再开始写。写完一个小单元就 commit 一次，绝不攒着到最后一把梭。这些习惯看上去都很笨，但它们让我在最忙乱、最紧急的时刻依然能不犯错。Git 本身不难学，难的是把这些动作内化成你自己的肌肉记忆。希望这篇东西能帮你少走一些我当年走过的弯路。
