简介这是一份面向零基础人群的Git使用教程PDF定位为最详细、最傻瓜式的入门指南帮助读者解决多人协作开发中的代码管理难题从零掌握分布式版本控制的核心思想。文档从Git的诞生背景讲起详细介绍了Windows安装配置、创建版本库、工作区与暂存区的关系并通过git add、git commit、git log、git reset --hard、git reflog等命令演示了版本创建、查看、回退与找回的完整流程每个步骤都配有命令行示例和输出说明便于初学者按图索骥。内容由浅入深覆盖从环境搭建到日常版本操作的完整链路。同时说明了HEAD指针、版本号、分支等概念让读者理解版本回退的原理而不是死记命令。资源共1个文件为3.05MB的PDF电子书目录清晰、图文并茂适合需要系统学习Git的开发新手、学生及运维人员随时查阅。已有10872人学习下载是广受认可的Git入门参考。1. Git是什么为什么每个写代码的人都需要它Git使用教程要讲的是版本控制往浅了说就是给项目装上一套“可以随时反悔”的备份系统。你大概率见过这种场景项目文件夹里躺着代码_最终版、代码_最终版2、代码_打死不改版真到要回退某个版本时只能挨个解压去碰运气。Git把每一次提交都记录成一条快照随时能回到任意状态不依赖网盘、不依赖手动复制所有操作都在本地完成。把需求说得更直白一点。你维护一个内部服务上午接口还正常下午改了三个文件页面全挂。没有版本控制只能靠记忆一步步回退有Git一条命令回到上午状态再用git diff看改动。所以Git最大的价值不是“把代码给别人看”而是“给未来的自己留后路”。这份教程按安装、初始化、日常提交、分支、远程协作、避坑、进阶的顺序走所有命令都可以直接复制进终端复现。适合刚接触版本控制的开发者也适合用了很久图形界面、想补一下命令行能力的人。2. 安装与初始化从零开始的第一个本地仓库2.1 在不同平台安装GitmacOS、Windows与Linux的常用方式安装Git的方式因操作系统而异这里给的是最常见的几条路径保证你能跑通不做多余美化。macOS上一般用包管理器一条命令装完brew install git这条命令会把Git和它依赖的组件一起安装省得手动处理环境变量。装完务必验证一下git --version如果终端里执行后版本号没变大概率是系统自带的旧版Git还在优先位置。macOS的老版本系统可能预装了Git但版本很老功能和新版有差距。打开新的终端窗口再执行一次git --version如果还是旧的需要检查PATH里有没有包含包管理器的安装目录。Windows上最省事的方式是去官网下安装包安装时一路点“Next”不改默认项。装完之后不要急着用cmd而是从“开始”菜单里打开Git Bash。Git Bash是一个模拟Linux命令行的环境路径写法、换行符、编码处理和Linux一致能少踩很多坑。在Git Bash里执行git --version看到版本号输出就说明安装成功。之前有同事直接拿cmd敲命令结果中文路径乱码、命令语法报错折腾半天换成Git Bash马上顺畅。Linux上Debian和Ubuntu系用aptsudo apt update sudo apt install git -yCentOS、RHEL、Fedora这些用yum或dnfsudo yum install git各发行版仓库里的Git版本可能新旧不一但对绝大多数开发场景都够用。装完同样验证一下。如果提示command not found先检查是不是真的安装成功再检查PATH配置通常重新登录终端就正常了。安装完成后的第一件事不是急着建仓库而是配置身份信息git config --global user.name YourName git config --global user.email youexample.com git config --listuser.name和user.email会写进每一次提交的元数据里提交历史里“谁改了什么”全靠它。建议在同一个团队里保持稳定的身份否则一个人的提交会散落在多个名字下面。--global表示全局生效即这台机器上所有仓库都共用这套身份。如果只想对某一个仓库单独设置身份进到仓库目录去掉--global再执行一次即可。还有个配置建议顺手做了把Git的默认编辑器改掉。Git在提交时如果没带-m参数会打开默认编辑器等你输入提交说明。对不熟悉vim的人第一次被丢进vim界面可能真的不知道怎么保存退出。换成常见的图形化编辑器就好很多git config --global core.editor code --wait这样执行git commit不带-m时会打开一个编辑器窗口写完保存关闭提交就继续了。这个配置一次搞定长期受益。2.2 初始化仓库与提交第一个版本init、add、commit三连装好Git之后第一步是让一个普通目录被Git接管。先建一个测试项目mkdir my-demo-project cd my-demo-project git initgit init会在当前目录生成一个.git子目录。这个.git可以理解成Git的“黑匣子”项目的快照、提交历史、分支指针、配置全存在这里。日常我们不需要打开它但也别乱删删了整个历史就没了。在项目里创建一个普通文件echo # demo README.md此时执行git status会看到README.md处于untracked状态意思是Git知道这个文件存在但还没有为它建立快照。接下来执行git add README.md git commit -m 初始提交git add负责把文件加入暂存区git commit才真正生成一个不可变的历史节点。这个两步走的设计很多人刚开始不理解等协作时才发现好处你可以只选择一部分文件暂存再统一提交。比如你同时改了接口代码和测试用例想分两个语义清晰的提交就分两次add再分别commit。commit之后再执行git status会看到“working tree clean”或类似的中文提示表示工作区与当前提交一致所有改动都已经入库。这个状态在Git里叫干净状态是你开始下一阶段工作前最希望看到的样子。新手还有一个高频疑问为什么git add了又说有改动假设你add了文件然后又改了一次git status会同时显示这个文件已经在暂存区、但工作区又有新改动。原因很简单add只把当时的内容放进了暂存区后续改动需要重新add才会被包含。想偷懒的话可以用一条半自动提交命令git commit -am 更新演示代码-a参数会自动暂存所有“已经被Git跟踪过的文件”-m参数指定提交说明两步变一步。但要注意新创建的文件没有被跟踪-am管不了它新文件必须先用git add让Git认识它。如果提交后发现这次改动不想要了用git restore回滚工作区git restore README.mdgit restore是较新版本Git推荐的恢复命令语义比老式checkout清晰。想同时撤销暂存区和工作区两处状态可以加参数git restore --staged README.md git restore README.md--staged只把暂存区里的改动清掉文件内容本身不受影响。先理解工作区、暂存区、提交历史这三层关系后面所有高阶操作都是在这三个概念上做文章。3. 日常操作把文件提交进历史而不是从零开始3.1 工作区、暂存区与快照理解Git的三个坑位Git的工作模型可以简化成三个区域工作区、暂存区、本地仓库。工作区是你磁盘上看到的文件暂存区是下一次提交的候选清单本地仓库则保存了每一次提交的完整快照。三个区域对应三条高频命令git add、git commit、git status。很多新人搞不清楚文件到底处于什么状态一个直观的办法是直接在项目里执行git status输出会明确告诉你文件处于哪一类状态On branch main Changes not staged for commit: (use git add file... to update what will be committed) modified: README.md Untracked files: (use git add file... to include in what will be committed) notes.txtmodified表示文件已经被跟踪过但工作区内容和暂存区不一致Untracked表示文件完全在Git管理之外。这两个状态是新手最容易混淆的地方。文件从untracked到tracked只差一次git add从modified到committed需要add和commit两步。快照是Git记录历史的方式。每次commit都会生成一个哈希值相当于该次提交的身份证号。查看历史记录用git log --oneline输出类似a3f2b8c 修复登录接口超时问题 d1e9f70 添加用户认证模块 f4c2a1b 初始提交左边是提交哈希的前几位右边是提交说明。用git log --oneline能快速浏览整个项目的演进脉络。想要更直观地看分支和合并情况可以用git log --graph --oneline --all这个命令会把分支分叉、合并提交用线条画出来对理解仓库拓扑非常有帮助。回到日常开发提交前审查改动是一个必须养成的习惯。用git diff查看自己到底改了什么git diff # 工作区 vs 暂存区 git diff --staged # 暂存区 vs 当前提交 git diff HEAD # 工作区 vs 当前提交我第一次带团队时要求组员commit之前必须执行git diff --staged就是为了防止把调试用的临时改动、敏感信息一起提交上去。这一步成本很低但能把很多低级失误拦在门外。有时提交完之后想回退到某个历史版本最常用的是git resetgit reset --hard commit hash--hard参数会把工作区、暂存区全部重置到指定提交的状态之后的改动统统丢弃。这是Git里最危险的命令之一一旦执行未提交的改动很难找回。reset还有两种更温和的参数参数对暂存区对工作区典型用途--soft重置不变想重新提交但保留文件内容--mixed默认重置不变撤销add但保留改动--hard重置重置彻底回到历史状态我的建议是新手默认只用--mixed毕竟它只撤销暂存不碰文件内容相对安全。真想用--hard时先想清楚——提交历史里有没有值得保住的快照如果没有再动手。3.2 分支的创建、切换与合并代码上的“平行世界”分支是Git和很多老版本控制工具拉开差距的地方。Git的分支本质上是一个指针指向某条提交链上的最新一次提交。创建分支几乎没有成本所以可以大胆开分支做实验这也是Git工作流能铺开的基础。创建并查看分支git branch feature/login git branch第一行创建一个名为feature/login的新分支但不会自动切换过去第二行列出所有本地分支当前所在分支前面会有一个星号。想切换到新分支git checkout feature/login较新版本的Git推荐用git switch语义更清晰git switch feature/login git switch -c feature/dev-c是create的缩写一条命令完成“创建分支并切换过去”。我自己日常更常用switch就是因为不会误把“切换分支”写成“恢复文件”命令职责更单一。在分支上开发完之后需要合回主分支。场景是这样的你从main分了feature/login在这个分支上加了登录功能提交了几次现在要并回maingit switch main git merge feature/loginmerge会把feature分支上的提交记录合并到当前分支。合并结果有两种常见情况第一种是快速前进feature分支从main分出后main没有任何新提交merge只是把main的指针向前移动到feature的顶端历史保持一条直线干净利落。第二种是三方合并main在feature分出之后也出现了新提交Git需要找到两个分支的共同祖先做三路比较把两边的改动合在一起并生成一个合并提交。如果两边改了同一个文件的同一段代码Git无法自己判断取哪一边就会停下来报告冲突。此时git status会列出冲突文件解决问题的办法放在第4章讲。还有一个高频场景和生产习惯相关正在一个分支干活突然要切去另一个分支修紧急问题但当前分支的改动还没写完也不想提交半成品。这时用git stash暂存现场git stash git switch hotfix # 修完紧急问题 git switch feature/login git stash popgit stash把未提交的改动从工作区清走暂存到一个栈里git stash pop再把它放回来。如果放回来时有冲突手动解决后提交即可。这个习惯能避免“不想提交又必须切换分支”的尴尬也不会因为硬切换分支把改动搞丢。分支的存在让多人协作从“排队改文件”变成了“各自建平行世界”。需要注意的是分支名尽量有语义比如feature/user-login、fix/payment-timeout不要用dev1、test2这类含义模糊的名字。仓库是多人共用的你的分支命名会影响所有人检索历史的效率。4. 与远程仓库协作拉取、推送与团队冲突4.1 关联远程仓库和第一次推送远程仓库不是Git的必需品但没有它团队协作就无从谈起。常见的做法是先在代码托管平台创建一个空仓库再把本地仓库关联过去。关联命令是git remote add origin https://example.com/yourname/my-demo-project.git git push -u origin mainorigin是一个别名代表“远程仓库”。git remote add origin就是在本地记录一个远程地址的快捷方式后续所有操作都不需要再输入长长的URL。git push -u origin main第一次把本地的main分支推送到远程-u参数设置了上游跟踪关系。设置之后后续在main分支上直接执行git push就能推到对应远程分支。远程仓库地址有HTTPS和SSH两种常见协议在本地配置好私钥的情况下SSH方式不用每次输入密码。这个配置和具体平台相关对着平台帮助文档走一遍即可原理上都是在本地~/.ssh目录存好人钥对再把公钥填到平台后台。第一次推送遇到最多的问题是“远程仓库里已经有文件了”。平台创建仓库时往往会自动生成README、LICENSE等初始化文件导致本地和远程各自有一套互不相关的历史。直接push会被拒绝必须先拉取合并。此时如果报错提示“unrelated histories”两套历史没有共同祖先执行git pull origin main --allow-unrelated-histories--allow-unrelated-histories参数允许两套独立历史强行合并。合并时如果文件没有重叠会直接生成一个合并提交如果重叠并且内容冲突需要手动解决。完成后再执行git push -u origin main就能成功。日常同步代码的标准动作是git pull git push我的习惯是每次准备push之前先pull特别是团队活跃的时候。先看一眼git status如果显示“Your branch is ahead of origin/main”说明本地领先远程若干提交如果显示“Your branch is behind”说明远程有本地没有的提交。behind状态下直接push也可能被拒先pull再push是稳妥的顺序。还要区分两个容易混淆的命令git pull和git fetch。git fetch只把远程新提交拉取到本地不会合并到当前分支git pull是fetch加merge的合体拉下来之后立即合并。想看清楚远程变化再做决定可以先fetch再手动merge更可控。检查远程仓库配置用git remote -v它会列出所有远程仓库的名字和地址。如果发现关联错地址可以删掉重新加git remote remove origin git remote add origin https://example.com/yourname/my-demo-project.git远程仓库地址错了不会污染本地提交历史删掉重加即可不用紧张。4.2 冲突怎么来的多分支修改同一行代码冲突是新手最害怕看到的东西其实它不过是Git在告诉你“两边都动了同一块地方我无法替你决定。”冲突本身不可怕解决完照样正常提交。典型的冲突场景是这样的A和B各自从main分支拉出工作分支A在src/config.js里把数值3改成了4并推送B也在src/config.js里把同一处数值改成了8准备推送。B执行git pull时Git合并发现两边改了同一行不能自动选边于是把决定权交给人。此时B查看git status会看到冲突标记On branch main You have unmerged paths. both modified: src/config.js打开src/config.js内容大致长这样 HEAD const level 8; const level 4; feature/level-update HEAD到之间是当前分支的内容到之间是远程分支的内容。B需要手动决定最终保留哪个值或者合并两种意图然后删掉这三行标记const level 8;保存文件执行git add src/config.js git commitGit会用这次新提交来标记冲突解决完成。注意冲突解决不能只改文件不提交Git需要一次显式提交来结束合并状态。处理冲突的几条建议都是实际踩出来的。第一看到冲突不要慌git status会告诉你所有冲突文件的位置一个一个解决不要同时打开十几个文件处理。第二如果冲突区域你不熟悉优先和写这段代码的人沟通两个人对齐意图再定保留值比自己猜要稳妥得多。第三解决冲突时只修改冲突标记内的部分不要顺手重构别人的代码否则合并记录里会混入无关改动后续回溯历史时很难看。第四解决完一个文件就git add一个全部解决完再commit避免在冲突状态下做出不完整的提交。还有一种常见误会是“merge会冲突pull不会”。其实git pull内部就是fetch加mergepull拉取的时候一样会撞上冲突。唯一的区别是平时pull比显式merge多了一步网络获取。理解这一点就不会再觉得“我明明只pull了一下怎么也要解决冲突”。从团队协作的角度看冲突的发生频率和分支粒度直接相关。主分支越新、分支存活时间越长冲突概率越大。养成长度短、经常同步的习惯冲突次数会显著下降。5. Git避坑指南七个新手翻车现场5.1 改了文件但commit没包含它白改半天现象写了一天代码最后执行git commit -am以为全部提交了。第二天发现新写的文件根本不在版本历史里。原因commit -am的-a参数只对已经跟踪过的文件生效。新文件对Git来说是untracked状态不是“有改动”状态所以-a不会把它纳入提交。解决先git status看哪些文件处于Untracked再显式addgit status git add notes.txt git commit -m 补充说明文件把“新文件要先add”当成肌肉记忆就不会在这类问题上耗时间。5.2 提交信息写错了怎么办现象刚刚commit完发现提交信息少写了一个字或者想补充一个文件进去不想额外生成一条“补提交”记录。原因很多人的第一反应是reset回退再重新提交其实Git有专门机制。解决只改提交信息用git commit --amend -m 修改后的提交信息如果想补文件进上一条提交先add再amendgit add 漏掉的文件.txt git commit --amend -m 完整提交信息这样新文件会并进上一条提交历史里看不出两条记录。注意如果这条commit已经推送到了远程amend会重写历史所有合作方pull后会遇到麻烦。已推送的提交不要用amend宁可新开一条commit。5.3 push被拒远程有我们不知道的新提交现象执行git push时被拒绝提示远程有本地没有的提交。原因远程仓库的main分支已经被其他人推进过了本地分支落后于它。直接push会让远程分支产生分叉Git默认拒绝这种非快进推送。解决先把远程改动拉下来合并再推送git pull # 如果有冲突解决后先add再commit git push这条链路能覆盖大部分场景。远程提示的错误信息里会提到“non-fast-forward”看到它就按这个流程处理。有一种比较危险的替代方案是git push -f强制覆盖远程分支但会把远端已有提交直接抛弃风险极大没有十足把握不要用。5.4 误删了未提交的文件现象手滑删了一个文件但内容还没提交甚至可能还没add过。刷新目录一看文件不见了当场愣住。原因Git能恢复的是“进入过版本库”或“进入过暂存区”的内容。从未被Git察觉过的文件对它来说等于不存在误删后确实无法找回。解决如果文件已经提交过用git checkout HEAD -- 误删文件.txt如果文件add过但没commit也可以从暂存区恢复git checkout -- 误删文件.txt这两个命令都会从对应的“快照”里把文件恢复到工作区。如果文件完全没add过那就真没了。所以临时文件、重要笔记先add一下哪怕不commit也算进了Git的视野。5.5 .gitignore失效日志文件被提交了几百MB现象项目里node_modules目录、日志文件、本地缓存被提交到了版本库仓库体积越来越大克隆一次要花很久。原因没有及时的.gitignore或者.gitignore写在了错误的位置。还有一种情况文件已经提交入库了后期才补.gitignore此时Git已经“认识”这个文件忽略规则对已跟踪文件不生效。解决在项目根目录新建.gitignore文件写入忽略规则node_modules/ *.log .DS_Store dist/ .env保存后执行git status确认这些文件不再出现在变更列表。如果文件已经入库需要先把它们从版本库“移除但保留磁盘文件”git rm -r --cached node_modules git commit -m 移除不应跟踪的目录--cached表示只在版本库里删除工作区文件原封不动。这个操作能把已经误入库的大目录清出历史但历史提交里其实还留着它们要想彻底从历史中抹掉需要另一个高级操作不在这里展开。最省心的思路是项目刚创建时就配好.gitignore不求后来补。5.6 分支搞混了改动在错误的branch上现象本来应该在feature/login分支写登录功能结果发现自己在main分支上写了一下午代码都在main的工作区里。原因创建分支前忘了切换或者切分支后没注意到当前分支名。解决利用stash打一套组合拳git stash git switch feature/login git stash pop工作区改动被暂存起来切到正确分支后再放出来。如果放出来有冲突解决后提交。这套操作不会复制文件也不会留下脏提交记录。如果已经commit在错误的main分支上了可以把它挪到正确分支git branch feature/login # 在main当前提交位置创建新分支 git reset --hard HEAD~1 # main回退到上一个提交 git switch feature/login # 切到新分支注意这个操作的前提是main还没推送远程推了之后历史就千万不能这样改。想救回被reset --hard丢掉的提交第6章的reflog是后悔药。5.7 git log退不出来现象执行git log后内容一页一页显示按下什么键都退出不了甚至以为终端卡死了。原因git log默认进入了分页器less。在less界面里q键才是退出CtrlC不是退出分页器新手容易误解为窗口失去响应。解决按q键退出。想减少输出长度用git log --onelinegit log --oneline会让每条提交只占一行输出更紧凑。记住less和vim是两套快捷键体系q和:wq不要搞混。6. 进阶技巧用rebase整理历史与reflog后悔药6.1 交互式rebase把提交历史理成一条线分叉合并多了以后历史和毛线团一样不利于回溯。想要干净的历史可以用rebase把一串提交重新整理git rebase -i HEAD~3HEAD~3意思是最近三条提交。执行后会打开一个交互编辑器列出三条提交的操作清单。把某条提交前的pick改成squash保存退出这条提交就会被并入上一条历史从三条变成两条甚至一条。rebase本质上在重建提交历史所以操作前务必确认这几条提交只存在于本地没推送到远程。已经共享的分支不要乱rebase会让队友的本地历史错乱。想保险的话操作前先建一个备份分支什么都不影响。6.2 reflog你最后的后悔药如果reset、rebase都玩砸了甚至“提交丢了”也不要第一时间绝望。Git里还有一个本地日志叫reflog记录着头指针HEAD每一次移动的痕迹。git reflog输出里能看到类似这样的记录a3f2b8c HEAD{0}: reset: moving to a3f2b8c d1e9f70 HEAD{1}: commit: 添加用户认证模块 f4c2a1b HEAD{2}: commit: 初始提交每一行都是HEAD曾经停留过的地方。无论你是reset跑偏、rebase改乱、还是误删了分支只要在reflog里找到想要的那一行执行git reset --hard commit hash就能把你送回那个时间点。reflog的默认保留期在90天左右并且只在本地生效。只要你不专门清理.git目录这段时间内多数操作都能找回。我自己有一次在模拟项目X上把rebase玩坏了三个提交乱成一团同事在旁边催着要演示。当时第一反应不是重写代码而是git reflog两分钟找回靠的就是这条兜底。现在每次做高危操作前我都会顺手看一眼reflog确认自己的“后悔药”在保质期内。希望帮到你。本文还有配套的精品资源点击获取