简介这是一份面向Git新手与内部培训讲师的完整教学PPT总计59页根据多年实战与授课经验整理浓缩了团队开发中最常使用的Git知识与操作场景。内容从集中式与分布式版本控制的对比切入清晰讲解Git工作区、暂存区、版本库原理并覆盖安装配置、克隆项目、提交修改、版本回退、分支管理与合并冲突处理等高频命令同时给出GitHub与GitLab的差异说明、可视化工具推荐以及基于GitLab的完整开发场景演练。资源包为单个pptx文件大小4.15MB讲师可直接用于公司或学校培训简单修改单位名称即可授课学员也可按章节自学实操。跟随课程操作一遍即可基本掌握从初始化仓库到远程协作的完整能力有效减少团队协作中的代码管理混乱。已有2050人学习下载适合希望快速上手Git、沉淀内部培训课程的开发团队与个人。1. 被 Git 支配的新人第一天一份培训课件能省下的沟通成本新同事入职第一天mentor 甩过来一行git clone他盯着终端愣了三秒问“Git 和 GitHub 不是一个东西吗”这个场景我见过太多次。Git 是每个开发者的基本功但能把 Git 讲清楚的人不多——分布式和集中式的区别、暂存区到底是干嘛的、为什么 merge 会冲突书里都有可真到用的时候全是坑。这篇要拆的是一份 Git 介绍与使用培训课件覆盖从 Git 概念、安装配置到 GitLab 开发场景演练的完整链路适合两类人一类是刚入职想快速上手 Git 的新手另一类是要给部门或学校做内部培训、需要现成课程改改就能用的讲师。课件的实际内容我按自己带新人的经验重新梳理了一遍照着这篇走第一周就能独立处理 clone、commit、分支合并这些日常操作。2. 集中式与分布式先弄懂 Git 为什么快再学命令才有底2.1 集中式的死穴中央服务器一挂全组停工课件里先讲了 SVN 这类集中式版本控制系统的典型流程早上到公司先从中央服务器 checkout 最新代码在自己电脑上改改完 commit 回中央服务器。听起来顺理成章但这里有个致命问题——所有操作都依赖那台中央服务器。网络慢的时候提交一个大文件要等半天服务器磁盘满了或者宕机了全组人连历史版本都查不了只能干等运维恢复。课件里举了个很形象的例子提交 5MB 的代码要等 20 分钟。这个场景在老牌集中式系统里一点都不夸张因为每次提交都得把差异传到服务器服务器再算一次版本库状态网络往返加服务端计算慢是常态。而单点故障更是集中式的死穴中央服务器的磁盘一旦损坏又没有及时备份整个项目的提交历史可能就全没了。这个对比值得反复讲给新人听集中式把版本库当唯一真相分布式把版本库复制到每个人本地。理解了这一层后面学git clone、git push、git pull的时候就会知道这些命令的本质是本地库和远程库之间的同步而不是“上传下载”。2.2 分布式把版本库复制到本地快照带来的三个红利Git 的设计思路和集中式完全不同。每个开发者的git clone拿到的不是一个工作副本而是远程仓库的完整镜像包含全部提交历史、全部分支、全部标签。本地就是一份完整的版本库日常的 add、commit、log、branch 操作全部在本地完成不消耗任何网络资源。课件里提到一个关键词叫“快照”。Git 每次提交保存的不是文件差异而是整个文件系统的一次快照Git 内部会用高效的方式存储这些快照。带来的直接好处有三个。第一速度本地操作没有网络开销commit、diff、log 都是毫秒级响应。第二安全任何一台机器的本地库都是完整备份中央服务器挂了随便找一台本地库就能还原不存在“所有鸡蛋在一个篮子里”的问题。第三分支成本极低在 Git 里创建分支只是创建一个指针几十个分支同时开发、切换、合并都是常态这也就是课件里说的“对非线性开发模式的强力支持”。这个设计还有一个容易被忽略的推论既然每个人的本地都是完整版本库那任何人的本地库都可以成为新的“中央库”。Git 并没有严格的服务端和客户端之分所谓的 Git 服务器上装的也是同一个 Git只是多配置了一些权限和钩子。这个思想是理解 GitLab、GitHub 工作原理的基础。2.3 Git、GitHub、GitLab 的分工工具、平台、私服这三个名词是新人最容易混的课件里专门做了区分。Git 是一个版本控制工具装在你电脑上和多语言运行时一样是一个软件。GitHub 是基于 Git 的在线代码托管平台也是目前全球最大的开源社区Spring、MyBatis、React、Vue 这些知名项目的源码都托管在上面。GitLab 则是开源的仓库管理软件你可以拿它在自己公司的内网搭一个类似 GitHub 的服务。从代码私有性角度说GitLab 更适合企业内部用它提供了完善的管理界面和权限控制可以精细到每个分支谁有权限推送、谁只能看。GitHub 虽然也支持私有仓库但它的核心价值在于开源协作。课件里有句话说得很到位对于开源项目而言GitHub 依然是代码托管的首选对于企业内部代码GitLab 是更可控的选择。2.4 一张表看懂迁移成本SVN 命令到 Git 命令很多从 SVN 转 Git 的人最不适应的是命令体系全变了。我一般会建议新人先看这张对照表不要逐条背而是理解“同一个动作在两种系统里对应什么”动作SVN 命令Git 命令拿最新代码svn checkout / svn updategit clone / git pull提交到中央库svn commitgit push本地提交无必须联网git commit查看历史svn loggit log合并分支svn merge常要联网计算git merge本地快速完成回退版本svn revertgit reset / git revert这张表背后是一个关键差异SVN 的 commit 必须联网Git 的 commit 在本地完成git push才跟远程仓库发生交互。理解了这一点新人在没网的环境下也能用 Git 做完整的管理这在飞机上、会议室里都是实用技能。3. 安装与配置Git Bash、提交者信息、SSH 密钥一次配到位3.1 Windows 安装Git Bash 才是你的主战场课件里提到Git 支持 Linux、Unix、Solaris、Mac 和 Windows下载地址在 git-scm.com。Windows 上安装的是 Git for Windows 项目提供的 exe 安装包官网下载慢的话可以用国内镜像几个人同时装会让官网下载明显变慢。安装时一路默认选项即可但有一个选项要留意安装完成后在开始菜单里会出现 Git Bash 和 Git GUI 两个入口。Git Bash 是一个模拟 Linux 终端的 shell 环境Git 在 Windows 上的命令操作基本都在这里完成也是我建议新人默认使用的入口。Git GUI 是官方自带的图形界面适合看提交历史但日常操作我还是推荐命令行因为网上几乎所有 Git 教程的命令行示例在 Git Bash 里都能直接跑。装完先验证安装是否成功# 查看当前安装的 Git 版本能输出版本号说明安装成功 git version # 查看 Git 命令帮助导航新手不知道该用哪个命令时先看这里 git help第一行命令是最快的验证方式如果系统提示“找不到命令”多半是安装时没勾选把 Git 加入 PATH。第二行命令会启动一个帮助索引列出一级命令的分类比如常用的“commit”“branch”“remote”比硬记命令清单高效。Git 在 Windows 上的安装坑不多最常见的反而是安装后 Git Bash 的默认路径比较深建议在 Git Bash 里执行cd切换到自己指定的工作目录不要用默认的 home 路径。3.2 提交者信息与 SSH 密钥认证配置一步到位装完 Git 的第一件事是配置用户信息这决定了你每次提交记录里的作者是谁。这里要特别提醒用户名和邮箱不是注册 GitHub 时用的登录账号而是写在提交记录里的身份标识团队协作时所有人的邮箱会拼进提交历史所以务必保持一致。查看当前配置和设置全局信息# 查看当前所有配置项确认是否已经配置过 git config --list # 配置全局用户名--global 表示对当前系统用户的所有仓库生效 git config --global user.name zhangsan # 配置全局邮箱建议使用真实邮箱方便同事认人 git config --global user.email zhangsancompany.comgit config --list会把系统、全局、仓库三层配置都列出来新手看这个命令的输出会很晕其实只要关注user.name和user.email两项就够了。--global参数的含义是写入用户主目录下的.gitconfig文件所以配置一次这台电脑上所有仓库都生效。如果某天需要给特定仓库用不同身份去掉--global在仓库目录里重新执行一遍即可。用户信息配好后建议直接把 SSH 密钥也配了。用 HTTPS 协议操作远程仓库每次 push 都要输账号密码很烦SSH 配好之后clone、push、pull 全部免输密码。生成密钥的常用做法是使用 ed25519 算法也可以选传统的 RSA 4096取决于你所在平台的兼容性GitLab、GitHub、Gitee 现在都支持 ed25519。# 生成密钥-C 后面的注释建议填你的邮箱便于识别是哪台机器 ssh-keygen -t ed25519 -C zhangsancompany.com # 一路回车即可默认保存位置一般在 ~/.ssh/id_ed25519 # 查看公钥内容复制后贴到 GitLab/GitHub/Gitee 的 SSH Keys 配置页 cat ~/.ssh/id_ed25519.pub生成密钥时如果担心安全可以设置口令但团队内部日常开发不建议加否则每次 push 都要输口令等于没免密。公钥文件.pub是安全可分享的私钥id_ed25519绝对不能泄露。把公钥贴到平台的 SSH Keys 页面后可以用ssh -T gitgitlab.com验证连通性看到欢迎信息说明认证已经通过。3.3 图形化工具Git GUI 和 TortoiseGit 什么时候用命令行会了之后图形工具是加分项而不是必需项。Git 自带 Git GUI 适合快速浏览提交图谱和暂存改动但功能偏弱。Windows 上更流行的是 TortoiseGit俗称“小乌龟”它在资源管理器右键直接显示 Git 操作菜单对不习惯终端的同事比较友好。SourceTree 是另一款跨平台的图形客户端提交历史可视化做得漂亮还内置了分支管理面板。我的建议是新手期先用命令行把 add、commit、push、pull 这四个动作练熟这是因为图形化工具的操作按钮对应的是命令行的封装不理解背后的命令逻辑遇到冲突解决时会完全不知道图形界面里的按钮在干什么。等命令行顺手了再用 TortoiseGit 或 SourceTree 提升日常操作效率特别是在看分支图谱、双击对比改动这些场景里图形界面的效率确实更高。4. 工作区、暂存区、版本库读懂数据流命令才不会背错4.1 三步数据流三个区到底怎么转起来课件里有一个核心模型Git 把文件放在三个区域里工作区是你打开文件夹能看到的目录暂存区是.git目录下的index文件也叫索引版本库是.git目录本身里面存着所有提交历史的对象库。文件从工作区到最终提交走的是这样一条路修改工作区文件执行git add把改动写入暂存区对暂存区里的改动执行git commit生成一次快照写入版本库。这里最容易绕晕的是暂存区。它不是一个目录而是一个索引文件记录着哪些文件、哪些改动被选中进入了下一次提交。为什么中间要隔一个暂存区因为你可以只提交一部分改动而不是把当天所有的修改一锅端提交上去。比如你同时改了三个文件其中两个属于功能 A一个属于无关注释就可以分两次 add、分两次 commit保持提交历史干净。课件里还画了一张提交示意图HEAD 是指向当前分支的游标master 分支的目录树就是最近一次提交的快照内容这个图理解了git reset的几种模式就顺理成章了。数据流的反向操作更危险。git checkout -- file会用暂存区的内容覆盖工作区文件工作区里未暂存的改动会被清掉git checkout HEAD file则用版本库内容同时覆盖暂存区和工作区会把暂存区里未提交的改动也清掉。课件对这两个命令都加了“极具危险性”的标注新手一定要记清楚方向是“用某个区的内容覆盖另一个区”执行之前先确认被覆盖的改动是不是已经不再需要了。4.2 高频命令串一遍init、status、diff、add、commit理解了三区模型再来看一组标准的操作流程。假设你被拉进一个新项目从远程仓库拿到代码做一次需求改动并提交。这一串命令基本覆盖了日常 80% 的操作# 克隆远程仓库到本地origin 是默认的远程仓库名 git clone gitgitlab.com:team/project.git # 查看当前仓库状态会告诉你有哪些文件被修改、哪些已暂存 git status # 查看工作区和暂存区的差异即“我还没 add 的改动” git diff # 把指定文件加入暂存区准备提交也可以 git add . 加入所有改动 git add src/main.py # 查看已暂存内容和版本库的差异即“我马上将提交什么” git diff --cached # 提交暂存区到本地仓库-m 后面的信息必须写清楚这次改了什么 git commit -m fix: 修复登录接口空指针异常git status是这一组命令里最该牢记的它把当前处于哪个分支、哪些文件待提交、哪些修改未暂存都列清楚。git diff和git diff --cached的边界是新人常混淆的点前者对比工作区与暂存区后者对比暂存区与最近一次提交。git commit提交完改动进入版本库但此刻还没有同步到远程仓库需要执行git push才真正交付给团队。4.3 reset 回退三兄弟--soft、--mixed、--hard 分别动哪个区提交发现写错了怎么办课件里把回退版本单独列了一节核心就是git reset。这个命令有三种模式区别在于分别动哪些区域很多人记混我建议用这种方式理解——它像是一个控制开关决定回退后遗留哪些改动# --soft: 只动版本库的 HEAD 指针暂存区和工作区都不动相当于撤销 commit 但保留 add git reset --soft HEAD~1 # --mixed: 默认模式HEAD 和暂存区都回退工作区保留相当于撤销 commit 和 add git reset HEAD~1 # --hard: 三个区全部回退到指定版本工作区里未提交的改动也会被清掉慎用 git reset --hard HEAD~1三个参数的区别可以这样理解--soft是后悔药里面最温柔的一种提交信息写错了撤销提交但代码还留在暂存区改完重新 commit 就行--mixed连暂存区的选中状态都撤掉代码留在工作区需要重新 add--hard是核弹会丢掉所有未提交的改动我见过不少新人执行完git reset --hard之后才发现丢失的代码找不回来了。如果回退的提交已经 push 到远程仓库不要直接 reset 后强推在分支保护开启的仓库里强推会被拒这时候用git revert生成一次反向提交更安全。5. 常见问题与避坑五个高频踩坑点从 SSH 认证失败到误清改动5.1 SSH 认证失败Permission denied (publickey)现象执行git clone gitgitlab.com:team/project.git时报错Permission denied (publickey)有时候连gitgithub.com也连不上看起来像灵异事件。原因绝大多数情况是 SSH 密钥没有生效具体分三种——公钥没贴到平台、私钥没注册到 ssh-agent、多台机器混用了同一个用户名导致密钥不匹配。解决先确认公钥已贴到平台的 SSH Keys 配置页再用ssh -vT gitgitlab.com调试连接输出里会标明用哪个密钥文件去认证。如果是多密钥环境在~/.ssh/config里指定当前项目的密钥文件避免 Git 拿错密钥去撞平台的认证。# 检查本地密钥文件的权限Windows 上 OpenSSH 对私钥权限敏感 # 先把密钥注册到 agent再测试连通性 ssh-add ~/.ssh/id_ed25519 ssh -T gitgitlab.com出现Authentication succeeded就是通了。这里有个常见误解很多人以为 SSH 认证失败是网络问题其实大部分和网络无关是本机密钥配置的问题。Git 走的是 22 端口访问被限制时换 HTTPS 协议克隆是临时方案但根因还是要把密钥配对。5.2 commit 信息写错了--amend 才是后悔药现象刚执行完git commit -m fix bug同事提醒说这次改动牵涉模块太多提交信息应该写详细一点但已经提交了。原因commit 信息是提交对象的一部分没法直接改只能通过生成新提交来替换旧提交。解决如果提交还没有 push用git commit --amend -m fix: 登录接口超时问题重构 token 校验逻辑。--amend会用新的提交替换当前分支的最后一次提交提交历史里不会留下两条记录。注意如果这个提交已经被 push 并且其他同事已经基于它拉了分支amend 会改变提交哈希导致同事的分支对不上这时候不要 amend老老实实新增一条提交说明。5.3 手滑执行 git checkout .改了一上午的代码没了现象想丢弃某个文件的改动敲了git checkout .结果整个工作区所有未暂存的改动全部消失一上午的功能白写了。原因git checkout .的作用是用暂存区的内容替换整个工作区所有未git add的改动都被覆盖这个操作没有任何确认提示。解决如果改动已经被git add过git reset可以找回暂存区里的内容。如果连 add 都没执行唯一的希望是用git fsck --lost-found去对象库里捞悬空对象Git 的底层机制是只要对象还存在于.git/objects理论上都能捞回来但操作繁琐。这条的教训是丢弃改动之前先git status看清楚影响范围平时养成频繁git commit的习惯即使没写完提交了就有后悔药没提交就是黑匣子。5.4 把 node_modules 和 .env 推上去了提交前先写 .gitignore现象新仓库初始化后直接git add .把node_modules、target、.env全部推进了版本库仓库体积飙到几百兆更严重的是.env里的数据库密码被同事从 Git 历史里翻出来了。原因没有配置.gitignore就盲目 add依赖目录和本地配置文件被当成了普通文件提交。这类文件一旦进入 Git 历史就算后面删了历史记录里还能翻出来。解决初始化仓库的第一件事是创建.gitignore把依赖目录、编译产物、本地配置、IDE 配置都排除掉。已经误提交的文件用git rm --cached把它们从暂存区移除但保留本地文件。# 从版本库移除但保留本地工作区文件-r 递归处理目录 git rm -r --cached node_modules # 最终把这条变更提交远程仓库的 Git 历史才干净 git commit -m chore: remove node_modules from version control.gitignore文件本身要提交到仓库这样全团队共享同一套排除规则。网上有各语言的标准模板直接拷贝一份再补上项目特有规则即可。GitHub 上的开源仓库几乎都自带.gitignore这就是为什么它们的仓库体积控制得很好。5.5 merge 冲突红字不是故障是让你手动决定现象执行git merge dev时终端输出CONFLICT (content): Merge conflict in src/UserService.java文件里出现一堆、、标记。原因两个分支修改了同一份文件的同一区域Git 不知道应该保留谁的版本于是停下等待人工裁决。这是分支协作中必然出现的场景没有冲突才奇怪。解决不要慌先git status列出所有冲突文件逐个打开处理和之间是当前分支的版本和之间是合并进来的分支的版本手工编辑成最终想要的内容删除三组标记符号然后 add 并 commit。复杂冲突建议借助 IDE 内置的合并工具IntelliJ IDEA、VS Code 都有可视化对比比盯着文本标记效率高一截。合并完成后跑一遍测试再 push这是团队协作最核心的一条纪律。6. GitLab 场景演练从克隆到 merge request 的完整迭代6.1 从 clone 到 merge request一次完整的开发循环课件里以 GitLab 为例做了一次场景演练把前面的知识点串成一条完整的链路。我把它整理成一套标准流程新人照做就能走通一次真正的协作开发# 1. 克隆项目到本地 git clone gitgitlab.com:team/project.git cd project # 2. 从 master 拉一条开发分支功能在一个独立分支上做 git checkout -b feature/login-timeout # 3. 开发完成后查看改动并提交 git add src/main/java/ git commit -m fix: 登录接口增加超时处理 # 4. 先拉取最新 master 并合并避免提交时冲突 git checkout master git pull origin master git checkout feature/login-timeout git merge master # 5. 推送分支到 GitLab自动生成 merge request 入口 git push origin feature/login-timeout这里有两个细节。第 4 步的“先合并再推送”是我带团队的强制要求直接把分支推到 GitLab 再在 MR 里解决冲突很多次会失败。第 5 步推送后GitLab 网页上会提示“Create merge request”填清楚描述和指派给哪个 reviewer代码评审通过后由有权限的人执行合并。整套流程的核心思路是master 永远保持可发布状态任何新功能都在独立分支上开发合并动作永远发生在远程平台而不是在本地把 dev 往 master 上合。6.2 分支保护与提交纪律团队协作最后的底线GitLab 里可以对 master 开启“Protected branch”开启后普通成员不能直接向 master 推送只能通过 merge request 合并。这个设置保证了关键分支不会被误推评审流程也顺理成章。另一个容易忽略的纪律是提交信息的格式团队最好统一风格比如fix: 描述、feat: 描述、refactor: 描述这样git log读起来像一份规范的变更日志。从那以后我每次拿到新仓库第一件事就是先看.gitignore是否齐全、跑一遍git status确认初始状态干净再开始动代码。这套习惯让新人的翻车率降了不少希望帮到你。本文还有配套的精品资源点击获取
Git从入门到实践：核心原理与GitLab协作开发全攻略
简介这是一份面向Git新手与内部培训讲师的完整教学PPT总计59页根据多年实战与授课经验整理浓缩了团队开发中最常使用的Git知识与操作场景。内容从集中式与分布式版本控制的对比切入清晰讲解Git工作区、暂存区、版本库原理并覆盖安装配置、克隆项目、提交修改、版本回退、分支管理与合并冲突处理等高频命令同时给出GitHub与GitLab的差异说明、可视化工具推荐以及基于GitLab的完整开发场景演练。资源包为单个pptx文件大小4.15MB讲师可直接用于公司或学校培训简单修改单位名称即可授课学员也可按章节自学实操。跟随课程操作一遍即可基本掌握从初始化仓库到远程协作的完整能力有效减少团队协作中的代码管理混乱。已有2050人学习下载适合希望快速上手Git、沉淀内部培训课程的开发团队与个人。1. 被 Git 支配的新人第一天一份培训课件能省下的沟通成本新同事入职第一天mentor 甩过来一行git clone他盯着终端愣了三秒问“Git 和 GitHub 不是一个东西吗”这个场景我见过太多次。Git 是每个开发者的基本功但能把 Git 讲清楚的人不多——分布式和集中式的区别、暂存区到底是干嘛的、为什么 merge 会冲突书里都有可真到用的时候全是坑。这篇要拆的是一份 Git 介绍与使用培训课件覆盖从 Git 概念、安装配置到 GitLab 开发场景演练的完整链路适合两类人一类是刚入职想快速上手 Git 的新手另一类是要给部门或学校做内部培训、需要现成课程改改就能用的讲师。课件的实际内容我按自己带新人的经验重新梳理了一遍照着这篇走第一周就能独立处理 clone、commit、分支合并这些日常操作。2. 集中式与分布式先弄懂 Git 为什么快再学命令才有底2.1 集中式的死穴中央服务器一挂全组停工课件里先讲了 SVN 这类集中式版本控制系统的典型流程早上到公司先从中央服务器 checkout 最新代码在自己电脑上改改完 commit 回中央服务器。听起来顺理成章但这里有个致命问题——所有操作都依赖那台中央服务器。网络慢的时候提交一个大文件要等半天服务器磁盘满了或者宕机了全组人连历史版本都查不了只能干等运维恢复。课件里举了个很形象的例子提交 5MB 的代码要等 20 分钟。这个场景在老牌集中式系统里一点都不夸张因为每次提交都得把差异传到服务器服务器再算一次版本库状态网络往返加服务端计算慢是常态。而单点故障更是集中式的死穴中央服务器的磁盘一旦损坏又没有及时备份整个项目的提交历史可能就全没了。这个对比值得反复讲给新人听集中式把版本库当唯一真相分布式把版本库复制到每个人本地。理解了这一层后面学git clone、git push、git pull的时候就会知道这些命令的本质是本地库和远程库之间的同步而不是“上传下载”。2.2 分布式把版本库复制到本地快照带来的三个红利Git 的设计思路和集中式完全不同。每个开发者的git clone拿到的不是一个工作副本而是远程仓库的完整镜像包含全部提交历史、全部分支、全部标签。本地就是一份完整的版本库日常的 add、commit、log、branch 操作全部在本地完成不消耗任何网络资源。课件里提到一个关键词叫“快照”。Git 每次提交保存的不是文件差异而是整个文件系统的一次快照Git 内部会用高效的方式存储这些快照。带来的直接好处有三个。第一速度本地操作没有网络开销commit、diff、log 都是毫秒级响应。第二安全任何一台机器的本地库都是完整备份中央服务器挂了随便找一台本地库就能还原不存在“所有鸡蛋在一个篮子里”的问题。第三分支成本极低在 Git 里创建分支只是创建一个指针几十个分支同时开发、切换、合并都是常态这也就是课件里说的“对非线性开发模式的强力支持”。这个设计还有一个容易被忽略的推论既然每个人的本地都是完整版本库那任何人的本地库都可以成为新的“中央库”。Git 并没有严格的服务端和客户端之分所谓的 Git 服务器上装的也是同一个 Git只是多配置了一些权限和钩子。这个思想是理解 GitLab、GitHub 工作原理的基础。2.3 Git、GitHub、GitLab 的分工工具、平台、私服这三个名词是新人最容易混的课件里专门做了区分。Git 是一个版本控制工具装在你电脑上和多语言运行时一样是一个软件。GitHub 是基于 Git 的在线代码托管平台也是目前全球最大的开源社区Spring、MyBatis、React、Vue 这些知名项目的源码都托管在上面。GitLab 则是开源的仓库管理软件你可以拿它在自己公司的内网搭一个类似 GitHub 的服务。从代码私有性角度说GitLab 更适合企业内部用它提供了完善的管理界面和权限控制可以精细到每个分支谁有权限推送、谁只能看。GitHub 虽然也支持私有仓库但它的核心价值在于开源协作。课件里有句话说得很到位对于开源项目而言GitHub 依然是代码托管的首选对于企业内部代码GitLab 是更可控的选择。2.4 一张表看懂迁移成本SVN 命令到 Git 命令很多从 SVN 转 Git 的人最不适应的是命令体系全变了。我一般会建议新人先看这张对照表不要逐条背而是理解“同一个动作在两种系统里对应什么”动作SVN 命令Git 命令拿最新代码svn checkout / svn updategit clone / git pull提交到中央库svn commitgit push本地提交无必须联网git commit查看历史svn loggit log合并分支svn merge常要联网计算git merge本地快速完成回退版本svn revertgit reset / git revert这张表背后是一个关键差异SVN 的 commit 必须联网Git 的 commit 在本地完成git push才跟远程仓库发生交互。理解了这一点新人在没网的环境下也能用 Git 做完整的管理这在飞机上、会议室里都是实用技能。3. 安装与配置Git Bash、提交者信息、SSH 密钥一次配到位3.1 Windows 安装Git Bash 才是你的主战场课件里提到Git 支持 Linux、Unix、Solaris、Mac 和 Windows下载地址在 git-scm.com。Windows 上安装的是 Git for Windows 项目提供的 exe 安装包官网下载慢的话可以用国内镜像几个人同时装会让官网下载明显变慢。安装时一路默认选项即可但有一个选项要留意安装完成后在开始菜单里会出现 Git Bash 和 Git GUI 两个入口。Git Bash 是一个模拟 Linux 终端的 shell 环境Git 在 Windows 上的命令操作基本都在这里完成也是我建议新人默认使用的入口。Git GUI 是官方自带的图形界面适合看提交历史但日常操作我还是推荐命令行因为网上几乎所有 Git 教程的命令行示例在 Git Bash 里都能直接跑。装完先验证安装是否成功# 查看当前安装的 Git 版本能输出版本号说明安装成功 git version # 查看 Git 命令帮助导航新手不知道该用哪个命令时先看这里 git help第一行命令是最快的验证方式如果系统提示“找不到命令”多半是安装时没勾选把 Git 加入 PATH。第二行命令会启动一个帮助索引列出一级命令的分类比如常用的“commit”“branch”“remote”比硬记命令清单高效。Git 在 Windows 上的安装坑不多最常见的反而是安装后 Git Bash 的默认路径比较深建议在 Git Bash 里执行cd切换到自己指定的工作目录不要用默认的 home 路径。3.2 提交者信息与 SSH 密钥认证配置一步到位装完 Git 的第一件事是配置用户信息这决定了你每次提交记录里的作者是谁。这里要特别提醒用户名和邮箱不是注册 GitHub 时用的登录账号而是写在提交记录里的身份标识团队协作时所有人的邮箱会拼进提交历史所以务必保持一致。查看当前配置和设置全局信息# 查看当前所有配置项确认是否已经配置过 git config --list # 配置全局用户名--global 表示对当前系统用户的所有仓库生效 git config --global user.name zhangsan # 配置全局邮箱建议使用真实邮箱方便同事认人 git config --global user.email zhangsancompany.comgit config --list会把系统、全局、仓库三层配置都列出来新手看这个命令的输出会很晕其实只要关注user.name和user.email两项就够了。--global参数的含义是写入用户主目录下的.gitconfig文件所以配置一次这台电脑上所有仓库都生效。如果某天需要给特定仓库用不同身份去掉--global在仓库目录里重新执行一遍即可。用户信息配好后建议直接把 SSH 密钥也配了。用 HTTPS 协议操作远程仓库每次 push 都要输账号密码很烦SSH 配好之后clone、push、pull 全部免输密码。生成密钥的常用做法是使用 ed25519 算法也可以选传统的 RSA 4096取决于你所在平台的兼容性GitLab、GitHub、Gitee 现在都支持 ed25519。# 生成密钥-C 后面的注释建议填你的邮箱便于识别是哪台机器 ssh-keygen -t ed25519 -C zhangsancompany.com # 一路回车即可默认保存位置一般在 ~/.ssh/id_ed25519 # 查看公钥内容复制后贴到 GitLab/GitHub/Gitee 的 SSH Keys 配置页 cat ~/.ssh/id_ed25519.pub生成密钥时如果担心安全可以设置口令但团队内部日常开发不建议加否则每次 push 都要输口令等于没免密。公钥文件.pub是安全可分享的私钥id_ed25519绝对不能泄露。把公钥贴到平台的 SSH Keys 页面后可以用ssh -T gitgitlab.com验证连通性看到欢迎信息说明认证已经通过。3.3 图形化工具Git GUI 和 TortoiseGit 什么时候用命令行会了之后图形工具是加分项而不是必需项。Git 自带 Git GUI 适合快速浏览提交图谱和暂存改动但功能偏弱。Windows 上更流行的是 TortoiseGit俗称“小乌龟”它在资源管理器右键直接显示 Git 操作菜单对不习惯终端的同事比较友好。SourceTree 是另一款跨平台的图形客户端提交历史可视化做得漂亮还内置了分支管理面板。我的建议是新手期先用命令行把 add、commit、push、pull 这四个动作练熟这是因为图形化工具的操作按钮对应的是命令行的封装不理解背后的命令逻辑遇到冲突解决时会完全不知道图形界面里的按钮在干什么。等命令行顺手了再用 TortoiseGit 或 SourceTree 提升日常操作效率特别是在看分支图谱、双击对比改动这些场景里图形界面的效率确实更高。4. 工作区、暂存区、版本库读懂数据流命令才不会背错4.1 三步数据流三个区到底怎么转起来课件里有一个核心模型Git 把文件放在三个区域里工作区是你打开文件夹能看到的目录暂存区是.git目录下的index文件也叫索引版本库是.git目录本身里面存着所有提交历史的对象库。文件从工作区到最终提交走的是这样一条路修改工作区文件执行git add把改动写入暂存区对暂存区里的改动执行git commit生成一次快照写入版本库。这里最容易绕晕的是暂存区。它不是一个目录而是一个索引文件记录着哪些文件、哪些改动被选中进入了下一次提交。为什么中间要隔一个暂存区因为你可以只提交一部分改动而不是把当天所有的修改一锅端提交上去。比如你同时改了三个文件其中两个属于功能 A一个属于无关注释就可以分两次 add、分两次 commit保持提交历史干净。课件里还画了一张提交示意图HEAD 是指向当前分支的游标master 分支的目录树就是最近一次提交的快照内容这个图理解了git reset的几种模式就顺理成章了。数据流的反向操作更危险。git checkout -- file会用暂存区的内容覆盖工作区文件工作区里未暂存的改动会被清掉git checkout HEAD file则用版本库内容同时覆盖暂存区和工作区会把暂存区里未提交的改动也清掉。课件对这两个命令都加了“极具危险性”的标注新手一定要记清楚方向是“用某个区的内容覆盖另一个区”执行之前先确认被覆盖的改动是不是已经不再需要了。4.2 高频命令串一遍init、status、diff、add、commit理解了三区模型再来看一组标准的操作流程。假设你被拉进一个新项目从远程仓库拿到代码做一次需求改动并提交。这一串命令基本覆盖了日常 80% 的操作# 克隆远程仓库到本地origin 是默认的远程仓库名 git clone gitgitlab.com:team/project.git # 查看当前仓库状态会告诉你有哪些文件被修改、哪些已暂存 git status # 查看工作区和暂存区的差异即“我还没 add 的改动” git diff # 把指定文件加入暂存区准备提交也可以 git add . 加入所有改动 git add src/main.py # 查看已暂存内容和版本库的差异即“我马上将提交什么” git diff --cached # 提交暂存区到本地仓库-m 后面的信息必须写清楚这次改了什么 git commit -m fix: 修复登录接口空指针异常git status是这一组命令里最该牢记的它把当前处于哪个分支、哪些文件待提交、哪些修改未暂存都列清楚。git diff和git diff --cached的边界是新人常混淆的点前者对比工作区与暂存区后者对比暂存区与最近一次提交。git commit提交完改动进入版本库但此刻还没有同步到远程仓库需要执行git push才真正交付给团队。4.3 reset 回退三兄弟--soft、--mixed、--hard 分别动哪个区提交发现写错了怎么办课件里把回退版本单独列了一节核心就是git reset。这个命令有三种模式区别在于分别动哪些区域很多人记混我建议用这种方式理解——它像是一个控制开关决定回退后遗留哪些改动# --soft: 只动版本库的 HEAD 指针暂存区和工作区都不动相当于撤销 commit 但保留 add git reset --soft HEAD~1 # --mixed: 默认模式HEAD 和暂存区都回退工作区保留相当于撤销 commit 和 add git reset HEAD~1 # --hard: 三个区全部回退到指定版本工作区里未提交的改动也会被清掉慎用 git reset --hard HEAD~1三个参数的区别可以这样理解--soft是后悔药里面最温柔的一种提交信息写错了撤销提交但代码还留在暂存区改完重新 commit 就行--mixed连暂存区的选中状态都撤掉代码留在工作区需要重新 add--hard是核弹会丢掉所有未提交的改动我见过不少新人执行完git reset --hard之后才发现丢失的代码找不回来了。如果回退的提交已经 push 到远程仓库不要直接 reset 后强推在分支保护开启的仓库里强推会被拒这时候用git revert生成一次反向提交更安全。5. 常见问题与避坑五个高频踩坑点从 SSH 认证失败到误清改动5.1 SSH 认证失败Permission denied (publickey)现象执行git clone gitgitlab.com:team/project.git时报错Permission denied (publickey)有时候连gitgithub.com也连不上看起来像灵异事件。原因绝大多数情况是 SSH 密钥没有生效具体分三种——公钥没贴到平台、私钥没注册到 ssh-agent、多台机器混用了同一个用户名导致密钥不匹配。解决先确认公钥已贴到平台的 SSH Keys 配置页再用ssh -vT gitgitlab.com调试连接输出里会标明用哪个密钥文件去认证。如果是多密钥环境在~/.ssh/config里指定当前项目的密钥文件避免 Git 拿错密钥去撞平台的认证。# 检查本地密钥文件的权限Windows 上 OpenSSH 对私钥权限敏感 # 先把密钥注册到 agent再测试连通性 ssh-add ~/.ssh/id_ed25519 ssh -T gitgitlab.com出现Authentication succeeded就是通了。这里有个常见误解很多人以为 SSH 认证失败是网络问题其实大部分和网络无关是本机密钥配置的问题。Git 走的是 22 端口访问被限制时换 HTTPS 协议克隆是临时方案但根因还是要把密钥配对。5.2 commit 信息写错了--amend 才是后悔药现象刚执行完git commit -m fix bug同事提醒说这次改动牵涉模块太多提交信息应该写详细一点但已经提交了。原因commit 信息是提交对象的一部分没法直接改只能通过生成新提交来替换旧提交。解决如果提交还没有 push用git commit --amend -m fix: 登录接口超时问题重构 token 校验逻辑。--amend会用新的提交替换当前分支的最后一次提交提交历史里不会留下两条记录。注意如果这个提交已经被 push 并且其他同事已经基于它拉了分支amend 会改变提交哈希导致同事的分支对不上这时候不要 amend老老实实新增一条提交说明。5.3 手滑执行 git checkout .改了一上午的代码没了现象想丢弃某个文件的改动敲了git checkout .结果整个工作区所有未暂存的改动全部消失一上午的功能白写了。原因git checkout .的作用是用暂存区的内容替换整个工作区所有未git add的改动都被覆盖这个操作没有任何确认提示。解决如果改动已经被git add过git reset可以找回暂存区里的内容。如果连 add 都没执行唯一的希望是用git fsck --lost-found去对象库里捞悬空对象Git 的底层机制是只要对象还存在于.git/objects理论上都能捞回来但操作繁琐。这条的教训是丢弃改动之前先git status看清楚影响范围平时养成频繁git commit的习惯即使没写完提交了就有后悔药没提交就是黑匣子。5.4 把 node_modules 和 .env 推上去了提交前先写 .gitignore现象新仓库初始化后直接git add .把node_modules、target、.env全部推进了版本库仓库体积飙到几百兆更严重的是.env里的数据库密码被同事从 Git 历史里翻出来了。原因没有配置.gitignore就盲目 add依赖目录和本地配置文件被当成了普通文件提交。这类文件一旦进入 Git 历史就算后面删了历史记录里还能翻出来。解决初始化仓库的第一件事是创建.gitignore把依赖目录、编译产物、本地配置、IDE 配置都排除掉。已经误提交的文件用git rm --cached把它们从暂存区移除但保留本地文件。# 从版本库移除但保留本地工作区文件-r 递归处理目录 git rm -r --cached node_modules # 最终把这条变更提交远程仓库的 Git 历史才干净 git commit -m chore: remove node_modules from version control.gitignore文件本身要提交到仓库这样全团队共享同一套排除规则。网上有各语言的标准模板直接拷贝一份再补上项目特有规则即可。GitHub 上的开源仓库几乎都自带.gitignore这就是为什么它们的仓库体积控制得很好。5.5 merge 冲突红字不是故障是让你手动决定现象执行git merge dev时终端输出CONFLICT (content): Merge conflict in src/UserService.java文件里出现一堆、、标记。原因两个分支修改了同一份文件的同一区域Git 不知道应该保留谁的版本于是停下等待人工裁决。这是分支协作中必然出现的场景没有冲突才奇怪。解决不要慌先git status列出所有冲突文件逐个打开处理和之间是当前分支的版本和之间是合并进来的分支的版本手工编辑成最终想要的内容删除三组标记符号然后 add 并 commit。复杂冲突建议借助 IDE 内置的合并工具IntelliJ IDEA、VS Code 都有可视化对比比盯着文本标记效率高一截。合并完成后跑一遍测试再 push这是团队协作最核心的一条纪律。6. GitLab 场景演练从克隆到 merge request 的完整迭代6.1 从 clone 到 merge request一次完整的开发循环课件里以 GitLab 为例做了一次场景演练把前面的知识点串成一条完整的链路。我把它整理成一套标准流程新人照做就能走通一次真正的协作开发# 1. 克隆项目到本地 git clone gitgitlab.com:team/project.git cd project # 2. 从 master 拉一条开发分支功能在一个独立分支上做 git checkout -b feature/login-timeout # 3. 开发完成后查看改动并提交 git add src/main/java/ git commit -m fix: 登录接口增加超时处理 # 4. 先拉取最新 master 并合并避免提交时冲突 git checkout master git pull origin master git checkout feature/login-timeout git merge master # 5. 推送分支到 GitLab自动生成 merge request 入口 git push origin feature/login-timeout这里有两个细节。第 4 步的“先合并再推送”是我带团队的强制要求直接把分支推到 GitLab 再在 MR 里解决冲突很多次会失败。第 5 步推送后GitLab 网页上会提示“Create merge request”填清楚描述和指派给哪个 reviewer代码评审通过后由有权限的人执行合并。整套流程的核心思路是master 永远保持可发布状态任何新功能都在独立分支上开发合并动作永远发生在远程平台而不是在本地把 dev 往 master 上合。6.2 分支保护与提交纪律团队协作最后的底线GitLab 里可以对 master 开启“Protected branch”开启后普通成员不能直接向 master 推送只能通过 merge request 合并。这个设置保证了关键分支不会被误推评审流程也顺理成章。另一个容易忽略的纪律是提交信息的格式团队最好统一风格比如fix: 描述、feat: 描述、refactor: 描述这样git log读起来像一份规范的变更日志。从那以后我每次拿到新仓库第一件事就是先看.gitignore是否齐全、跑一遍git status确认初始状态干净再开始动代码。这套习惯让新人的翻车率降了不少希望帮到你。本文还有配套的精品资源点击获取