Git 基础：分支、提交、合并、回滚完整教程

文章目录

• • 前言
  • 一、先搞懂：Git到底是个啥？为啥程序员都离不开它？
  • 二、Git的核心骨架：三大区域与完整工作流
  • • [2.1 三大区域到底是什么？](#2.1 三大区域到底是什么？)
    • [2.2 Git最基础的完整工作流](#2.2 Git最基础的完整工作流)
  • 三、Git的核心操作：提交commit，你的代码时光机
  • • [3.1 commit到底是什么？](#3.1 commit到底是什么？)
    • [3.2 怎么写好commit message？别再写"更新"了！](#3.2 怎么写好commit message？别再写"更新"了！)
  • 四、分支branch：Git的灵魂，多人协作的核心
  • • [4.1 分支到底是什么？用大白话讲明白](#4.1 分支到底是什么？用大白话讲明白)
    • [4.2 分支的基础操作，看完就能上手](#4.2 分支的基础操作，看完就能上手)
    • • [1. 查看分支](#1. 查看分支)
      • [2. 创建分支](#2. 创建分支)
      • [3. 切换分支](#3. 切换分支)
      • [4. 删除分支](#4. 删除分支)
    • [4.3 2026年最通用的分支管理模型，团队协作必看](#4.3 2026年最通用的分支管理模型，团队协作必看)
  • 五、合并merge与变基rebase：把分支代码合到一起的两种方式
  • • [5.1 合并merge：最安全、最常用的合并方式](#5.1 合并merge：最安全、最常用的合并方式)
    • [5.2 变基rebase：让你的提交历史变成一条干净的直线](#5.2 变基rebase：让你的提交历史变成一条干净的直线)
    • [5.3 merge和rebase的区别，什么时候用哪个？](#5.3 merge和rebase的区别，什么时候用哪个？)
  • 六、回滚与撤销：Git的后悔药，代码写错了也不用慌
  • • [6.1 场景1：改了文件，还没git add到暂存区，想撤销修改](#6.1 场景1：改了文件，还没git add到暂存区，想撤销修改)
    • [6.2 场景2：已经git add到暂存区了，还没commit，想撤回暂存区](#6.2 场景2：已经git add到暂存区了，还没commit，想撤回暂存区)
    • [6.3 场景3：已经commit了，想撤销这次提交，回到上一个版本](#6.3 场景3：已经commit了，想撤销这次提交，回到上一个版本)
    • • [1. git reset：重置提交，直接"删除"指定版本之后的提交](#1. git reset：重置提交，直接"删除"指定版本之后的提交)
      • [2. git revert：反转提交，新建一个commit撤销之前的修改](#2. git revert：反转提交，新建一个commit撤销之前的修改)
      • [3. 核心红线：什么时候用reset，什么时候用revert？](#3. 核心红线：什么时候用reset，什么时候用revert？)
    • [6.4 救命神器：git reflog，哪怕你把代码删没了，都能找回来](#6.4 救命神器：git reflog，哪怕你把代码删没了，都能找回来)
  • 七、远程仓库与多人协作：GitHub/Gitee/GitLab实战
  • • [7.1 远程仓库的核心操作](#7.1 远程仓库的核心操作)
    • • [1. 关联本地仓库与远程仓库](#1. 关联本地仓库与远程仓库)
      • [2. 把本地代码推送到远程仓库](#2. 把本地代码推送到远程仓库)
      • [3. 把远程仓库的代码拉到本地](#3. 把远程仓库的代码拉到本地)
      • [4. 克隆远程仓库到本地](#4. 克隆远程仓库到本地)
    • [7.2 多人协作的标准流程，看完就能直接用](#7.2 多人协作的标准流程，看完就能直接用)
    • [7.3 代码冲突怎么办？别慌，3步就能解决](#7.3 代码冲突怎么办？别慌，3步就能解决)
    • • 冲突是怎么来的？
      • 怎么解决冲突？3步搞定
  • 八、2026年必学的Git进阶技巧，提升你的开发效率
  • • [8.1 git stash：临时暂存代码，不用再写一半代码硬切分支](#8.1 git stash：临时暂存代码，不用再写一半代码硬切分支)
    • [8.2 git cherry-pick：单独摘一个commit过来，不用合并整个分支](#8.2 git cherry-pick：单独摘一个commit过来，不用合并整个分支)
    • [8.3 git alias：给命令起别名，少打好多字](#8.3 git alias：给命令起别名，少打好多字)
    • [8.4 AI辅助Git工具：2026年的新玩法](#8.4 AI辅助Git工具：2026年的新玩法)
  • 九、最后说几句

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

兄弟们，先问个扎心的问题：你用Git的时候，是不是只会三板斧git add .、git commit -m "更新"、git push，一遇到代码冲突就头皮发麻，想回滚代码直接把文件删了重写，分支开得像蜘蛛网，最后自己都分不清哪个分支是干嘛的？

我在AI行业摸爬滚打了22年，带过不下百个实习生和初级开发，见过太多离谱的Git事故：有工作3年的后端，合并分支把同事半个月写的支付功能直接弄没了，最后在部门周会上公开社死道歉；有刚毕业的小伙子，线上出了紧急bug，直接在main分支上硬改，改到一半发现代码全乱了，只能哭着找我救场；还有更狠的，用了git reset --hard之后发现代码全没了，以为要卷铺盖走人，连离职申请都写好了。

说句实在话，2026年的今天，Git早就不是什么加分项了，而是程序员的基本功，就像你吃饭要用筷子、写字要用笔一样。不管你是写传统CRUD的后端、做页面的前端，还是搞AI智能体开发、大模型微调，只要你写代码，就离不开Git。智联招聘最新的数据显示，现在95%以上的技术岗招聘，不管是初级还是资深，"熟练使用Git进行版本控制与团队协作"都已经成了必填项，就像十年前你不会Spring Boot根本拿不到面试机会一样。

很多人说Git难，命令多，记不住，一用就踩坑。其实根本不是这样，Git的核心逻辑简单到离谱，只是很多教程上来就扔一堆命令和参数，把人直接劝退了。就像我教AI的时候，从来不会上来就给大家甩公式，而是用段子和生活化的类比把原理讲透，Git也是一样。今天这篇文章，我就用大白话，把Git从基础原理到实战操作，再到避坑指南，给大家讲得明明白白，哪怕你是刚学编程的高中生，都能看懂，看完就能直接上手用。

一、先搞懂：Git到底是个啥？为啥程序员都离不开它？

在讲命令之前，咱们先把Git的本质搞懂，不然你死记硬背再多命令，遇到点特殊情况还是会慌。

先给大家举个最接地气的例子：你大学写毕业论文的时候，是不是干过这事？

• 第一版写完，存个文件叫《毕业论文_初稿.doc》
• 改了几章，导师说不行，存个《毕业论文_修改版1.doc》
• 又改了半个月，导师说还是初稿好，存个《毕业论文_真最终版.doc》
• 临答辩前一天，导师让你加个案例，你怕改坏了，又复制一份《毕业论文_打死不改版.doc》
• 最后你的文件夹里，躺着十几个版本的论文，找的时候翻半天，想回到某一版的时候，根本记不清哪个文件对应哪个版本。

而Git，就是专门帮你管这些版本的"超级管家"。它不用你手动复制文件改名字，你每改完一版，只要给它说一声"我要存档了"，它就会自动给你存一个完整的版本，给这个版本编个唯一的编号，写好备注，以后你想回到任何一个版本，一秒钟就能切回去，哪怕是半年前的版本，都能丝毫不差地还原。

再举个例子，你和同学一起合写毕业论文，你写第三章，他写第四章，你们俩都基于初稿改。要是没有Git，你们只能互相发文件，他把他改的发给你，你复制粘贴到你的文档里，你改的再发给他，一不小心就会把对方的内容覆盖掉，最后越改越乱。而有了Git，你们俩可以同时改，改完之后一键合并，谁改了哪里、什么时候改的，清清楚楚，哪怕你们俩改了同一个地方，Git也会给你标出来，让你选留哪个，绝对不会出现内容丢失的情况。

这就是Git最核心的两个能力：版本控制 和多人协作。

这里还要给大家讲清楚，Git是分布式的版本控制系统，和之前的SVN这种集中式的完全不一样。还是用毕业论文举例子：

• 集中式版本控制（SVN）：就像你们的论文只有一份正本，放在导师的电脑里，你每次改都要联网去导师那把最新的论文下载下来，改完再联网传回去，断网了就啥也干不了，要是导师的电脑坏了，你的论文就全没了。
• 分布式版本控制（Git）：你们每个人的电脑里，都有这份论文的完整副本，包括所有的版本历史。你断网了也能随便改，随便存档，等联网了，再和大家同步你的修改就行。哪怕其中一个人的电脑坏了，随便找一个人的电脑，就能把完整的项目和所有版本都恢复回来。

这就是为什么Git能吊打所有其他版本控制工具，成为现在全世界程序员的标配。它不仅安全，而且灵活，速度还快，开分支、合并版本都是瞬间完成，零成本。

二、Git的核心骨架：三大区域与完整工作流

很多新手用Git踩坑，90%的原因都是没搞懂Git的三大区域，死记硬背命令，根本不知道每个命令执行之后，代码到底从哪到哪了。今天我就给大家把这个逻辑讲透，只要你搞懂了三大区域，Git的所有命令你都能一眼看懂，根本不用背。

还是用生活化的类比，咱们把写代码比作你开了一家蛋糕店，做蛋糕的流程，正好对应Git的三大区域：

2.1 三大区域到底是什么？

1. 工作区（Working Directory）

   就是你电脑里能看到的、正在写代码的文件夹，就像你蛋糕店的操作间。你在这里改代码、写新功能、删文件，所有的修改都发生在这里，你能直接看到，直接修改。

2. 暂存区（Stage / Index）

   就是你蛋糕店的"待打包窗口"。你做完了一款蛋糕，觉得没问题了，就先放到这个窗口里，等着一起打包发货，但还没正式交付。对应到Git里，就是你改完了几个文件，觉得这部分修改没问题了，先放到暂存区里，暂存区会记录你这次要存档的所有修改，但是还没正式生成一个永久版本。

3. 版本库（Repository）

   就是你蛋糕店的"成品仓库"。你把待打包窗口里的蛋糕，正式打包、贴好标签、写好生产日期，放到仓库里，永久保存起来，以后随时能找得到。对应到Git里，就是你把暂存区里的所有修改，正式提交到版本库，生成一个唯一的、永久的版本（commit），这个版本会永远存在，哪怕你之后把代码改崩了，也能从仓库里把这个版本拉出来，丝毫不差地还原。

2.2 Git最基础的完整工作流

搞懂了三大区域，Git最核心的工作流就非常清晰了，一共就4步，你每天写代码都在重复这个流程：

1. 在工作区写代码、修改文件：你在操作间里做蛋糕，改配方，加新口味。
2. 用git add命令，把修改的文件放到暂存区：你把做好的蛋糕，放到待打包窗口里，确认这次要交付的内容。
3. 用git commit命令，把暂存区的内容提交到版本库，生成一个永久版本：你把待打包窗口里的蛋糕，正式打包贴标签，放到成品仓库里，生成一个存档。
4. 用git push命令，把本地版本库的内容推送到远程仓库：你把仓库里的成品，发到全国的连锁门店，让你的同事都能拿到最新的版本。

就这么简单，没有任何花里胡哨的东西。

这里还要给大家讲一个新手最常问的问题：为什么要有暂存区？我直接把修改提交到版本库不行吗？

举个例子你就懂了：你今天改了两个东西，一个是修复了线上登录的bug，一个是开发了一半的首页新功能。这时候，线上突然催你，要把登录bug的修复马上发布上线，但是首页新功能还没写完，不能发布。

如果没有暂存区，你只能把首页新功能的代码删掉，提交登录bug的修复，发布完再把代码粘回来，非常麻烦。而有了暂存区，你只需要把登录bug修复的文件，用git add放到暂存区，然后commit提交，生成一个版本，直接发布就行。首页新功能的代码还安安稳稳地躺在工作区，一点不受影响，等你写完了再add commit就行。

这就是暂存区的意义：它让你可以灵活地控制，哪些修改要放到这次的提交里，哪些修改先不放，把不同的功能、不同的bug修复，分成不同的版本提交，以后出问题了，能精准地找到是哪个版本出的问题，精准回滚，而不是所有修改混在一起，一锅粥。

三、Git的核心操作：提交commit，你的代码时光机

搞懂了工作流，咱们就来讲Git最核心的操作：git commit。如果说Git是你的代码时光机，那每一个commit，就是时光机里的一个存档点，你以后随时能回到这个存档点。

3.1 commit到底是什么？

很多新手以为，commit只存了和上一个版本不一样的修改内容，其实不是。Git的每一个commit，都是你当前项目的完整快照，就像你玩游戏的时候，每次存档，游戏都会把你当前的等级、装备、任务进度，所有的状态全部存下来，而不是只存你和上次存档不一样的地方。

有人会问，那每次都存完整的项目，不会很占空间吗？放心，Git做了优化，对于没有修改的文件，Git只会保留一个指针，指向之前已经存过的文件，不会重复存储，所以既保证了快照的完整性，又控制了存储空间，速度还极快。

每个commit都有几个核心的属性：

• 唯一的commit哈希ID：一个40位的字符串，是这个commit的唯一身份证，一般用前7位就能精准定位到这个版本。
• 提交人：谁提交的这个版本，团队协作的时候，能清楚地知道谁改了什么。
• 提交时间：什么时候提交的，完整的时间线一目了然。
• 提交说明（commit message）：你写的备注，说明这个版本改了什么，这是commit的灵魂。
• 父commit：上一个版本的ID，Git就是靠这个，把所有的commit串成一条时间线，形成完整的版本历史。

3.2 怎么写好commit message？别再写"更新"了！

我见过太多程序员，commit message写得极其敷衍，要么是git commit -m "更新"，要么是"修改"，要么是"fix bug"，过一个礼拜自己都忘了这个commit改了啥，更别说你的同事了。等线上出了问题，想找哪个版本出的bug，翻几百个commit，全是"更新"，根本找不到，只能干瞪眼。

2026年了，不管是大厂还是创业公司，都有严格的commit message规范，今天我就给大家讲一个全世界通用的、最简单的规范，就是Angular团队的规范，只要你照着写，你的commit历史会干净得像艺术品，以后找版本、回滚、生成更新日志，都事半功倍。

这个规范的格式非常简单：

<type>(<scope>): <subject>

• type ：提交的类型，必填，告诉大家这个commit是干嘛的，只能用下面这几个固定值：
  • feat：新增功能，比如你加了一个支付功能，就用feat
  • fix：修复bug，比如你修复了登录倒计时的bug，就用fix
  • docs：文档修改，比如你改了README、接口文档，就用docs
  • style：代码格式修改，比如改了缩进、空格，不影响代码逻辑，就用style
  • refactor：代码重构，既没有新增功能，也没有修复bug，只是优化了代码结构，就用refactor
  • test：测试相关，比如加了单元测试、自动化测试，就用test
  • chore：构建工具、依赖包修改，比如升级了npm包、改了webpack配置，就用chore
• scope：修改的范围，可选，比如登录模块、首页、支付模块，告诉大家你改的是项目里的哪个部分。
• subject：提交的具体内容，必填，用简短的一句话，说清楚这个commit到底改了什么，不要太长，50个字以内最好。

给大家举几个反例和正例，一眼就能看懂：

• ❌ 反例：git commit -m "改了点东西"
• ❌ 反例：git commit -m "更新"
• ❌ 反例：git commit -m "fix bug"
• ✅ 正例：git commit -m "fix(登录): 修复手机号验证码60秒倒计时重置异常的bug"
• ✅ 正例：git commit -m "feat(支付): 新增微信支付回调验签与订单状态更新功能"
• ✅ 正例：git commit -m "docs: 更新README中的项目启动步骤与环境要求"

就这么简单，养成写规范commit message的习惯，你会回来感谢我的。我带团队的时候，只要有人commit message不规范，直接打回，不让合并，这是一个程序员最基本的职业素养。

四、分支branch：Git的灵魂，多人协作的核心

如果说commit是Git的核心，那分支就是Git的灵魂，也是Git能吊打其他版本控制工具的核心原因。很多新手对分支一知半解，不敢用，或者乱开分支，最后把自己绕晕了，今天我就给大家把分支讲透，其实它简单得离谱。

4.1 分支到底是什么？用大白话讲明白

还是用咱们写毕业论文的例子：你已经把毕业论文的正文写完了，存了一个最终版，这时候导师让你加一个案例分析，但是你又怕改坏了原来的正文，到时候导师又说不用加了，你改不回去。

这时候你会怎么做？肯定是把原来的最终版论文，复制一份，改个名字叫《毕业论文_案例补充版.doc》，然后在这个副本里随便改，随便折腾，哪怕改崩了，也不影响原来的最终版。等你把案例写好了，导师说没问题了，你再把案例内容复制到原来的最终版里，就完事了。

这个副本 ，就是Git里的分支 。而原来的那篇最终版论文，就是我们的主分支 ，一般叫main或者master。

你看，分支的本质就是这么简单：它就是你项目的一个独立副本，让你可以在不影响主分支稳定代码的前提下，随便开发新功能、改bug，等你开发完、测试没问题了，再把这个分支的内容合并回主分支就行。

这里要给大家讲一个Git最牛逼的地方：别的版本控制工具，开分支就是复制整个项目文件夹，项目大了，复制一次要等好几分钟，而Git的分支，只是一个指向某个commit的指针，开分支就是新建一个指针，瞬间完成，零成本，零等待。所以在Git里，我们鼓励大家随便开分支，随便玩，玩坏了直接删掉就行，一点负担都没有。

4.2 分支的基础操作，看完就能上手

分支的操作非常简单，核心就几个命令，2026年了，我给大家推荐用最新的、语义更清晰的命令，避免用老的checkout，因为它功能太多，新手很容易搞混。

1. 查看分支

# 查看本地所有分支，前面带*的就是你当前所在的分支
git branch

# 查看远程所有分支
git branch -r

# 查看本地+远程所有分支
git branch -a

2. 创建分支

# 基于当前分支，创建一个新的分支，注意：创建之后不会自动切换到新分支
git branch 分支名

# 示例：创建一个开发支付功能的分支
git branch feat/pay

这里给大家提个规范：分支名要见名知意，一般用类型/功能的格式，比如feat/pay是新增支付功能，fix/login-bug是修复登录的bug，hotfix/pay-crash是线上紧急修复支付崩溃的问题，别随便起个test1、aaa这种名字，过两天你自己都忘了这个分支是干嘛的。

3. 切换分支

# 切换到指定分支，2026年推荐用switch，语义清晰，专门用来切换分支
git switch 分支名

# 示例：切换到feat/pay分支
git switch feat/pay

# 快捷操作：创建分支并直接切换到该分支，最常用
git switch -c 分支名

# 示例：创建feat/user-center分支，并直接切换过去
git switch -c feat/user-center

4. 删除分支

# 删除已经合并完成的分支，安全删除，要是分支没合并，会提示你，不让你删
git branch -d 分支名

# 强制删除分支，不管有没有合并，直接删掉，慎用！
git branch -D 分支名

# 示例：删除已经合并完的feat/pay分支
git branch -d feat/pay

注意：你不能删除你当前所在的分支，比如你现在在feat/pay分支里，想删这个分支，必须先切换到别的分支，比如main分支，再执行删除命令。

4.3 2026年最通用的分支管理模型，团队协作必看

很多新手开分支很随意，今天在main分支上开发，明天在develop分支上改bug，后天又开了个不知道干嘛的分支，最后整个项目的分支乱成一锅粥，合并的时候全是冲突。

其实现在的互联网公司，尤其是AI创业团队，都不用复杂的原版Git Flow了，都用简化版的分支管理模型，既符合敏捷开发的节奏，又足够规范，不会乱，今天我就给大家讲这个模型，不管是个人开发还是团队协作，都能用。

这个模型一共就5种分支，分工明确，边界清晰：

1. main分支：线上环境分支，核心红线：永远保持可发布、稳定的状态，绝对不能直接在main分支上写代码，所有的修改都必须通过其他分支合并过来。这个分支的代码，就是线上正在跑的代码，哪天线上炸了，直接从main分支拉代码排查，绝对不会有半成品代码混在里面。
2. develop分支：开发分支，所有的功能开发都基于这个分支，测试没问题的代码，先合并到这个分支，等要发布上线的时候，再把develop分支合并到main分支。
3. feat/xxx分支：功能分支，从develop分支拉出来，专门用来开发某个新功能，开发完、测试没问题之后，合并回develop分支，然后删掉这个分支。比如你要开发用户中心功能，就从develop拉一个feat/user-center分支，开发完合并回去。
4. fix/xxx分支：bug修复分支，从develop分支拉出来，专门用来修复测试环境的bug，修复完合并回develop分支，然后删掉。
5. hotfix/xxx分支：紧急线上bug修复分支，线上出了紧急bug，必须马上修复的时候，从main分支拉出来，修复完、测试没问题之后，同时合并回main分支和develop分支，确保线上和开发环境的代码都修复了，然后删掉这个分支。

我给大家举个完整的开发流程，一眼就能看懂：

1. 项目初始化，创建main分支和develop分支，两个分支代码完全一致。
2. 你要开发一个支付功能，从develop分支拉一个feat/pay分支，在这个分支里开发，随便commit，随便改，不影响任何其他分支。
3. 支付功能开发完了，你把develop分支的最新代码合并到feat/pay分支，解决冲突，测试没问题。
4. 提交合并请求，让同事帮你code review，没问题之后，把feat/pay分支合并到develop分支，删掉feat/pay分支。
5. 这个版本的所有功能都开发完了，测试没问题，把develop分支合并到main分支，给main分支打个版本标签，发布上线。
6. 上线之后，发现支付有个bug，导致用户付了钱，订单状态没更新，紧急从main分支拉一个hotfix/pay-order-bug分支，修复bug。
7. 修复完测试没问题，把hotfix分支同时合并回main分支和develop分支，发布上线，删掉hotfix分支。

就这么简单，整个流程非常清晰，不会乱，也不会出现线上代码混进半成品的情况。我带过的团队，都是用这个模型，从来没出过分支管理的乱子。

这里给大家提一个红线：绝对不要直接在main分支上开发代码！ 我见过太多新手，图省事，直接在main分支上写代码，改到一半，线上出bug了，他的main分支已经被改得面目全非，根本没法基于线上代码修复bug，只能手忙脚乱回滚，最后社死现场。

五、合并merge与变基rebase：把分支代码合到一起的两种方式

你开发完了功能，要把分支的代码合并回主分支，这里有两种方式：merge和rebase。这也是新手的重灾区，很多人搞不懂它俩的区别，一合并就出冲突，然后乱搞，把提交历史弄得乱七八糟。今天我就用大白话，给大家讲清楚它俩的区别，什么时候用哪个，还有绝对不能踩的红线。

5.1 合并merge：最安全、最常用的合并方式

先讲merge，这是最常用、最安全的合并方式，新手先把merge用熟，再去碰rebase。

还是用毕业论文的例子：你从正文的最终版，复制了一个副本写案例，在你写案例的这段时间，你的同学也在正文的最终版里，修改了摘要和参考文献。现在你把案例写完了，要把你的副本和正文合并到一起。

merge做的事情，就是找三个关键点：

1. 你的副本的最新版本（你的feat分支的最新commit）
2. 正文的最新版本（main分支的最新commit）
3. 你们俩的共同祖先（你当初复制副本的时候，那个正文的最终版commit）

然后Git会自动把你们俩的修改，合并到一起，生成一个新的合并commit，这个commit会保留你们俩所有的修改，也会保留完整的提交历史，清楚地记录了什么时候开了分支，什么时候合并了分支。

merge分两种情况，非常好理解：

1. 快进合并（Fast-Forward）

   你从main分支开了feat分支，在feat分支改了东西，这期间main分支一点没动，没有任何新的提交。这时候合并，Git发现，main分支的最新commit，就是你feat分支的共同祖先，所以它直接把main分支的指针，移到feat分支的最新commit就行，就像看视频快进一样，不会生成新的合并commit，整个提交历史是一条直线。

   这种情况一般出现在你个人开发，没有其他人改main分支的代码的时候。

2. 三方合并

   你开了feat分支之后，main分支也有了新的提交，这时候Git没法快进了，就会执行三方合并，自动把两个分支的修改合并起来，生成一个新的合并commit，提交历史里会清楚地记录，这里有一次分支合并。

   这种情况是团队协作里最常见的，因为你开发功能的时候，肯定有其他同事也在合并代码到main分支。

merge的命令非常简单：

# 先切换到要合并到的目标分支，比如你要把feat/pay合并到develop分支，先切到develop
git switch develop

# 执行merge命令，把feat/pay分支的内容合并到当前的develop分支
git merge feat/pay

就这么两步，非常简单。如果合并的时候没有冲突，Git会自动完成合并，如果有冲突，Git会告诉你哪些文件有冲突，你手动解决完冲突，再add commit就行，冲突的解决方法，我后面会专门讲。

5.2 变基rebase：让你的提交历史变成一条干净的直线

很多新手一听rebase就怕，觉得它很复杂，很危险，其实它的原理非常简单，只是大家没给它讲明白。

还是用坐高铁的例子，给大家讲清楚rebase到底干了啥：

你从北京西站（两个分支的共同祖先commit）上了高铁，坐了两站，提交了两个commit（你的feat分支的两个版本）。这时候你发现，你坐的这趟高铁，起点已经从北京西站，延伸到了石家庄（main分支有了新的提交，往前推进了）。

而rebase（变基）做的事情，就是把你的上车点（分支的基准），从北京西站，改到石家庄，然后把你坐的两站（你的两个commit），重新接在石家庄的后面。

这样一来，整个高铁线路，就变成了一条完整的直线，没有分叉，非常干净，看不到你曾经开过分支，也看不到合并的记录，就像你一直是在最新的main分支上，依次提交了这些commit一样。

rebase的命令也很简单：

# 先切换到你的功能分支，比如feat/pay
git switch feat/pay

# 执行rebase命令，把你的分支的基准，变到develop分支的最新版本
git rebase develop

执行完之后，你的feat分支的提交，就全部接在了develop分支最新commit的后面，提交历史是一条完美的直线。这时候你再切换到develop分支，执行merge feat/pay，就会直接触发快进合并，连合并commit都不会生成，整个历史非常干净。

5.3 merge和rebase的区别，什么时候用哪个？

给大家整理了一个最简单的对比，一眼就能看懂：

特性	merge	rebase
提交历史	保留完整的分支历史，有分叉，能清楚看到什么时候开了分支，什么时候合并了	重写提交历史，把分叉变成一条直线，看不到分支的痕迹
操作风险	极低，不会修改已有的提交历史，非常安全	有风险，会修改提交历史，用错了会出大问题
适用场景	团队协作中，合并公共分支的代码，保留完整历史	个人私有功能分支，整理自己的提交历史，让历史更干净

这里给大家划一条绝对不能碰的红线 ，我见过太多人踩这个坑，出了严重的事故：
绝对不要在公共分支（比如main、develop）上执行rebase！只能在你自己的私有功能分支上执行rebase！

为什么？因为rebase会重写提交历史，你在公共分支上执行了rebase，就会把公共分支的提交历史改了，而你的同事本地的公共分支，还是原来的历史，这时候他们拉代码的时候，就会出现严重的冲突，整个团队的提交历史全乱了，最后要花好几个小时才能恢复。

我见过最惨烈的一次，一个新手在main分支上执行了rebase，然后强制push到了远程，整个团队20多个人，本地的main分支全和远程对不上了，所有人的代码都没法提交，最后整个团队花了一下午才恢复，那个新手当天就请全团队喝了奶茶，还写了全公司通报的事故报告。

所以给新手的建议：先把merge用熟，团队协作的时候，优先用merge，安全第一。等你完全搞懂了Git的原理，再在自己的私有分支上用rebase，整理提交历史。

六、回滚与撤销：Git的后悔药，代码写错了也不用慌

写代码，谁都有写错的时候，改崩了、提交错了、合并错了，都是常有的事。很多新手一遇到这种情况，就慌了，直接删文件、重装项目，其实Git给我们准备了全套的后悔药，不管你改到哪一步，都能撤回来，哪怕你把代码全删了，都能找回来。

今天我就按场景给大家讲，不同的情况，用什么命令，怎么撤销，看完之后，你再也不用怕写错代码了。

6.1 场景1：改了文件，还没git add到暂存区，想撤销修改

这个是最常见的情况：你改了代码，还没执行git add，发现改崩了，想回到和版本库一模一样的状态，就当没改过这个文件。

这时候用git restore命令，2026年推荐用这个，语义清晰，专门用来撤销工作区的修改：

# 撤销单个文件的修改，回到和版本库一模一样的状态
git restore 文件名

# 示例：撤销login.js文件的修改
git restore src/login.js

# 撤销当前目录所有文件的修改，慎用！会把你所有没add的修改全撤掉
git restore .

这个操作，就像你改了Word文档，没保存，直接关闭不保存，回到原来的样子，非常简单。

6.2 场景2：已经git add到暂存区了，还没commit，想撤回暂存区

你已经执行了git add，把文件放到了暂存区，但是还没commit，发现改的不对，想把暂存区的内容撤回到工作区，不修改你已经改好的代码，只是把它从暂存区里拿出来。

这时候还是用git restore命令，加个--staged参数：

# 把单个文件从暂存区撤回，回到工作区，代码修改不会丢
git restore --staged 文件名

# 示例：把login.js从暂存区撤回
git restore --staged src/login.js

# 把当前目录所有文件从暂存区撤回
git restore --staged .

这个操作，就像你把蛋糕放到了待打包窗口，现在又拿出来，回到操作间，继续修改，待打包窗口里没了，但是你已经做好的蛋糕还在，一点没动。

6.3 场景3：已经commit了，想撤销这次提交，回到上一个版本

这个是新手最常遇到的情况：已经提交了commit，发现写错了，想回滚到上一个版本。这里有两个命令：git reset和git revert，很多人搞混，今天我给大家讲清楚，什么时候用哪个。

1. git reset：重置提交，直接"删除"指定版本之后的提交

git reset就像你玩游戏，存了个档，发现这个存档里你选错了选项，想回到上一个存档，把这个存档直接删掉，就当没存过。它会把HEAD指针，移到你指定的commit，之后的提交就"消失"了。

git reset有三个模式，对应不同的场景，大家一定要记清楚：

• --soft 软重置 ：只重置commit，暂存区和工作区的代码完全保留。

  适用场景：你刚commit完，发现commit message写错了，或者漏add了一个文件，想重新commit。

  # 回到上一个commit，代码一点不动，只是撤销了这次commit
  git reset --soft HEAD~1

  执行完之后，你这次commit的内容，会全部回到暂存区，你可以修改commit message，或者补加文件，重新commit就行。

• --mixed 混合重置（默认模式） ：重置commit和暂存区，工作区的代码保留。

  适用场景：你commit了之后，发现这次提交的代码有问题，想撤回到工作区，重新修改，重新提交。这是默认模式，不加参数就是--mixed。

  # 回到上一个commit，暂存区清空，代码还在工作区，你可以重新修改
  git reset HEAD~1

• --hard 硬重置 ：强制重置，commit、暂存区、工作区全部回到指定版本，之后的所有修改全部删掉。

  适用场景：你改崩了，想完全回到某个指定的版本，之后的修改全不要了，一键还原。这个命令慎用！

  # 强制回到上一个commit，所有之后的修改全部删掉，无法恢复
  git reset --hard HEAD~1
  
  # 强制回到指定commit id的版本，commit id只需要前7位就行
  git reset --hard a1b2c3d

2. git revert：反转提交，新建一个commit撤销之前的修改

git revert和git reset完全不一样，它不会删除任何提交历史，而是会新建一个新的commit，把你要撤销的那个commit的修改，全部反向改回来。比如你之前的commit是把A改成了B，revert就会把B改回A，原来的提交历史完全保留，清清楚楚地记录了，你什么时候提交了什么，什么时候撤销了这个提交。

命令非常简单：

# 反转指定的commit，生成一个新的commit，撤销这个commit的修改
git revert commit_id

# 示例：反转id为a1b2c3d的commit
git revert a1b2c3d

3. 核心红线：什么时候用reset，什么时候用revert？

这里给大家划一条绝对不能乱的红线，很多人踩坑就是因为搞反了：

• 如果你的commit还没push到远程仓库，只有你自己本地有，用reset，没问题，因为不会影响任何人。
• 如果你的commit已经push到远程公共仓库了，所有人都能拉到，绝对不要用reset！必须用git revert！

为什么？因为你用reset把本地的commit删了，但是远程仓库里还有这个commit，你要是强制push，就会把远程的提交历史改了，你的同事拉代码的时候，就会出现严重的冲突，整个团队的历史全乱了，和之前rebase的坑一模一样。

而git revert是新建一个commit，不会修改原来的历史，你push到远程之后，所有人拉代码，都会正常合并，不会有任何问题，安全第一。

6.4 救命神器：git reflog，哪怕你把代码删没了，都能找回来

很多新手用了git reset --hard之后，发现代码没了，以为找不回来了，哭着来找我，以为要丢工作了。其实完全不用慌，Git有一个救命神器：git reflog。

git reflog会记录你所有的Git操作记录，包括你切换分支、reset、commit、rebase，所有的操作，哪怕你reset了，哪怕你删了分支，都能在这里找到对应的commit id，然后再reset回去，就能把代码恢复回来。

用法非常简单：

# 查看所有的Git操作记录
git reflog

执行之后，你会看到所有的操作记录，每一条都有对应的commit id，你找到你想回到的那个操作的commit id，然后执行git reset --hard commit_id，就能一键恢复，哪怕你把天捅破了，它都能给你补回来。

我从业22年，用这个命令救过无数新手的代码，也救过我自己好几次，这个命令，你一定要记下来，关键时刻能救命。

七、远程仓库与多人协作：GitHub/Gitee/GitLab实战

前面讲的都是本地Git的操作，但是我们工作中，都是团队协作，这就需要远程仓库了。常用的远程仓库平台有GitHub、Gitee、GitLab，用法都是一样的，今天我就给大家讲清楚，远程仓库的核心操作，还有多人协作的标准流程。

7.1 远程仓库的核心操作

远程仓库，就是一个放在云端的共享仓库，你本地的代码可以推上去，你的同事可以从上面拉下来，大家一起同步代码。核心操作就几个，非常简单：

1. 关联本地仓库与远程仓库

你在本地创建了一个项目，写了代码，提交了commit，现在要把它放到远程仓库里，先在远程平台创建一个空仓库，然后执行下面的命令：

# 把本地仓库和远程仓库关联起来，origin是远程仓库的别名，默认都叫origin
git remote add origin 远程仓库地址

# 示例：关联Gitee上的仓库
git remote add origin https://gitee.com/xxx/xxx.git

2. 把本地代码推送到远程仓库

# 把本地的main分支推送到远程origin仓库的main分支，-u是设置上游分支，之后push不用再加origin main了
git push -u origin main

# 之后再推送，直接执行就行
git push

# 推送指定分支到远程
git push origin 分支名

3. 把远程仓库的代码拉到本地

# 把远程仓库的最新代码，拉到本地，自动合并到当前分支
git pull

# 拉取远程指定分支的代码，合并到当前分支
git pull origin 分支名

注意：git pull其实是两个命令的组合，git fetch（拉取远程的最新代码，不合并） + git merge（把拉取的代码合并到当前分支）。

4. 克隆远程仓库到本地

看到别人的开源项目，想下载到本地，或者你换了电脑，要把自己的远程仓库克隆下来，用clone命令：

# 把远程仓库完整克隆到本地，包括所有分支、所有提交历史
git clone 远程仓库地址

# 示例：克隆Vue的官方仓库
git clone https://github.com/vuejs/vue.git

7.2 多人协作的标准流程，看完就能直接用

很多新手刚进团队，不知道怎么和同事协作，一push就冲突，一合并就乱，今天我给大家一个2026年互联网公司通用的多人协作标准流程，你照着这个流程走，绝对不会出问题：

1. 先拉取最新代码 ：每天上班第一件事，切换到develop分支，执行git pull，把远程develop分支的最新代码拉到本地，确保你的本地代码是最新的。
2. 创建自己的功能分支 ：从develop分支，拉一个你自己的功能分支，比如feat/pay，绝对不要直接在develop分支上开发。
3. 本地开发，频繁commit：在自己的分支上开发，每完成一个小功能，就commit一次，写好commit message，不要攒一大堆修改才commit，不然出了问题都找不到哪里错了。
4. 开发完，先拉取最新代码，解决冲突 ：开发完了，先切换到develop分支，执行git pull，拉取最新的develop代码，再切换回你的功能分支，执行git merge develop，把最新的develop代码合并到你的分支，手动解决冲突，确保你的分支能和最新的develop代码完美合并。
5. 测试没问题，推送到远程 ：解决完冲突，本地测试没问题，执行git push origin 你的分支名，把你的分支推送到远程仓库。
6. 提交合并请求，code review：在远程平台，提交Pull Request（PR）/ Merge Request（MR），把你的分支合并到develop分支，让你的同事帮你code review，检查代码有没有问题。
7. 合并完成，删除分支：code review通过，合并到develop分支之后，把远程的功能分支和本地的功能分支都删掉，保持仓库干净。

就这么7步，非常清晰，照着做，绝对不会出现协作乱子，也不会出现莫名其妙的冲突。

7.3 代码冲突怎么办？别慌，3步就能解决

很多新手一看到代码冲突，就头皮发麻，不知道怎么办。其实冲突非常简单，根本不用慌，今天我给大家讲清楚，冲突是怎么来的，怎么解决。

冲突是怎么来的？

冲突的本质非常简单：Git自动合并的时候，发现同一个文件的同一个位置，你和你的同事改了不一样的内容，Git不知道该保留哪个，就会标出来，让你手动选择，这就是冲突。

举个例子：你在login.js里，把登录按钮的文字改成了"立即登录"，你的同事在另一个分支里，把同一个位置的文字改成了"登录"，合并的时候，Git就不知道该用哪个，就会产生冲突。

怎么解决冲突？3步搞定

1. 找到冲突的文件 ：合并的时候，Git会告诉你哪些文件有冲突，比如Auto-merging src/login.js\nCONFLICT (content): Merge conflict in src/login.js，就是login.js这个文件有冲突。

2. 打开文件，手动解决冲突 ：打开冲突的文件，你会看到Git给你标出来的冲突内容，格式是这样的：

   <<<<<<< HEAD
   <button>立即登录</button>
   =======
   <button>登录</button>
   >>>>>>> feat/pay

   • <<<<<<< HEAD 到 ======= 之间的内容，是你当前分支的代码
   • ======= 到 >>>>>>> feat/pay 之间的内容，是你要合并的分支的代码
     你只要把这些标记（<<<<<<<、=======、>>>>>>>）全部删掉，留下你想要的内容就行。比如你想保留"立即登录"，就改成：

   <button>立即登录</button>

   要是你想两个都不要，改成"确认登录"，就改成：

   <button>确认登录</button>

   就这么简单，所有的冲突文件都这么处理就行。

3. 处理完冲突，提交合并 ：所有冲突文件都处理完了，执行git add 冲突文件名，把处理完的文件放到暂存区，然后执行git commit，完成合并，冲突就解决了。

真的，冲突一点都不可怕，很多新手就是看到那些标记就慌了，其实只要你静下心来，看看两边的代码，选你想要的就行，1分钟就能搞定。

八、2026年必学的Git进阶技巧，提升你的开发效率

前面讲的都是基础操作，足够你应对90%的工作场景了，这里再给大家讲几个2026年常用的进阶技巧，能大幅提升你的开发效率，让你的同事都觉得你是Git大神。

8.1 git stash：临时暂存代码，不用再写一半代码硬切分支

这个技巧太实用了，几乎每天都能用到。场景：你正在开发新功能，代码写了一半，还不想commit，这时候线上突然出了个紧急bug，让你马上切分支修复，这时候你怎么办？

很多新手会把写了一半的代码删掉，或者复制到别的地方，切分支改bug，改完再粘回来，非常麻烦。这时候用git stash，一键就能解决。

git stash会把你当前工作区和暂存区的修改，临时暂存起来，让你的工作区变得干干净净，和版本库一模一样，你就可以放心切分支改bug了。等你改完bug，切回来，再把暂存的内容恢复出来就行。

核心命令：

# 临时暂存当前的所有修改
git stash

# 暂存的时候，加个备注，方便以后找
git stash push -m "写了一半的支付功能，待完善回调逻辑"

# 查看所有暂存的记录
git stash list

# 恢复最新的暂存内容，恢复之后会把这条暂存记录删掉
git stash pop

# 恢复指定的暂存记录，比如恢复第一条，stash@{0}就是第一条
git stash pop stash@{0}

# 恢复暂存内容，但是不删掉暂存记录，想多次恢复的时候用
git stash apply

# 删除最新的暂存记录
git stash drop

# 删除所有暂存记录
git stash clear

这个命令，真的是开发神器，谁用谁知道。

8.2 git cherry-pick：单独摘一个commit过来，不用合并整个分支

场景：你在feat分支开发了一个大功能，里面有一个commit，修复了一个通用的线上bug，现在你想把这个bug修复，直接合并到main分支，但是不想合并整个feat分支，因为功能还没开发完。

这时候用git cherry-pick，就能把指定的commit，单独摘出来，合并到当前分支，非常灵活。

命令非常简单：

# 把指定的commit，摘到当前分支，生成一个新的commit
git cherry-pick commit_id

# 示例：把id为a1b2c3d的commit，摘到当前分支
git cherry-pick a1b2c3d

# 连续摘多个commit，从commit1到commit2，注意是左开右闭，要包含commit1的话，用commit1^
git cherry-pick commit1^..commit2

8.3 git alias：给命令起别名，少打好多字

Git的很多命令，都很长，每次敲都很麻烦，你可以给它们起别名，比如把git checkout改成git co，把git commit改成git cm，每次敲命令，少打好多字，效率直接翻倍。

配置方法：

# 给git switch起别名git sw
git config --global alias.sw switch

# 给git commit起别名git cm
git config --global alias.cm "commit -m"

# 给git status起别名git st
git config --global alias.st status

# 给git branch起别名git br
git config --global alias.br branch

# 给git checkout起别名git co
git config --global alias.co checkout

# 给git log起别名git lg，显示漂亮的提交历史
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

配置完之后，你就可以直接用别名了，比如git st就是查看状态，git cm "fix: 修复bug"就是提交代码，git lg就能看到非常漂亮的、带图形的提交历史，一眼就能看清分支的合并情况。

8.4 AI辅助Git工具：2026年的新玩法

2026年了，AI已经全面渗透到开发的各个环节，Git也不例外。现在很多AI工具，都能帮你搞定Git的各种操作：

• 自动生成规范的commit message：比如GitHub Copilot、文心一言代码助手，你只要改完代码，它就能根据你的修改，自动生成符合规范的commit message，不用你自己想。
• 自动解决代码冲突：AI能自动分析冲突的两边代码，给出最优的解决建议，甚至一键帮你解决冲突，不用你手动改。
• 自然语言执行Git命令：你不用记命令，只要给AI说一句"帮我把刚才的提交回滚，保留工作区的代码"，它就能自动生成对应的命令，甚至直接帮你执行。
• 自动分析提交历史，找出bug引入的版本：AI能帮你分析提交历史，找出哪个commit引入了bug，帮你快速定位问题。

这里要给大家提个醒：AI生成的命令，尤其是git reset --hard、git rebase这种危险命令，一定要先看懂，确认没问题再执行，不要直接复制粘贴，不然很容易出事故。AI是辅助工具，最终还是要你自己把控。

九、最后说几句

兄弟们，Git真的不是什么高深的技术，它就是一个帮你管理代码、和团队协作的工具，就像你用Word的撤销、保存功能一样，不用死记硬背命令，只要你搞懂了它的核心原理，知道每个命令是干嘛的，对应什么场景，用多了自然就熟了。

2026年的今天，大模型、AI智能体发展得飞快，很多人说程序员要被AI替代了，但是我想说，AI只是工具，能用好工具的程序员，永远不会被替代。而Git，就是你作为程序员，必须掌握的最基础的工具，不管你是做传统开发，还是做AI大模型应用开发，都离不开它。

我在AI行业摸爬滚打了22年，见过太多程序员，技术不错，但是连Git都用不明白，一协作就出问题，白白错失了很多机会。真的，花几个小时，把Git的基础操作搞懂，把这篇文章收藏起来，遇到问题翻一翻，绝对能让你少走很多弯路。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。