Git 从入门到精通：核心概念、常用命令与团队协作实践

Git 是目前最主流的分布式版本控制工具。无论你是写博客、写代码、维护配置文件，还是和团队协作开发，几乎都绕不开 Git。

这篇文章按“从入门到精通”的顺序讲清几件事：

1. Git 到底解决什么问题，和 SVN 有什么不同。
2. Git 的核心概念是什么，为什么很多人“命令会背，但原理不清”。
3. 日常开发最常用的命令怎么用，分别适合什么场景。
4. 分支协作、合并、回滚、变基、标签这些进阶能力该怎么理解。
5. 真正落到团队里，什么工作流更稳，哪些坑最常见。

---

1) Git 是什么，它解决什么问题

最简单地说，Git 是一个“记录文件变化历史”的工具，但它不只是“备份”。

它主要解决这些问题：

• 你改过什么，什么时候改的。
• 你为什么改，能不能写清楚背景。
• 某次修改出问题了，能不能快速回退。
• 两个人同时改同一个项目，怎么合并。
• 一条稳定主线之外，怎么开分支做实验而不影响正式版本。

如果没有 Git，很多团队会变成这样：

• 文件名靠人工区分，例如 final-v2-最终版-真的最终版.zip
• 不知道谁改了什么
• 出问题时只能靠猜
• 多人协作时经常互相覆盖代码

Git 的价值，就在于把“版本历史、协作关系、变更原因”都结构化保存下来。

---

2) Git 和 SVN 的区别

很多教程会先讲这件事，因为它能帮助你理解 Git 为什么是“分布式”。

2.1 SVN：集中式

SVN 更像“大家都连同一台中央服务器工作”：

• 版本历史主要在服务器
• 本地只是工作副本
• 离线能力较弱

2.2 Git：分布式

Git 的特点是：每个仓库本地都包含完整历史。

这意味着：

• 本地就能看历史、建分支、提交
• 大多数操作非常快
• 即使远程仓库暂时不可用，也能先本地开发

所以你可以把 Git 理解成：

• 本地仓库：你自己的完整版本世界
• 远程仓库：团队同步与协作中心

---

3) 先理解 4 个核心概念

很多人学 Git 卡住，不是因为命令太多，而是因为这几个概念没建立起来。

3.1 工作区（Working Tree）

就是你当前看到并正在编辑的文件目录。

例如你改了一个 README.md，但还没执行任何 Git 命令，这些改动就在工作区。

3.2 暂存区（Index / Staging Area）

暂存区可以理解为“本次准备提交的清单”。

你并不是所有改动都必须一次性提交。可以先挑一部分放进暂存区，再提交。

常见命令：

git add README.md

3.3 本地仓库（Local Repository）

执行 git commit 后，改动才真正进入本地版本历史。

git commit -m "docs: update README"

3.4 远程仓库（Remote Repository）

例如 GitHub、GitLab、Gitee 上的仓库。

本地提交之后，并不会自动同步到远程，需要再执行：

git push

一个非常经典的理解图是：

工作区 -> 暂存区 -> 本地仓库 -> 远程仓库

只要你把这条链路想清楚，很多 Git 命令就不会再乱。

---

4) 安装 Git 与初始化配置

4.1 查看是否已安装

git --version

4.2 配置用户名和邮箱

这是最基础也最重要的一步，因为每次提交都会记录作者信息。

git config --global user.name "your-name"
git config --global user.email "your-email@example.com"

查看当前配置：

git config --list

只查看某一项：

git config user.name
git config user.email

4.3 设置默认编辑器

git config --global core.editor "vim"

4.4 设置默认分支名为 main

git config --global init.defaultBranch main

---

5) 创建仓库的两种方式

5.1 在本地新建仓库

mkdir demo-git
cd demo-git
git init

执行后目录里会生成一个 .git 目录，这就是 Git 仓库元数据。

5.2 克隆远程仓库

git clone https://github.com/username/project.git

如果使用 SSH：

git clone git@github.com:username/project.git

---

6) 从 0 到 1：最小工作流

这是日常最常见的一套流程：

git init
git status
git add .
git commit -m "feat: initial commit"
git remote add origin git@github.com:username/project.git
git push -u origin main

你可以把它理解为：

1. 创建仓库。
2. 查看当前状态。
3. 把改动加入暂存区。
4. 提交到本地历史。
5. 关联远程仓库。
6. 推送到远程。

