企业官网建设流程全解析

简介：面向零基础开发者的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 别漏 PATH，mac 和 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 git，Ubuntu/Debian 执行sudo apt install git后同样跑一遍上面四条命令。验证 git 是否装好，只看git --version有没有输出版本号——这一步没通过，后面所有操作都无从谈起。

2.2 第一次运行前必做的三个配置：作者身份、默认分支、换行符

Git 每次提交都会记录「谁在什么时候写了什么」，这个「谁」就来自 user.name 和 user.email。忘记配置的后果是提交记录显示一堆 unknown，或者 push 到远程时被拒。填错了也不要紧，后面随时用git config --global重跑覆盖。

换行符是我建议你第一次就定下来的配置。Windows 的文本换行是 CRLF，Linux 和 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 git@gitee.com

看到「Hi xxx! You've successfully authenticated」就说明通了。以后 clone 仓库就用git clone git@gitee.com:用户名/仓库名.git，push 和 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: 提交 readme"

git init是把这个目录变成仓库；git status随时看当前状态，这是所有 git 命令里使用频率最高的一条；git add readme.md只把 readme.md 放进暂存区；git commit -m把暂存区内容固化成一次提交。提交后再跑一次git status，你会看到工作区干净了——这就是一次完整的最小循环。

这里有个常见误解：git commit只会提交暂存区里的东西。你改了文件但不 add，commit 半天提示 nothing to commit，就是这个原因。养成习惯：commit 前先 git status，确认哪些文件进了暂存区再动手。

3.2 推送到远程并从远程拉更新：push 和 pull 的先后顺序

本地仓库和远程仓库不是同步的，理解这一点能省掉很多莫名的报错。git push是把本地提交推上去，git pull是把远程的新提交拉下来，它们之间还有一种「别人已经推过、你本地落后」的状态。第一次推送到远程的完整路径：

git remote add origin git@gitee.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 dev

git branch dev创建分支；git switch -c dev创建并切过去，等于两条命令合成一条；在 dev 上做完提交后切回 main，git 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 git@gitee.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 status，git 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 表示修 bug，docs 表示文档改动。虽然 Git 不校验，但三个月后回头看历史，这个格式能让你一眼定位任何一次改动。

每次 pull 之前先git status确认工作区干净；如果不干净，先 commit 再 pull。很多人翻车都是因为工作区有杂物时直接 pull，冲突信息跳出来一头雾水。

最后一条，提交前看一眼git diff。这条命令显示的是「当前改动 vs 已暂存内容」的差异，能帮你发现调试时留下的 console.log 和临时修改。养成这三个习惯之后，我几乎再没遇到过需要到处搜报错的紧急情况——这不代表 Git 不再出错，而是错误发生时，我能立刻知道根因在哪一层。

希望这篇 git 使用教程能让你的命令敲得少一点、心里有底一点；也祝你在 repo 林立的工作里，每次 commit 完都能睡个好觉。

本文还有配套的精品资源，点击获取