Git 这个东西说实话刚接触的人容易把它当成一个“上传代码的网盘工具”用着用着就会发现不对劲怎么动不动就冲突了怎么改个文件还要先 add 再 commit怎么 reset 一下代码没了。我见过太多新人在这一步就劝退了但其实 Git 的设计逻辑捋顺了之后非常顺它解决的从来不只是“存代码”而是让你在改代码这件事上能随便折腾、随时反悔、多人并行不打架。这篇东西我不打算搞成一本正经的文档式教程就按我平时带新人、帮同事擦屁股的实际路径来讲讲 Git 的核心东西。内容包括 Git 到底在解决什么问题、安装好之后第一件事要配置什么、每天高频用的命令怎么理解、分支怎么玩才不乱、多人协作时怎么避免互相伤害、以及改错了怎么安全地退回去。看完你至少能明白自己在敲什么、为什么这么敲、出了问题去哪里找答案。1. 先搞清楚 Git 到底在解决什么问题1.1 从“网盘式备份”到“版本快照”很多人一开始管理代码是这么搞的项目文件夹复制一份改名为project_final改两天后又复制一份改名为project_final_v2再改出问题了想回退结果发现 v2 和 final 都不知道差在哪。这就是典型的没有版本管理意识。Git 的核心思路其实特别朴素每次你觉得代码到了一个“可以记录”的点就拍一张快照Git 把整棵文件树的状态完整记录下来。之后你可以随时在任何两张快照之间来回跳也可以把某一次改动单独拿出来看甚至可以创造出一条完全独立的时间线去“实验”想法成功了再合并回来失败了直接丢掉。这个思想和网盘同步有本质区别。网盘帮你存的是“当前最新状态”Git 帮你存的是“整个演变历史”。所以你在 Git 里做的几乎所有操作本质上都是在操作这条历史链条新增一个节点、回到某个节点、对比两个节点的差异、把两条链合并到一起。1.2 三个区域工作区、暂存区、版本库理解 Git 绕不开这三个概念这是整个工具的地基。工作区就是你电脑上肉眼可见、编辑器里正在改的那些文件。暂存区你可以把它理解为一个“候车区”。你告诉 Git“我要把这几件事记到历史里”但还没正式盖章这些改动就先放在暂存区。版本库一旦 commit改动就正式生成一个快照节点进入 Git 的版本历史里永久只要你不主动搞破坏保留。很多人第一次用 Git 会疑惑我明明git add了怎么git commit之后git status还是有东西大概率是改了文件之后忘了重新 add。这是新手最常见的“灵魂拷问”来源之一。养成一个肌肉记忆每次 commit 前先git status确认一下到底提交了什么再动手。1.3 Git 是“快照”而不是“差异补丁”SVN 时代版本库存的是相邻两个版本的差异要还原某个版本需要从起点开始不断叠加补丁。Git 则相反每个 commit 节点都保存了那一时刻全部文件的一个引用切分支、看历史都极其快。这就解释了为什么 Git 的很多操作看着“重”实际上非常轻——因为它存的是快照的引用关系而不是真的把每个版本的文件都复制一份塞满磁盘。这个思想理解了后续很多命令行为你都不会觉得奇怪。2. 安装与初始化不要小看第一步2.1 各平台的安装方式说实话安装 Git 本身没什么技术含量但这一关劝退了很多人尤其是 Windows 用户一看到一堆安装选项就懵。Windows去 Git 官网下载安装包一路默认即可。唯一建议留意的是安装过程中“调整 PATH 环境变量”那一步默认选项就行选错了可能导致命令行里找不到 git。macOS终端里敲git --version如果没装系统会弹窗引导你安装 Command Line Tools。或者你有 Homebrew 的话brew install git也算省事。LinuxDebian/Ubuntu 系用sudo apt install gitCentOS/RHEL 系用sudo yum install git没什么好说的。装完之后建议顺手做一件事关掉当前终端重新开一个敲git --version确认输出正常。这一步能避免不少“我明明装了怎么提示找不到”的尴尬。2.2 安装后的第一件事配置身份这一步可能比安装本身更重要因为Git 在每次 commit 的时候会把用户名字和邮箱写进历史记录而且是写死的那种。等到你提交完代码发现作者名是whatever或者邮箱是空的再想改就得动用改写历史的命令麻烦得很。打开终端依次执行三行配置git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main前两条大家都能理解第三条是设置新建仓库时默认主分支名字。近些年社区普遍把默认分支从 master 改成了 main提前设置好后面新建仓库就不会在这个细节上纠结。这里有个小知识点--global表示这台机器上的所有仓库都用这个配置。如果你有一些项目需要单独用不同的身份比如工作项目用公司邮箱个人项目用个人邮箱就在对应的仓库目录下执行不带--global的同款命令Git 会优先使用仓库级配置。2.3 配置 SSH Key 不是必须但建议提前做如果你只是在自己电脑上本地用 Git完全可以跳过这一节。但只要你打算往 GitHub、GitLab、Gitee 这类远程仓库上推代码配置 SSH Key 能让你省掉大量“每次输入用户名密码”的烦躁。整个流程三步走生成密钥对ssh-keygen -t ed25519 -C 你的邮箱一路回车即可它会生成一对公私钥默认存放在~/.ssh/目录下。查看公钥内容cat ~/.ssh/id_ed25519.pub把输出的一整行内容复制到远程仓库平台GitHub/GitLab/Gitee 等的 SSH Keys 设置页面里。配好之后clone 远程仓库时选择 SSH 地址而不是 HTTPS 地址后面 push/pull 就不用每次输入账号密码了。实测下来这个体验差距非常大尤其是高频推送代码的时候。3. 每天用得最多的核心命令3.1 从零起步init、add、commit 的完整链路不管你是新建项目还是接手已有代码日常高频链路其实就这么几条。进入项目目录初始化仓库git init这个命令会在当前目录生成一个隐藏的.git文件夹从现在开始这个目录的一切变化都会被 Git 追踪。注意一点不要手动去改.git文件夹里面的东西出问题恢复起来很麻烦。接着把文件加入暂存区并提交git add . git commit -m 初始化项目git add .的作用是把当前目录下所有变动过的文件加入暂存区。.是一种通配符写法代表当前目录。如果你只想提交某一个文件用git add 文件名即可。然后git commit -m后面跟的引号内容就是这个历史节点你写给未来自己/队友看的“改动说明”。我强烈建议每个 commit 都写清楚“做了什么、为什么这么做”不要用update、fix、asdf这种废话提交信息。等过两周你回来看历史你会感谢当初好好写说明的自己。3.2 查看状态与历史记录git status是你平时用得最多的命令没有之一。它告诉你三件事当前在哪个分支、哪些文件被改过、哪些改动已经暂存。每次操作前养成敲一下的习惯基本可以避免九成误操作。git log查看提交历史git log --oneline --graph --all--oneline让每条记录只显示一行摘要--graph用字符画的方式显示分支走向--all显示所有分支而不是只有当前分支。这三个参数组合在一起是我个人最推荐的历史查看方式信息够用且直观。3.3 对比差异diff 的正确用法git diff是检查“改了什么”的命令它对于排查一个莫名其妙的问题特别有用。git diff # 查看工作区与暂存区的差异 git diff --staged # 查看暂存区与上一次提交的差异 git diff HEAD # 查看工作区与最近一次提交的差异新手最容易混淆的是前两个。简单记忆方法不带参数的 diff 看的是你“还没 add 什么”带--staged的看的是你“已经 add 了什么”。4. 分支管理让代码“并行”成为可能4.1 分支到底是什么一句话解释分支它是一条独立的提交时间线。在 main 分支上创建出一个新分支这两个分支上的提交互不影响你可以在新分支上随便折腾折腾完了再合并回主分支折腾砸了直接删除分支主分支毫发无损。理解这一点后很多项目规范你就能看懂为什么了开发新功能开feature/xxx分支、修紧急 bug 开hotfix/xxx分支、坚决不在 main 分支上直接改代码。这些规则的本质不是搞形式主义而是保证主分支永远处于一个可发布的状态。4.2 分支的创建、切换与合并最常用的分支操作如下git branch 新分支名 # 创建分支 git checkout 分支名 # 切换分支 git checkout -b 新分支名 # 创建并切换高频用法 git branch -d 分支名 # 删除分支合并分支的核心命令是git merge 要合并进来的分支名假设你在feature/login分支上开发完登录功能想合并回main步骤是git checkout main切回主分支git merge feature/login把功能分支合并进来如果没问题删掉feature/login分支收工这里有个新手的常见困惑合并前要不要先 pull 最新代码答案是要。在开始一天的开发前或者准备合并分支前先把目标分支拉到最新状态能减少大量冲突。4.3 合并时机与方式的选择git merge会保留两条分支的分叉历史看着像一张网如果开发过程中分支不多也可以用git rebase把一条分支的提交“搬到”另一条分支的顶端让历史变成一条直线。我的建议是自己随意折腾的分支rebase 更清爽多人共享的分支主角必须是 merge尽量别擅自 rebase原因是 rebase 会原封不动地“重放”提交如果那条分支已经被别人拉下去用了你 rebase 之后 push别人再 pull 就会遇到历史分叉不一致的问题那种局面真的很难解释清楚。关于合并冲突很多人谈之色变其实是正常现象。当两个分支改了同一个文件的同一行时Git 不知道你想保留哪个只能停下来让你人工裁决。冲突文件里会看到这样的标记 HEAD 这是当前分支的内容 这是要合并进来的内容 feature/login解决方式不复杂编辑文件删掉、、这些标记行把内容改成你最终想要的版本然后git add这个文件再git commit合并就完成了。我见过不少新人在这里手忙脚乱其实放宽心冲突只是意味着“需要人来判断”而不是“出事故了”。5. 远程协作把代码推到远端5.1 建立远程连接remote 与 clonegit remote add origin 远程仓库地址用于把本地仓库与远程仓库关联起来origin只是远程仓库的默认命名不是硬编码。git clone 远程仓库地址则会把远程仓库完整复制到本地包括所有分支和历史记录同时自动配置好 remote。所以接手一个已有项目通常直接git clone就完事。这里有一个实操细节值得提一下克隆下来的仓库默认只会在本地给你建一个当前分支的跟踪关系想查看全部远程分支用git branch -r能看到远程有哪些分支。真正要切到某个远程分支开发一般git checkout 分支名就行Git 会自动帮你创建本地分支并追踪对应的远程分支。5.2 push 与 pull两个方向的同步把本地提交推送到远程git push origin 分支名如果你是第一次推送这个分支并且想让本地分支和远程分支建立跟踪关系可以用git push -u origin 分支名-u是--set-upstream的简写设置一次之后后续在这条分支上直接敲git push和git pull就可以了不用再重复指定远程仓库和分支名。拉取远程更新到本地git pull注意git pull在底层其实是git fetch加git merge的组合。git fetch只是把远程的最新状态下载到本地但不动你当前的工作区真正把远程更新合并到当前分支的是merge这一步。理解了这个底层逻辑你就知道为什么有时候git pull会弹出一个提交信息编辑界面——因为它本质上是在执行一次合并合并产生了新的提交节点。面对这个界面不用慌按:wq然后回车Vim 操作即可保留默认提交信息。5.3 多人协作的标准流程日常协作中一个比较安全的标准流程是git checkout maingit pull origin main把主分支更新到最新git checkout -b feature/我的功能从最新主分支拉出自己的开发分支开发完commit 提交git checkout main并git pull origin main看看主分支有没有新动静git merge feature/我的功能合并git push origin main这套流程最核心的点在于尽量减少长期分支存在的周期每次合并前都先同步最新主分支。这么做不是为了好看而是为了减少冲突面积——一个分支存活时间越久它和主分支的差异就越大合并时冲突点就可能越多。6. 改错了怎么办撤销与回滚的正确姿势6.1 还没提交checkout 与 restore改完代码发现改砸了想恢复到修改前的状态git checkout -- 文件名或者新写法git restore 文件名这个命令会用最近一次提交的版本覆盖工作区文件。警告这个操作不可逆所有未提交的改动会直接丢失没有二次恢复机会。所以我通常建议先确认一下自己是不是真的不想要这些改动了再执行。如果改动已经执行过git add想撤销暂存状态但不改文件内容git restore --staged 文件名这个操作只是把文件从暂存区“退回去”代码内容还在工作区所以相对安全。6.2 已经提交了reset 与 revert已经 commit 了才发现有问题有两个处理思路git reset和git revert很多人在这里容易搞混。git reset本质是移动 HEAD 指针相当于“回到过去”git reset --soft HEAD~1 # 撤销提交保留改动在暂存区 git reset --mixed HEAD~1 # 撤销提交保留改动在工作区默认 git reset --hard HEAD~1 # 撤销提交改动直接扔掉--soft和--mixed相对安全真正的危险是--hard它会从工作目录里直接删除改动本地未推送的代码可能就此消失。git revert则完全不同它不做“穿越”而是新生成一个反向提交把某个旧提交造成的改动“抵消”掉git revert 某次提交的哈希值举一个实际场景你昨天推送了一个提交今天发现那个提交里有个 bug。由于远端代码可能已经被同事拉去用了这时候用git reset --hard再强制推送是非常危险的很可能导致同事本地历史错乱。而git revert只制造一个新的提交不改变历史所有人的仓库状态会自然平滑。所以我的选择原则极其简单还没有推送的提交想改就 reset已经推送并且可能被其他人拉取的提交用 revert6.3 紧急场合stash 临时保存现场开发到一半需要切换分支但又不想把当前半成品提交上去这时候git stash就是你的救星git stash # 把所有未提交的改动暂存起来工作区回到干净状态 git stash list # 查看暂存列表 git stash pop # 恢复最近一次暂存的改动并删除记录配合分支使用这个命令能让你在不中断手头工作的情况下灵活切换上下文。老实说这就是那种“用过的都说好、不用的人总觉得没必要”的功能等你在现场救过几次火就明白它的价值了。6.4.gitignore让不该进仓库的文件别进来这个虽然不属于撤销操作但跟“避免错误”密切相关。像node_modules、target、build、dist、.env、IDE 配置文件这类文件不应该提交进版本库。做法是在项目根目录创建.gitignore文件把要忽略的文件和目录写进去例如node_modules/ dist/ .env *.log .DS_Store这个文件本身应该被提交到仓库里这样所有协作者都共用同一套忽略规则。我见过不少人忘了配.gitignore把node_modules整个提交进了仓库结果仓库体积暴涨到几百兆clone 一次慢到怀疑人生。7. 避坑指南与常见问题排查7.1 提交者身份不对问题commit 之后发现git log里的作者名和邮箱不对或者远端显示“该提交不是本人”。解决修改配置后执行git commit --amend --reset-author把当前提交的作者信息替换成新配置。这条命令同样适用于修改 commit 信息写错字的情况。7.2 提交到了错误的分支问题在 main 分支上不小心提交了本该在 feature 分支上开发的代码。解决如果该提交还没推送可以用git reset --soft HEAD~1把提交撤销到暂存区然后切到正确的分支再git commit。如果已经推送了就麻烦一些需要小心处理远程历史不过一般场景下尽早发现尽早改。7.3 遇到大文件怎么办问题本想提交一个大资源文件结果发现 push 的时候特别慢或者远程仓库直接拒绝推送大文件。解决优先考虑项目是否真的需要这个文件入库。像视频、安装包、依赖库这类东西更适合放在对象存储或各团队的制品仓库里而不是塞进 Git 历史。一旦一个文件进入了历史即使你后来删掉它它依然留在 Git 的历史记录中仓库体积减不下来。早期就配好.gitignore、严格审查入库内容比后面想办法清洗历史容易得多。7.4 中文文件名乱码问题含中文文件名的文件在git status和git log里显示成转义字符。解决Git 默认会对非 ASCII 文件名做转义显示想恢复中文显示执行git config --global core.quotepath false这条配置在许多社区中被广泛推荐非常实用至少我配置之后再也没被乱码困扰过。7.5 误删了分支或丢失了提交问题删错了分支或者 reset 之后发现刚才的提交里有些代码还想找回来。解决先用git reflog查看本地的全部操作记录它记录了 HEAD 的一举一动。找到那次提交的哈希值后有两种恢复路径可以直接git branch 新分支名 哈希值在指定哈希处重建分支也可以git checkout 哈希值先查看内容再说。只要提交曾经存在reflog 通常都能帮你找到它所以我特别强调的是Git 的绝大多数操作是可逆的真的丢了什么东西先别慌还有救。7.6 命令速查小抄整理一份日常用的速查表方便贴在手边场景命令查看状态git status查看简洁历史git log --oneline --graph --all查看工作区改动git diff暂存全部改动git add .提交git commit -m 说明创建并切换分支git checkout -b 分支名查看所有分支git branch -a合并分支git merge 分支名推送分支git push -u origin 分支名拉取更新git pull暂存现场git stash/git stash pop撤销未提交修改git restore 文件名撤销最后提交并保留改动git reset --soft HEAD~1安全撤销已推送提交git revert 哈希值最后聊一点我自己的体会。Git 这个工具刚用的时候觉得命令又多又绕但等你在真实项目里摸爬滚打一阵子你会发现它几乎不会“误伤”你绝大部分“翻车”都来自对底层模型的不理解或者操作太着急没看状态。我的建议一直是动手之前先git statuscommit 之前想清楚这次提交说明怎么写合并之前先git pull。这三条看着简单能长期做到你的 Git 体验会比身边绝大多数人都顺。真要遇到拿不准的操作在共享分支上优先想想还有没有其他同事会受影响宁可保守也不要硬来。