---

7) 最常用命令速查

下面这些命令，是绝大多数开发者每天都会接触到的。

7.1 git status

看当前仓库状态，是最常用的“安全命令”。

git status

你可以看到：

• 当前在哪个分支
• 哪些文件被修改了
• 哪些文件已暂存
• 哪些文件还未跟踪

建议：不确定时先看 git status。

7.2 git add

把改动放进暂存区。

git add file.txt
git add src/
git add .

注意：

• git add . 很方便，但容易把不该提交的文件也加进去
• 团队协作时，更推荐按文件或按目录精确 add

7.3 git commit

把暂存区内容提交到本地仓库。

git commit -m "fix: resolve login validation bug"

补充两个常用写法：

git commit -am "docs: update usage"
git commit --amend

说明：

• -a 只会提交“已被 Git 跟踪的文件”，不会自动包含新文件
• --amend 常用于修改上一次提交信息，或把漏掉的小改动补进去

7.4 git log

查看提交历史。

git log
git log --oneline
git log --graph --oneline --decorate

推荐你长期记住这一条：

git log --graph --oneline --decorate --all

它非常适合看分支关系。

7.5 git diff

看差异。

git diff
git diff --staged
git diff main..feature/login

最常见含义：

• git diff：看工作区和暂存区的差异
• git diff --staged：看暂存区和上一次提交的差异

7.6 git rm 与 git mv

git rm old.txt
git mv old-name.txt new-name.txt

它们会同时处理文件系统变化与 Git 跟踪关系。

---

8) 分支：Git 最强大的能力之一

8.1 查看和创建分支

git branch
git branch dev
git switch -c feature/login

传统写法也很多人使用：

git checkout -b feature/login

现在更推荐：

• git switch：切换分支
• git restore：恢复文件

语义更清晰。

8.2 切换分支

git switch main
git switch feature/login

8.3 删除分支

git branch -d feature/login
git branch -D feature/login

区别：

• -d：安全删除，未合并会阻止
• -D：强制删除

8.4 为什么要开分支

因为分支可以把“正式版本”和“实验开发”隔离开。

典型场景：

