简介面向 Git 新手快速上手以及公司、学校内部培训场景这份 59 页 PPT 课件系统梳理了从版本控制概念到团队协作的完整路径。内容先讲清 Git 作为分布式版本控制系统的核心优势速度、简洁设计、非线性开发与本地安全再对比集中式 SVN 与分布式 Git 的差异以及 Git、GitHub、GitLab 三者的定位随后覆盖安装配置、工作区/暂存区/版本库原理并逐一演示初始化仓库、克隆、状态查看、文件比较、提交修改、回退版本、删除文件、远程操作、拉取合并、分支管理、分支保护、冲突解决、忽略文件等十余类开发常用命令还包含以 GitLab 为例的实操演练和可视化工具推荐。资源为单个 PPTX 文件压缩包仅 4.15MB培训讲师可直接修改单位名称后用于授课。已有 2050 人学习下载适合新人入职自学和讲师二次备课学完并跟着操作一遍即可基本掌握日常工作中常用的 Git 使用方法。1. 这份 Git 培训 PPT 有什么用新人三天上手与内训复用团队里来了个新同事第一天就往 master 上 push 了编译产物第二天又把别人的提交覆盖了。这不是个例几乎每个新人都要把 Git 的核心概念重新踩一遍。这套 Git 培训课程就是干这个的把 Git 介绍、集中式与分布式对比、安装配置、工作区原理、常用命令、分支合并到 .gitignore 全串成一条线新人跟着过一遍就能应对日常开发资深开发拿去给学校或公司做内训简单改一下单位名称就能直接讲。适合刚入职还没摸过 Git 的开发者、需要带新人的技术负责人以及准备做内部技术分享的讲师。2. 为什么是 Git 而不是 SVN集中式与分布式的本质差别2.1 集中式版本控制的痛点中央服务器一挂全组停摆SVN 是我们很熟悉的版本控制系统但它的模型有一个绕不开的问题版本库集中存放在中央服务器上所有提交和更新都依赖这台服务器。干活之前要先从中央服务器拉最新版本干完活再推回去。如果服务器宕机整个团队都没法提交如果网络状况不好传一个 5MB 的文件等上 20 分钟也是常有的事。我来公司之前所在的硬件组用的就是 SVN每周五下午服务器一崩整个组就进入聊天模式。后来换到 Git 之后至少提交代码这件事不再受网络和服务器状态牵制了。PPT 里用单点故障这个词很准确集中式架构的可用性完全押在中央服务器这一棵树上。2.2 分布式不是没有服务器本地就是完整仓库Git 的分布式模型解决的不只是网络问题。克隆一个远程仓库之后你本地拥有的不是一份工作副本而是一个完整的版本库——包含全部历史提交、全部分支、全部标签。提交代码时是推送到本地仓库完全不需要连接远程。这带来两个直接收益一是提交速度快不会有等待网络传输的焦虑二是安全冗余就算中央代码库的服务器彻底崩溃任一台开发机的本地库都能把整个项目还原出来。这一点 PPT 里有一句很关键的话任何代码的提交者都可以成为中央代码库。很多刚接触 Git 的人以为分布式就是没有服务端其实不是。Git 没有服务端和客户端的严格区分所谓服务端装的也是 Git只是约定俗成地把它当作中央仓库来用。真正的中央仓库崩溃了随便找一台 clone 过代码的机器就能顶上。2.3 快照机制为什么 Git 分支切换比 SVN 轻量SVN 记录的是文件差异每个版本存的是相对于上一个版本改了哪些行。Git 则完全不同每次提交保存的是整个文件系统的一次快照。这个设计让分支切换和合并变得极其轻量也是 Git 支持非线性开发模式的底层原因——可以同时保留几千个分支进行开发和切换每个分支就是一条指向快照的引用链。理解了快照模型很多 Git 行为就说得通了。比如切换分支为什么快因为本质上就是移动几个指针合并分支为什么经常能自动完成因为 Git 能通过快照找到两个分支的共同祖先算出真正需要合并的差异。这个原理 PPT 里没有展开讲但我在给新人讲课时一定会提因为它能解释后续遇到的大半玄学问题。2.4 Git、GitHub、GitLab 三者的定位怎么区分这三个名字在 PPT 里被反复对比也是新手最容易搞混的一组概念。一句话概括Git 是一种版本控制系统是工具GitHub 和 GitLab 都是基于 Git 实现的在线代码托管平台。GitHub 目前是全球最大的代码托管平台开源项目首选GitLab 更强调私有部署和权限控制常用于企业内部搭 Git 私服。维度GitGitHubGitLab定位分布式版本控制工具在线代码托管平台可私有部署的代码托管系统部署本地命令行工具云服务可部署到内网服务器开源项目-首选社区资源丰富也支持但更偏企业场景私有项目-私有仓库收费有门槛权限控制完善企业内部常用附加能力无wiki、Gist、协作图谱wiki、issue 跟踪、分支保护企业内部培训场景里PPT 以 GitLab 为例做开发场景演练是有道理的。GitHub 的很多协作流程在企业内网复制不了而 GitLab 自带完善的管理界面和权限控制更适合模拟真实的团队协作环境。3. 安装与配置三端安装、Git Bash 与用户信息设置3.1 Windows 安装官网下载、国内镜像与安装选项Git 官方支持 Linux/Unix、Solaris、Mac 和 Windows 平台。Windows 平台通常安装的是 Git for Windows也就是早期 msysGit 项目提供的安装包下载地址是 https://git-scm.com/downloads。官网下载速度不稳定的话可以用国内镜像https://npm.taobao.org/mirrors/git-for-windows/版本全速度快。安装过程中有一个选项值得单独提一下调整 PATH 环境变量的那一步建议选Git from the command line and also from 3rd-party software。这样 Git 的 exe 会被加入系统 PATHIDEA、VS Code 这类编辑器才能直接识别到 git.exe不然 IDE 里会出现 Cannot run program git 的报错。装完之后开始菜单会出现 Git 相关的几个入口日常使用最频繁的是 Git Bash它提供一个 Linux 风格的命令行窗口并且自带 ssh 客户端后面配置 SSH 密钥不需要额外装工具。装好后先验证一下版本git version能输出版本号就说明安装成功。另外git help可以打开命令帮助导航不记得某个命令的参数时先查它比上网搜快得多。3.2 Linux 与 Mac 安装包管理器一行搞定Linux 和 Mac 的安装相对简单用系统自带的包管理器就行# Debian / Ubuntu sudo apt-get update sudo apt-get install git -y # CentOS / RHEL sudo yum install git -y # macOS需先安装 Homebrew brew install git用包管理器装的版本可能不是官网最新版但对日常开发没有任何影响。我一般建议内网开发环境优先用系统包管理器的版本方便后续统一升级和维护如果在 Windows 上开发就跟着官网或者镜像的安装包走。安装完成后同样用git version验证。3.3 第一步配置user.name 与 user.email 必须设置Git 提交记录里的作者信息来自配置项不设置的话 commit 会报错或者提交后显示的是系统默认的乱码名字后续追责都找不到人。配置分全局和仓库两个级别# 全局配置对当前用户下的所有仓库生效 git config --global user.name 你的名字 git config --global user.email youcompany.com # 查看当前生效的全部配置 git config --list # 查看单项配置 git config user.name参数说明--global表示写入用户级配置文件Windows 下在C:\Users\你的用户名\.gitconfig不带这个参数则只写入当前仓库的.git/config。公司内部使用邮箱一定要用公司分配的邮箱否则提交记录关联不到企业账号GitLab/GitHub 的贡献图统计也会漏掉你。3.4 SSH 免密配置生成密钥并添加到 GitLab 或 GitHub远程操作有两种认证方式HTTPS 每次 push/pull 都要输账号密码SSH 只要配置一次公钥就行。Git for Windows 自带了 ssh 客户端直接在 Git Bash 里生成密钥# 生成密钥-t 指定算法-b 指定位数-C 填你的邮箱 ssh-keygen -t rsa -b 4096 -C youcompany.com # 一路回车默认保存到 ~/.ssh/id_rsa.pub # 查看公钥内容复制后粘贴到 GitLab/GitHub 的 SSH Keys 页面 cat ~/.ssh/id_rsa.pub新版 Git 默认也会生成id_ed25519密钥两者选一个用都行密钥位数越高越难被暴力破解。公钥粘贴到 GitLab 或 GitHub 的设置页面之后把克隆地址换成 SSH 格式形如gitgitlab.example.com:group/project.git以后再操作远程仓库就不需要输密码了。SSH 认证失败是出现频率最高的报错之一后面第 6 章的排查记录会专门讲。4. 工作区、暂存区、版本库理解 Git 核心模型与五条铁律4.1 三个区域的准确定义与 HEAD 的含义Git 的工作流程里有三块区域工作区就是你在电脑里能看到的目录你新建、修改文件都发生在这里暂存区也叫 stage 或 index存放在.git目录下的 index 文件中你可以把它理解为准备提交的候选区版本库则是工作区隐藏的.git目录本身里面装着 Git 的全部对象和引用。PPT 里有一张非常经典的区域关系图左侧是工作区右侧是版本库。版本库中标记为 index 的区域就是暂存区标记为 master 的是 master 分支所代表的目录树。HEAD 可以理解为指向当前分支的一个游标在绝大多数命令里出现 HEAD 的地方都可以直接用 master 替换。理解了 HEAD 是指针而不是一个真实存在的目录后面看git reset和git checkout的行为会清晰很多。版本库中的 objects 目录是 Git 的对象库每次git add时被修改的文件内容会写成一个新的对象存进.git/objects对象 ID 记录在暂存区的文件索引中。git commit时暂存区的目录树被写到版本库master 分支更新为指向这个新提交。4.2 文件流转add、commit、reset、checkout 各动了哪里这五个命令是理解 Git 模型的关键也是 PPT 里用区域图重点标注的一组操作。我把常见写法整理成一个代码块每个命令后面标注它影响的区域# 1. 工作区修改后加入暂存区 # 暂存区目录树更新文件内容写入对象库索引记录对象 ID git add src/main.py # 2. 提交把暂存区目录树写入版本库master 分支指向新提交 git commit -m fix: 修复登录接口空指针 # 3. 回退暂存区暂存区内容被 master 目录树替换工作区不受影响 git reset HEAD src/main.py # 4. 从暂存区删除文件保留工作区文件 git rm --cached src/test.py # 5. 用暂存区内容替换工作区文件工作区未暂存的改动全丢 git checkout -- src/main.py逻辑说明git add之后文件内容进入对象库但还没形成提交这时候反悔可以用git reset HEAD file把暂存区还原回 HEAD 的状态工作区保持原样。git rm --cached适合处理文件已经被跟踪但你想让它停止跟踪的情况比如后面要讲的 .gitignore 不生效问题。紧接着是 PPT 里强调的两个危险命令必须单独拎出来讲# 危险操作 1用暂存区全部文件替换工作区 # 后果工作区中未添加到暂存区的改动被清除不可恢复 git checkout . # 危险操作 2用 HEAD 指向的版本替换暂存区和工作区 # 后果连暂存区中未提交的改动一起丢比上一个更危险 git checkout HEAD .这两条命令清除的都是未提交的改动一旦执行工作区和暂存区的改动不会进入版本库Git 不会有任何记录可以找回。如果是刚写了大半天还没 commit 的代码手滑执行了git checkout .——这个场景我见过不止一次基本就是重写一遍的命运。4.3 diff 的三个比较维度工作区、暂存区、版本库很多新手搞不清git diff到底在比较什么其实三个区域两两组合就有三组差异命令比较对象典型用途git diff工作区 vs 暂存区看还没 add 的改动git diff --cached暂存区 vs 版本库HEAD看 add 了但还没 commit 的改动git diff HEAD工作区 vs 版本库HEAD看所有未提交的改动含已暂存第三个命令看到的相当于前两个的总和。我提交前的习惯是先用git diff扫一遍未暂存改动再用git diff --cached确认识别暂存的内容是不是自己想要的最后才 commit。参数--cached在新版本里也可以用--staged两者等价。4.4 最容易搞混的场景add 之后又改了文件commit 提交的是哪个版本这个场景几乎每个新手都会经历一次改完代码git add然后又改了一版忘记重新 add直接git commit。结果提交进版本库的是第一次 add 时的版本最新改动还躺工作区里。原因在于 commit 操作的输入是暂存区的目录树不是工作区。git add之后暂存区里存的是那个时刻的文件内容。之后文件再改动工作区内容和暂存区内容就不一致了git status会把文件同时列为 staged 和 unstaged 两行颜色都不一样。想提交最新版本必须重新git add一次。用脚后跟想也知道先 add 再改再 commit会把改动丢掉但实际开发里就是容易发生尤其是赶版本的时候。我现在的做法是 commit 之前一定git status看一眼staged 和 unstaged 同时出现的时候先停下来想清楚。5. 开发场景命令实战从 clone 到 merge 的完整命令链5.1 拿下一个仓库clone、init 与 remote 的关联进入新项目组的第一件事就是克隆仓库。git clone会把远程仓库完整复制到本地包含全部历史和分支之后的开发都在本地进行# SSH 方式克隆推荐 git clone gitgitlab.example.com:group/project.git cd project # HTTPS 方式克隆每次远程操作要输账号密码 git clone https://gitlab.example.com/group/project.git如果是自己从零开一个新项目用git init初始化再手动关联远程仓库git init git remote add origin gitgitlab.example.com:group/project.git git push -u origin master参数说明remote add给远程地址起名为 origin这是默认约定叫别的也行但没必要。-u参数把本地 master 和远程 master 关联起来第一次 push 带上它之后后续再 push 直接写git push就够了不用每次跟上远程名和分支名。5.2 日常提交链路status、diff、add、commit、push这是使用频率最高的五条命令直接决定每天的开发体验git status # 查看工作区和暂存区的状态 git diff # 查看未暂存的改动细节 git add . # 把当前目录所有改动加入暂存区 git commit -m feat: 用户模块新增导出功能 git push origin master # 推送到远程仓库 git log --oneline -5 # 查看最近 5 条提交记录注意git add .会把当前目录下所有未忽略的改动都加进去包括新生成的 IDE 配置文件、编译产物、日志文件等等。如果仓库还没配置好 .gitignore这一步就可能把不该提交的东西卷进来。我的习惯是先git status看一遍变更列表确认没有奇怪文件再决定用git add .还是精确git add 具体文件。提交信息的规范也值得提一下。PPT 里没有展开但团队协作中 commit message 是后面git log检索和代码审查的重要依据。常规项目一般用feat:、fix:、refactor:、docs:这类前缀做提交类型标注比如git commit -m fix: 修复登录接口空指针。手写不大规范的话也可以参考 Angular 的提交信息约定按团队习惯定就行。5.3 后悔药怎么选reset、revert 与 checkout 的边界Git 的后悔药有几种选错代价差别很大。先看git reset的三种模式和适用场景命令影响范围适用场景git reset --soft HEAD~1只回退提交记录保留暂存区和工作区提交后发现漏了文件想重新 commitgit reset HEAD~1默认 mixed回退提交并清空暂存区工作区保留提交信息写错了想重新 add 和 commitgit reset --hard HEAD~1提交、暂存区、工作区全部回退本地乱改一通彻底放弃实际踩坑记录里--hard是重灾区。它会把工作区的改动一并清掉而且不会留下任何痕迹。如果 commit 已经 push 到远程了不要用 reset 去删因为远程分支会被其他同事拉走历史改写会造成一堆冲突。正确做法是用git revert HEAD生成一个反向提交把这次的改动撤销掉同时保留原来的提交历史# 撤销最近一次提交生成一个新的反向提交 git revert HEAD # 或者指定撤销某个具体的提交 git revert abc123参数说明HEAD~1表示当前提交的父提交HEAD~2就是往前数两个提交。git revert后面跟的是要撤销的提交 ID。revert 和 reset 的选择标准很简单本地没推送过用 reset 随便玩已经推送了用 revert 做反向提交。5.4 拉取与合并fetch 与 pull 到底差在哪团队协作里每次开始干活前拉取最新代码是基本操作。这里要分清git fetch和git pull# fetch 只把远程更新下载到本地不改变工作区 git fetch origin # fetch 之后再手动合并 git merge origin/master # pull 等于 fetch merge一步到位 git pull origin master很多新人以为git pull是更新代码其实它的本质是先下载远程更新再把远程分支合并到当前分支。如果本地也有未提交的改动pull 就可能触发合并冲突。我一般建议本地有没提交的改动时先git commit保存现场或者git stash暂存起来再执行 pull。stash 的恢复命令是git stash pop这个组合在切换分支前处理改了一半不想丢的代码时非常实用。5.5 分支管理与合并从功能分支回到 master 的标准动作分支是 Git 最强的特性很多团队用 GitLab 的 Merge Request 流程做代码审查底层就是分支合并。基础操作如下# 创建并切换到新分支 git checkout -b feature-login # 在新分支上开发、提交不影响 master git add . git commit -m feat: 完成登录模块开发 # 切回 master拉取最新代码 git checkout master git pull origin master # 合并功能分支 git merge feature-login # 删除已合并的功能分支 git branch -d feature-login参数说明-b是创建并切换的组合参数等价于先git branch feature-login再git checkout feature-login。合并不一定每次都顺滑当 master 和功能分支改了同一个文件的同一段代码时Git 会停下来报告冲突。解决流程是先git status看哪些文件冲突打开文件找到、、标记的部分手工保留正确的代码并删掉标记然后git add这个文件最后 commit 完成合并。分支保护是 GitLab 场景里很关键的一个设置。在 GitLab 的项目设置里可以把 master 设成 Protected 分支普通开发者没有权限直接 push只能从功能分支发起 Merge Request由有权限的维护者审查后合并。这个机制 PPT 里提了一句但实际团队落地时非常有用——它强制所有代码变更至少被一个人看过才能进主干是低成本高收益的代码质量管理手段。6. 避坑与进阶.gitignore、可视化工具与高频排查记录6.1 五条高频踩坑记录现象原因解决执行git checkout -- file后刚写的代码全没了checkout 用暂存区替换了工作区未暂存改动被覆盖无法直接恢复唯一补救是看编辑器本地历史。先git stash再操作永远不要在有未提交改动时执行 checkout 覆盖git reset --hard后想找回之前的提交--hard 把提交记录指针回退了但对象库里的提交对象还在用git reflog查看操作历史找到丢失提交的 ID执行git reset --hard commit-id找回.gitignore 配了规则但文件还是被跟踪.gitignore 只对未跟踪文件生效已跟踪文件不受影响执行git rm --cached file停止跟踪重新 add 和 commitSSH 连远程仓库报 Permission denied公钥没添加到 GitLab/GitHub或 clone 用的地址不是 SSH 格式cat ~/.ssh/id_rsa.pub复制公钥粘贴到平台设置里的 SSH Keys确认克隆地址以git开头pull 时提示本地改动会被覆盖本地未提交的改动和远程更新冲突先git commit保存现场或git stash暂存改动pull 完再git stash pop恢复6.2 .gitignore从源头拦住不该提交的文件.gitignore 里写的是 Git 要忽略的文件规则。Java 项目的典型配置会忽略编译产物和 IDE 配置target/ *.class .idea/ *.iml *.log规则说明target/忽略目录*.class忽略所有以 .class 结尾的文件。配置之后新文件不再出现在git status里但已经跟踪过的文件不会自动停止跟踪要配合git rm -r --cached .清理索引后再重新提交。6.3 可视化工具与 IDE 集成命令行用的溜不代表要拒绝图形工具。SourceTree 和 TortoiseGit 是常见的 Windows 客户端SourceTree 适合看分支图谱和做交互式 rebaseTortoiseGit 直接集成在右键菜单里。用 IDEA 的话内置 Git 插件已经够用File→New→Project from Version Control粘贴仓库地址就能拉下项目右下角的分支菜单可以切换、合并底部的 Git 窗口能看 diff 和提交历史。图形工具的优点是 diff 可视化和误操作提示更友好但核心命令还是要懂因为 IDEA 的操作最终也是转换成命令执行的。从我用 Git 这几年踩过的坑来看纪律比技巧重要得多。以前我用git reset --hard用顺手了有一次在共享分支上执行完才发现把同事刚推的提交一起回退掉了最后靠git reflog才把提交捞回来。从那以后我每次 reset 前都强制自己先git stash留一个备份再操作完立刻验证reflog 确认无误才继续。这套流程多花不到一分钟但能救回大半天的工作量。希望帮到你。本文还有配套的精品资源点击获取