简介面向零基础开发者的Git入门教程以PDF文档形式呈现共1个PDF文件大小3.05MB轻量易携带。教程从Git诞生历史切入解释其版本控制与分布式两大特点随后逐步演示Windows安装、git init创建仓库、git add与git commit提交版本、git log查看记录、git reset --hard回退版本等高频命令并对HEAD^、HEAD~n等指针含义做了通俗解读。内容还细致对比了工作区、暂存区与版本库的关系配以code.txt、code2.txt等具体操作示例帮助读者理解为什么Git要分两步提交。作为「最详细、最傻瓜」式教程它基本不需要前置经验跟着命令敲一遍即可掌握日常版本管理流程适合自学、教学或作为随查手册。文档排版清晰命令与示例配合读者可边看边操作快速建立起对Git的整体认识。目前已有10872人学习下载是一份经过多人验证的实用入门资料。1. git使用教程最详细、最傻瓜先弄懂它到底帮你干什么很多人把「git使用教程」搜成一本命令词典背了一堆命令回到项目里还是不知道第一步敲什么。「最详细、最傻瓜」这六个字是我写这篇的起点也是新人和半熟手最容易踩的误区——Git 根本不是靠背命令学会的它只是给代码拍连续快照的工具每个 commit 是一张能回退的照片而 clone、push、merge、status 这些动作都只是在照片之间搬东西。这篇教程不追求命令全家桶只带你从零装好、配好、提交、推到远程、合并分支再把最容易翻车的场景一个个拆开。适合刚接触 git、搜「git怎么用」的新手也适合已经会 commit 但搞不清分支合并和撤销逻辑的熟手。读完你可以照着敲也能在出错时知道去哪查。2. 装好 Git 并完成第一份配置从零到能连远程仓库2.1 安装路径Windows 别漏 PATHmac 和 Linux 一行命令搞定Windows 用户去官网下载安装包国内网络慢的话可以直接搜 git 国内镜像选一个标着 msys64 字样的 exe 文件下载。双击之后的安装过程基本都是「下一步」但有一个关键选项必须看清楚Select Components 之后会问 PATH 怎么配一定选第二项「Git from the command line and also from 3rd-party software」。这一步没选对后面在 PowerShell 里敲 git 就会报「无法识别」也就是热搜里那条经典的报错。装完别急着关窗口先把终端git bash 或 PowerShell重新开一个验证版本并写入第一份全局配置git --version git config --global user.name 你的名字 git config --global user.email 你的邮箱 git config --global init.defaultBranch main四条命令的作用分别是确认安装成功、设置提交时显示的作者名、设置作者邮箱、把新建仓库的默认分支名定为 main旧版本默认叫 master现在新项目统一用 main 更省事。Mac 在终端里执行brew install gitUbuntu/Debian 执行sudo apt install git后同样跑一遍上面四条命令。验证 git 是否装好只看git --version有没有输出版本号——这一步没通过后面所有操作都无从谈起。2.2 第一次运行前必做的三个配置作者身份、默认分支、换行符Git 每次提交都会记录「谁在什么时候写了什么」这个「谁」就来自 user.name 和 user.email。忘记配置的后果是提交记录显示一堆 unknown或者 push 到远程时被拒。填错了也不要紧后面随时用git config --global重跑覆盖。换行符是我建议你第一次就定下来的配置。Windows 的文本换行是 CRLFLinux 和 Mac 是 LF两者混用会导致 git diff 显示整个文件被改动。我一般建议git config --global core.autocrlf input这个值的意思是提交时把 CRLF 转成 LF 存进仓库checkout 到本地时不再强制转换。如果你不确定选什么input是对跨平台团队最友好的方案。Windows 上也有很多人选true它的行为是提交转 LF、检出转 CRLF——对只用 Windows 的团队够用但仓库里一旦出现 LF 换行的文件diff 还是会花眼。2.3 配置 SSH 免密与远程仓库密钥远程仓库如果走 HTTPS每次 push 都要输账号密码Windows 还会时不时弹一个凭据窗口点错就白给。我个人的做法是一律用 SSH。现在 GitHub、Gitee 都支持 ed25519 密钥生成和配置都不复杂ssh-keygen -t ed25519 -C 你的邮箱 cat ~/.ssh/id_ed25519.pub第一条命令生成密钥一路回车即可不需要设口令第二条输出公钥内容。把公钥完整复制到你的 Gitee 或 GitHub 账号设置里找到「SSH 公钥」入口粘贴保存。验证是否连通ssh -T gitgitee.com看到「Hi xxx! Youve successfully authenticated」就说明通了。以后 clone 仓库就用git clone gitgitee.com:用户名/仓库名.gitpush 和 pull 都会自动走免密。SSH 认证失败那条热门报错绝大多数就是这一步没做完整第 5 章我会把排查过程拆开讲。3. 本地跑通最小提交流程从 init 到 push 的完整命令链3.1 从 git init 到 git commit暂存区不是黑匣子Git 的最小工作单元其实只有几个工作区、暂存区、本地版本库。工作区是你能看到的文件暂存区是「准备提交但还没提交」的中间状态版本库存的是拍好的快照。很多新手不理解为什么要有 add 这一步——直接把文件从工作区送进版本库不就完了答案是add 让你可以挑着提交改坏了 3 个文件只想提交修复完成的那个每次都全量提交会让历史变成一团乱麻。mkdir demo cd demo git init echo 第一次提交 readme.md git status git add readme.md git commit -m docs: 提交 readmegit init是把这个目录变成仓库git status随时看当前状态这是所有 git 命令里使用频率最高的一条git add readme.md只把 readme.md 放进暂存区git commit -m把暂存区内容固化成一次提交。提交后再跑一次git status你会看到工作区干净了——这就是一次完整的最小循环。这里有个常见误解git commit只会提交暂存区里的东西。你改了文件但不 addcommit 半天提示 nothing to commit就是这个原因。养成习惯commit 前先 git status确认哪些文件进了暂存区再动手。3.2 推送到远程并从远程拉更新push 和 pull 的先后顺序本地仓库和远程仓库不是同步的理解这一点能省掉很多莫名的报错。git push是把本地提交推上去git pull是把远程的新提交拉下来它们之间还有一种「别人已经推过、你本地落后」的状态。第一次推送到远程的完整路径git remote add origin gitgitee.com:用户名/demo.git git push -u origin main第一条命令给本地仓库绑定一个远程地址名字叫 origin这是约定俗成的称呼不是强制第二条把本地 main 分支推上去-u的意思是记住这次推送的参数以后直接git push就能推到同一条分支。拉更新我一般建议先处理干净本地git status确认没有未提交的改动后再git pull。如果本地有未 commit 的修改pull 又正好动到同一个文件Git 会拒绝合并报错提示你要么 commit 要么 stash。这时候先 commit 比 stash 好——stash 是把改动藏到一边很多人藏完就忘了过两周发现改动丢了。3.3 分支的新建、合并与删除分支是 Git 最值得学的功能也是很多「半熟手」第一次翻车的地方。分支的本质是一个可移动的指针指向某次提交新建分支只是新建一个指针不会复制文件所以创建分支的成本极低。git branch dev git switch -c dev # 在 dev 上提交一些改动 git commit -m feat: 开发新功能 git switch main git merge dev git branch -d devgit branch dev创建分支git switch -c dev创建并切过去等于两条命令合成一条在 dev 上做完提交后切回 maingit merge dev把 dev 的提交融入 main确认没问题后git branch -d dev删除分支。合并这件事很多人理解反了——它不是「把 dev 复制到 main」而是「把 main 指向 dev 或新增一个合并提交」。如果 main 从创建 dev 之后就没动过Git 会直接把 main 快进到 dev 的提交上这叫 fast-forward。如果 main 也有新提交Git 就会生成一个 merge commit把两条分支的历史接在一起。提示切换分支前一定要git status。分支没提交的改动会跟着你「漂移」到另一个分支这是新手最容易撞到的玄学问题——在 dev 改的代码切回 main 居然还在。4. 后悔药与合并现场commit 改错、分支合错的参数详解4.1 改上一次提交信息git commit --amend 的三种常见用法热搜里常出现「git commit --amend 怎么使用」因为它确实是使用频率最高的「后悔药」。它的作用不是新建一个提交而是把上一次提交替换掉常用于三种场景提交信息写错了、忘了把某个小改动包含进去、想少一次提交让历史更干净。git commit --amend -m feat: 修正后的提交信息第一种场景一行命令解决。注意-m会直接把提交信息替换成新内容不需要先 reset 再重新 commit。git add 漏掉的文件 git commit --amend --no-edit第二种场景把文件 add 之后带上--no-edit表示保留原来的提交信息只是把新文件并入上一次提交——这样就不会出现「改个标点还要单独提交一次」的碎片历史。第三种场景要小心如果你已经 push 到了远程--amend会把本地提交的哈希值整个换掉远程还是旧的那个下次 push 就会提示分叉。处理方式要么是git push --force-with-lease比 --force 安全推送前会检查远程是否有别人推过新东西要么干脆别 amend 已经公开的提交。提示--force-with-lease不是万能的它只能检查你上次拉取时的远程状态。别人在那个基础上推了新提交它照样会拒绝——拒绝其实是好事强制推送他人的提交属于团队事故级别。4.2 撤销本地改动reset 与 restore 的边界撤销是 Git 里最容易混淆的一块因为旧教程混用了 checkout、reset、revert 三个命令干同一件事。现代 Git 已经拆清楚了restore 负责「撤销改动」reset 负责「移动指针」revert 负责「新增一个反向提交」。git restore --staged readme.md # 取消暂存保留工作区改动 git restore readme.md # 丢弃工作区改动回到暂存区内容 git reset --hard HEAD~1 # 本地回退一次提交丢弃改动第一条常用于你 add 错了文件第二条常用于改了一团乱想放弃第三条是「回到上一次提交」的硬回退只对本地自己一个人使用的分支安全。边界在于git restore最后那个不带参数的形式是从暂存区恢复文件如果你修改文件后既没 add 也没 commit它能救你如果已经 add 了必须先--staged再 restore。--hard更危险它把暂存区和工作区一起丢掉丢掉的改动没法从工作区找回来。给自己留后路的做法是回退前先看一眼git reflog——记录里能找到你误删的提交哈希关键时刻能捡回半条命。4.3 merge 和 rebase先会合再谈历史整洁团队协作里合并分支是每天的常规动作。Git 提供 merge 和 rebase 两条路merge 保留「真实发生的分叉与合并」rebase 把一条分支的提交挪到另一条分支的顶端让历史看起来像一条直线。我自己的建议是新人优先用 merge先不碰 rebase。原因是 merge 出错时可以完整查看分叉结构冲突解决后不会改写其他人的提交历史rebase 改写的是你自己的提交哈希一旦中途冲突处理起来比 merge 多一层心智负担。git switch main git pull git switch dev git rebase main如果团队约定用 rebase 保持 main 的线性历史这也是合法的。但 rebase 有一个绝对红线只能重写从未推送过的本地提交。已经推送到远程的提交被 rebase别人 pull 时会直接裂开。你记不住这一条就永远只对本地分支用 rebase。5. Git 命令使用常见问题与避坑实录五条新手翻车现场5.1 fatal: not a git repository (or any of the parent directories): .git现象在任何目录敲git status或git push报这行 fatal。搜这个报错的人特别多说明它不是个别问题。原因你当前所在目录不在任何 Git 仓库里。常见场景是 cd 进了某个子目录而这个子目录不是仓库根目录或者整个目录就不是 clone/init 出来的。解决先pwd确认自己在哪ls -a看有没有.git目录cd回到仓库根目录再试。更快的定位方式是git rev-parse --show-toplevel它能直接输出当前仓库的根路径比肉眼找目录快得多。5.2 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称现象Windows 上打开 PowerShell 敲 git 命令报这一长串中文提示。原因安装 Git 时在 PATH 配置那一步选了「Use Git from Git Bash only」或者用了绿色便携版导致 cmd 和 PowerShell 找不到 git 的可执行文件。解决最保险的方法是重新运行安装包把这一个选项改成「Git from the command line and also from 3rd-party software」。改完后必须完全关闭并重开终端——环境变量只在进程启动时读取一次重开前敲再多命令也没用。手动加 PATH 也可以但 Windows 的 PATH 编辑容易手滑删掉别的路径新手不值得冒这个险。5.3 SSH 认证失败Permission denied (publickey)现象push 的时候报Permission denied (publickey)后面跟着fatal: Could not read from remote repository.。原因SSH 密钥没配对。要么公钥没添加到 Gitee/GitHub 账号要么本地生成的密钥和远程仓库不属于同一个账号要么多密钥环境下 SSH 客户端选了错误的密钥文件。解决先跑ssh -T gitgitee.com看具体返回值再确认~/.ssh/id_ed25519.pub的内容和你账号后台粘贴的完全一致如果有多份密钥需要在~/.ssh/config里给对应域名指定IdentityFile。对大多数新电脑按第 2 章的ssh-keygen流程重走一遍90% 的问题都能消除。5.4 合并冲突满屏分隔线 HEAD 与 现象merge 或 pull 之后打开文件看到 HEAD、、三行分隔符中间是两段不一样的代码。原因两个分支改动了同一个文件的同一个区域Git 无法自动判断谁是对的只好把两个版本都摆出来让你选。解决没有银弹只能人工取舍。打开文件删掉保留版本之外的所有代码与分隔线最后git add这个文件再git commit结束合并。如果你想偷懒全取某一侧可以用git checkout --ours保留当前分支或git checkout --theirs保留对方分支。冲突看着吓人实际只是 Git 在行使「不敢替你决定」的职责——比它偷偷覆盖掉你一行代码要安全得多。5.5 推送时账号密码弹个没完或换账号后身份残留现象走 HTTPS 时每次 push 都弹窗要密码换了一个仓库账号后弹窗还是要求旧账号的密码。原因Windows 凭据管理器缓存了旧的 git 凭据域名不变的情况下它会一直用缓存里的身份。解决打开「控制面板 → 凭据管理器 → Windows 凭据」搜 git 相关的条目删除或者用命令行一句处理cmdkey /delete:git:https://gitee.com删掉后重新 push它会让你再输一次新账号密码并重新缓存。想要一劳永逸还是回到第 2 章配 SSH——凭据管理器这件事本身就是 Windows 用户最常见的暗坑。6. 让 Git 每天用得更顺手alias、worktree 与固定习惯6.1 把高频命令缩成三个字母我每天用 Git 的时间大头都在看状态、看差异、看历史。这三条命令频率极高值得配成 alias。Git 自带别名机制配置一次全局有效git config --global alias.st status git config --global alias.df diff git config --global alias.lg log --oneline --graph --decorate --all git config --global alias.co checkout配置后git st等于git statusgit lg直接看一张带分支线的提交图谱。别名是纯个人偏好不影响仓库内容也不影响团队其他人。我的经验是别名不要配太多超过五个反而要回忆别名对应哪个命令不如直接敲全称。6.2 用 git worktree 同时开多个分支告别切换翻车频繁在分支之间 switch最烦的是「本地有未提交改动不让切」或者「带着改动切过去污染另一个分支」。我的方案是用git worktree让每个分支拥有独立的目录互不干扰。git worktree add ../demo-fix main这条命令会在上一级目录生成一个 demo-fix 文件夹里面是一个连接到当前仓库、且工作分支为 main 的完整工作区。需要修紧急 bug 时切到另一个分支开一个 worktree修完合并回来原来分支上的开发完全不用动。查看和管理已开的工作区用git worktree list和git worktree remove。6.3 三个我固定下来的操作习惯提交信息坚持写「类型: 描述」的格式feat 表示新功能fix 表示修 bugdocs 表示文档改动。虽然 Git 不校验但三个月后回头看历史这个格式能让你一眼定位任何一次改动。每次 pull 之前先git status确认工作区干净如果不干净先 commit 再 pull。很多人翻车都是因为工作区有杂物时直接 pull冲突信息跳出来一头雾水。最后一条提交前看一眼git diff。这条命令显示的是「当前改动 vs 已暂存内容」的差异能帮你发现调试时留下的 console.log 和临时修改。养成这三个习惯之后我几乎再没遇到过需要到处搜报错的紧急情况——这不代表 Git 不再出错而是错误发生时我能立刻知道根因在哪一层。希望这篇 git 使用教程能让你的命令敲得少一点、心里有底一点也祝你在 repo 林立的工作里每次 commit 完都能睡个好觉。本文还有配套的精品资源点击获取