• main：稳定主线
• develop：开发集成分支
• feature/*：功能分支
• hotfix/*：线上紧急修复

---

9) 合并与变基：最容易混淆的两个主题

9.1 git merge

把一个分支的结果合并到当前分支。

例如先切到 main，再合并功能分支：

git switch main
git merge feature/login

优点：

• 历史真实
• 分支轨迹完整
• 团队更容易理解

9.2 git rebase

变基会把当前分支“重新接到另一个分支最新提交之后”。

git switch feature/login
git rebase main

优点：

• 提交历史更线性
• 看起来更干净

风险：

• 会改写提交历史
• 已经 push 给别人用的公共分支，不要随意 rebase

9.3 一句话理解

• merge：保留分叉历史
• rebase：重写为线性历史

9.4 推荐实践

对大多数团队来说：

• 本地功能分支同步主线时，可以适度 rebase
• 合并到主分支时，走 PR/MR 审核更稳
• 公共分支慎用历史改写

---

10) 远程仓库协作

10.1 查看远程仓库

git remote -v

10.2 添加远程仓库

git remote add origin git@github.com:username/project.git

10.3 拉取远程更新

git pull
git pull origin main

注意：git pull 本质上通常等于：

git fetch
git merge

所以你想更稳一点时，可以拆开执行：

git fetch origin
git merge origin/main

10.4 推送本地提交

git push
git push -u origin main

首次推送新分支常用：

git push -u origin feature/login

---

11) 撤销、回退、恢复：最容易出事故的区域

这是 Git 教程里必须讲清楚的一部分，因为很多人“会删历史，不会安全回退”。

11.1 撤销工作区改动

git restore file.txt

如果你只是改坏了某个文件，还没 add，这条很有用。

11.2 取消暂存

git restore --staged file.txt

11.3 回退提交，但保留改动

git reset --soft HEAD~1

适合场景：刚提交完，发现提交信息不对，或者想重新整理 commit。

11.4 回退提交，并撤出暂存区

git reset --mixed HEAD~1

这是默认模式。

11.5 彻底丢弃提交和改动

git reset --hard HEAD~1

这条命令危险很高，使用前一定要确认。

11.6 更安全的“反向提交”：git revert

git revert <commit-id>

它不会粗暴改写历史，而是新增一次“反向修改”的提交。

团队协作、公共分支场景下，通常优先考虑 revert，而不是 reset --hard。

---

12) git stash：临时收起现场

当你改到一半，突然要切分支修一个紧急问题，就很适合用 stash。

git stash
git stash list
git stash pop

更完整一点：

git stash push -m "wip: login form"
git stash apply stash@{0}
git stash drop stash@{0}

常见场景：

• 正在开发功能 A，临时被叫去修 Bug
• 当前改动还不适合 commit
• 想先保存现场，稍后继续

---

13) git tag：给版本打标签

标签常用于发布版本，例如 v1.0.0、v2.3.1。

13.1 创建标签

git tag v1.0.0
git tag -a v1.0.0 -m "release version 1.0.0"

13.2 查看标签

git tag

13.3 推送标签

git push origin v1.0.0
git push origin --tags

建议：

• 正式发布版本时，优先使用带注释标签 -a
• 标签命名尽量遵循统一规范，如语义化版本号

---

14) .gitignore：别把不该提交的东西交上去

典型不该提交的内容：

• 编译产物
• 临时文件
• IDE 配置
• 日志文件
• 密钥、密码、本地环境变量文件

一个常见示例：

node_modules/
dist/
.DS_Store
.idea/
*.log
.env

如果某文件已经被 Git 跟踪，再写进 .gitignore 是不会自动失效的，需要先取消跟踪：

git rm -r --cached .
git add .
git commit -m "chore: refresh ignore rules"

---

15) 冲突解决：协作开发绕不开的一课

15.1 冲突怎么来的

最典型场景：

• 你和同事改了同一个文件的同一段
• 你 pull / merge / rebase 时，Git 无法自动判断保留哪一版

15.2 冲突长什么样

<<<<<<< HEAD
当前分支内容
=======
另一分支内容
>>>>>>> feature/login

这表示 Git 把冲突区段标出来，等你手工决定最终保留什么。

15.3 解决步骤

1. 打开冲突文件。
2. 手动编辑成最终正确内容。
3. 删除冲突标记。
4. git add 冲突文件。
5. 继续 merge 或 rebase 流程。

例如：

git add src/app.js
git commit

如果你在 rebase 中：

git rebase --continue

想放弃本次 rebase：

git rebase --abort

---

16) 常用场景实战举例

16.1 新功能开发

git switch main
git pull origin main
git switch -c feature/user-center
git add .
git commit -m "feat: add user center page"
git push -u origin feature/user-center

16.2 修复线上 Bug

git switch main
git pull origin main
git switch -c hotfix/login-null-check
git add .
git commit -m "fix: handle null user in login"
git push -u origin hotfix/login-null-check

16.3 提交前检查差异

git status
git diff
git diff --staged

16.4 修改上一次提交信息

git commit --amend -m "fix: correct login validation logic"

16.5 找回误删分支或误回退的提交

git reflog

reflog 很重要，它能记录 HEAD 的移动历史。很多“以为丢了”的提交，其实还能从这里找回来。

---

17) 团队协作建议：怎么用 Git 更稳

17.1 提交信息要有语义

不要只写：

update
fix
改一下

更推荐：

feat: add search box to tags page
fix: correct mobile toc floating behavior
docs: update deployment instructions
refactor: simplify article card rendering

常见前缀：

• feat：新功能
• fix：修复问题
• docs：文档修改
• refactor：重构
• style：格式调整
• test：测试相关
• chore：杂项维护

17.2 小步提交

一个 commit 尽量只做一件相对独立的事。

这样带来的好处：

• 更容易 review
• 更容易定位问题
• 更容易 cherry-pick 或回滚

17.3 主分支保持稳定

建议：

• main 不直接乱提交
• 功能走分支
• 通过 PR/MR 合并
• 合并前先跑测试

17.4 不要把敏感信息提交到仓库

尤其是：

• 密钥
• Token
• 数据库密码
• 生产环境配置

一旦 push 到公开仓库，即使后续删除，也可能已经进入历史记录。

---

18) 进阶命令与能力

18.1 git cherry-pick

把某个提交单独摘过来。

git cherry-pick <commit-id>

适合场景：

• 某个 hotfix 只想同步一部分提交
• 不想整条分支一起合并

18.2 git blame

查看某一行最后是谁改的。

git blame src/app.js

它不是为了“甩锅”，而是为了快速定位上下文。

18.3 git show

看某个提交的详细内容。

git show <commit-id>

18.4 git reflog

再次强调一次，这条命令是“后悔药”之一：

git reflog

很多误操作之后，第一时间先看它。

---

19) Git 常见误区

19.1 误区一：pull 就是一条简单同步命令

实际上它可能触发合并，甚至带来冲突。所以重要分支上建议先：

git fetch
git log --oneline --graph --decorate --all

确认之后再合并。

19.2 误区二：reset --hard 是万能修复命令

它是“强力清场”，不是“万能修复”。

如果仓库里有未备份的重要改动，这条命令可能让你非常难受。

19.3 误区三：rebase 一定比 merge 高级

并不是。它们只是适用场景不同。

选择的标准不是“谁更高级”，而是：

• 团队能不能理解
• 工作流会不会更稳
• 是否会影响公共历史

---

20) 一个推荐学习路径

如果你是从零开始学 Git，我建议按这个顺序：

1. 先学 init / clone / status / add / commit / log / diff
2. 再学 branch / switch / merge / pull / push
3. 然后学 stash / tag / revert / reset / reflog
4. 最后再理解 rebase / cherry-pick / blame

不要一上来就把所有命令都背完。Git 真正难的是“状态流转”和“历史理解”，不是命令数量本身。

---

21) 日常高频命令清单

下面是一份更适合收藏的速查表。

场景	命令	说明
查看状态	git status	看当前改动、分支、暂存情况
添加文件	git add file.txt	把文件加入暂存区
提交	git commit -m "feat: xxx"	提交到本地仓库
查看历史	git log --oneline	精简查看提交记录
查看差异	git diff	查看未暂存改动
查看已暂存差异	git diff --staged	查看即将提交的内容
创建分支	git switch -c feature/a	创建并切换到新分支
切换分支	git switch main	切回主分支
合并分支	git merge feature/a	把功能分支合并进当前分支
拉取更新	git pull origin main	从远程拉最新代码
推送代码	git push origin main	推送到远程
临时存档	git stash	暂存现场
反向回滚	git revert <id>	新增一个撤销提交
查看操作记录	git reflog	查 HEAD 变化历史
打标签	git tag -a v1.0.0 -m "release"	给版本打标签

---

22) IDEA / VS Code 中图形化使用 Git

很多人一开始学 Git，会更喜欢先用图形界面，再逐步过渡到命令行。这是完全正常的。

图形化工具的优势在于：

• 更直观看到文件变更
• 更容易理解分支、提交、冲突这些概念
• 对新手更友好，降低误操作门槛

但也要注意：

• 图形界面只是“对 Git 命令的封装”
• 真遇到复杂问题时，最终还是要回到命令行理解原理

所以更推荐的学习方式是：

• 平时用 IDEA / VS Code 提升效率
• 同时知道它背后对应的 Git 命令是什么

22.1 IntelliJ IDEA 中常用 Git 操作

IntelliJ IDEA 对 Git 的集成非常完善，Java、前端、后端项目都很适合直接用。

常见入口位置：

• 顶部菜单 Git
• 左下角分支名称区域
• 文件右键菜单
• 提交窗口 Commit

常用操作对应关系：

IDEA 图形操作	对应 Git 命令	说明
Commit	git commit	提交本地改动
Push	git push	推送到远程仓库
Pull	git pull	拉取远程更新
Update Project	git pull / git fetch	同步远程更新
New Branch	git switch -c xxx	新建并切换分支
Checkout Branch	git switch xxx	切换分支
Merge Into Current	git merge xxx	合并分支到当前分支
Rebase Current Onto	git rebase xxx	变基到目标分支
Show History	git log	查看提交历史
Rollback	git restore	恢复未提交改动

1. 提交代码

在 IDEA 中最常用的是提交窗口：

1. 修改代码后，打开 Commit 面板。
2. 勾选本次要提交的文件。
3. 填写提交信息。
4. 选择 Commit 或 Commit and Push。

这样做的好处是：

• 可以按文件勾选，避免把无关改动一起提交
• 可以直接看到 diff，减少误提交

2. 查看差异

IDEA 里看 diff 很方便：

• 文件列表会标颜色
• 点击文件可以直接看到修改前后对比
• 支持逐块查看和比对

这本质上对应的是：

git diff
git diff --staged

3. 切换和管理分支

点击左下角分支名，通常可以完成：

• 新建分支
• 切换分支
• 合并分支
• 删除分支
• Rebase 当前分支

如果你在做功能开发，一个很常见的图形化流程是：

1. 从 main 拉最新代码。
2. 新建 feature/xxx 分支。
3. 开发并提交。
4. Push 到远程。
5. 发起 PR/MR。

4. 处理冲突

IDEA 的冲突处理界面非常适合新手：

• 左侧通常是当前版本
• 右侧通常是对方版本
• 中间是最终结果

你可以逐块选择保留哪部分，再统一保存。

这比手工编辑冲突标记更直观，但你仍然要理解冲突的本质是“同一段内容两边都改了”。

5. 查看文件历史与逐行追踪

在 IDEA 中你还可以：

• 查看某个文件的历史提交
• 查看某一行是谁改的
• 对比两个历史版本

这些分别对应：

git log -- file.txt
git blame file.txt
git show <commit-id>

22.2 VS Code 中常用 Git 操作

VS Code 自带 Git 集成，对轻量开发和前端项目尤其友好。

最常用的入口是左侧的“源代码管理（Source Control）”面板。

常见操作对应关系：

VS Code 图形操作	对应 Git 命令	说明
Source Control Changes	git status	查看变更文件
Stage Changes	git add	暂存改动
Commit	git commit	提交到本地仓库
Sync Changes	git pull + git push	同步本地与远程
Publish Branch	git push -u origin xxx	首次推送新分支
Create Branch	git switch -c xxx	创建分支
Checkout	git switch xxx	切换分支
View History（扩展）	git log	查看历史
Discard Changes	git restore	放弃未提交修改

1. 暂存与提交

在 VS Code 里，文件改动后会出现在 Source Control 面板中。

你可以：

• 单独暂存某个文件
• 暂存全部改动
• 输入提交信息
• 点击提交按钮完成 commit

这能帮助你练习“按逻辑拆分提交”，而不是每次都一把 git add .。

2. 查看 diff

点击某个变更文件，就能看到图形化 diff 视图。

这对写文档、改配置、改代码都很有帮助，尤其适合检查：

• 是否误删内容
• 是否多改了无关部分
• 格式化工具是否带来了额外噪音

3. 分支切换

在状态栏底部可以快速看到当前分支，点击后可以：

• 创建分支
• 切换分支
• 拉取远程分支

如果你装了 GitLens 等扩展，还能更清晰地看提交历史、作者信息和文件演化过程。

22.3 图形界面和命令行怎么配合

一个比较实用的建议是：

• 日常 status、看 diff、选文件提交，可以优先用图形界面
• 涉及 rebase、cherry-pick、复杂冲突、回滚恢复时，优先理解命令行

你可以把二者这样分工：

场景	更推荐方式	原因
看文件改动	图形界面	更直观
选择提交文件	图形界面	勾选式操作更稳
普通 commit / push / pull	两者都可以	都很高频
冲突处理	先图形界面，再理解命令	容易看懂差异
复杂 rebase	命令行为主	更可控、更透明
排查历史问题	命令行 + 图形工具结合	效率最高

22.4 给新手的建议

如果你刚开始学 Git，不必纠结“必须全程命令行”还是“只能用图形界面”。

更稳的方式是：

1. 先在 IDEA / VS Code 里建立直觉。
2. 每做一次图形操作，顺手想一下它对应哪条 Git 命令。
3. 当你开始接触冲突、回滚、变基时，再重点补命令行。

这样学会更快，也更不容易在一开始被 Git 吓到。

---

23) 总结：Git 不只是命令行工具，更是一套协作方法

学 Git 的关键，不是把几十条命令都死记硬背，而是建立这几个认知：

• Git 在管理“变更历史”，不是单纯备份文件。
• 工作区、暂存区、本地仓库、远程仓库，这四层要分清。
• 分支是隔离风险、支持协作的核心能力。
• 公共历史要谨慎改写，团队里优先选择更稳的方式。
• 真正高水平的 Git 使用者，不是“命令背得多”，而是“出问题时知道怎么安全处理”。

如果你把这篇文章里的核心命令和概念真正练过一遍，已经足够应对大多数个人项目与团队开发场景。

---

参考资料

• Git 官方文档
• Pro Git（在线版）
• GitHub Docs