企业官网建设流程全解析

我最早开始用 Git，其实是踩了一鼻子灰的。那时候刚进团队，同事丢给我一个仓库地址，让我把代码拉下来。我顺手点了网页上的 Download ZIP，解压、改代码、又手动打包发回去，被老大当着全组的面教育了一顿。那会儿我才意识到，Git 不是用来“下载代码”的，它是用来管理代码版本、协作开发的一套完整工具链。而现在网上的 Git 下载安装教程，要么写得太简略，新手装到一半就卡住；要么只讲命令不讲原理，装了等于白装。

这篇我尽量按“保姆级”的标准来写，从下载安装、初始化配置、常用命令，到 Gitee/GitHub 密钥配置，再到一些容易被忽略的底层参数，一次讲透。不管你是完全没装过 Git 的小白，还是已经装了但用起来不顺手的同学，这篇都值得从头到尾过一遍。

1. 安装之前，先把 Git 到底是什么这件事弄清楚

很多人一上来就急着装软件，装完发现还是不会用，问题往往出在“没搞懂 Git 在解决问题时采用的思路”。所以在我带新人时，会花十分钟先把核心概念讲明白，磨刀不误砍柴工。

1.1 什么是版本控制，Git 和 SVN 有什么本质区别

版本控制的本质，是给文件留“后悔药”。想象一下你在写 Word 文档，每写一段就另存为一个新文件：论文终版.doc、论文终版2.doc、论文最终版不改了.doc。这种做法在单个文件时还能撑住，一旦换成几十个工程师同时改几千个文件，马上就会失控。版本控制工具干的事情，就是替你自动完成这些“存档”，并且能随时对比任意两次存档之间的差异。

Git 和早期 SVN 最大的区别在于“分布”。SVN 是集中式管理，所有历史记录都存在中心服务器上，你本地只有一份工作副本，一旦服务器挂了或者网络不通，整个团队都动不了。而 Git 每个开发者本地都有一份完整仓库，包括全部历史提交记录。这意味着你断网了也能正常提交代码，等联网时再推送到远端。这个设计来自 Linux 内核社区的经验：Linus Torvalds 当年开发 Git，就是因为社区提交量大、地域分散，需要一个不需要总连中心也能协作的系统。

分布式带来的另一个好处是安全。如果远端服务器硬盘坏了，只要任何一个人的本地仓库还在，就能完整恢复全部代码和历史，这比集中式系统容错强得多。

1.2 四个关键区域的工作流程：工作区、暂存区、本地仓库、远程仓库

Git 里最需要搞清楚的，就是文件在四个区域之间的流转关系。我用一个生活比喻：你做菜的时候，原材料堆在案板上（工作区），挑选好的配菜放到碗里（暂存区），正式下锅出锅装盘（本地仓库），最后端到餐厅展示给客人（远程仓库）。

具体到操作：

• 工作区：你电脑上实际看到的文件目录，在这里随便改，Git 不会管你。
• 暂存区（Index/Stage）：执行 git add 后文件进入的区域，相当于提前选好“准备提交哪些改动”。
• 本地仓库：执行 git commit 后，改动被打包成一次永久记录，存储在你电脑的 .git 目录里。
• 远程仓库：执行 git push 后，本地记录同步到 Gitee/GitHub/GitLab 等服务器上，团队其他成员才能看到。

新手最容易犯的错，是以为 git add 之后文件就已经“存好了”。实际上只有 commit 之后才算真正生成了历史记录。而 push 则负责把记录同步出去。理解了这个流程，后面所有命令就都好学了。

1.3 为什么我建议新手都用命令行，而不是只依赖图形工具

现在有很多好用的图形工具，比如 SourceTree、Tower、VS Code 自带的 Git 面板，界面友好，点几下按钮就能完成操作。但我带过几十个新人，有一个经验比较确定：第一遍学 Git，必须用命令行过一遍。原因有三个。

第一，命令行能看到完整的过程输出。比如推送到远端失败，命令行会明确告诉你“Permission denied”还是“failed to push some refs”，图形工具往往只弹一个模糊的错误提示。第二，命令行是唯一能覆盖所有 Git 功能的入口。图形工具菜单有限，很多高级操作（比如交互式 rebase、git filter-branch）压根没有按钮。第三，面试和线上服务器排障时，你面对的往往是纯终端环境，没有图形界面可用。

当然，日常开发中我用图形工具做代码审查和 diff 对比，但执行关键动作时，还是习惯敲命令。这篇教程也统一用命令行演示，因为命令行最通用、最本质。

2. 保姆级 Git 下载安装全流程：Windows、macOS、Linux 都照顾到

下面进入正题，下载安装。考虑到社区里 Windows 用户最多，我会重点拆解 Windows 的安装细节，macOS 和 Linux 单独用一节交代清楚。

2.1 下载前先确认的 3 个信息，避免装错版本

下载安装前，花 30 秒确认下面三个信息，能省掉后面一堆麻烦。

第一，操作系统位数。Git 官方提供 64 位和 32 位安装包，绝大多数电脑都是 64 位。怎么看：Windows 下按 Win + Pause 键（或者“设置-系统-关于”），查看“系统类型”；macOS 在“关于本机”里看芯片类型，是 Apple Silicon 还是 Intel 也决定了部分安装方式。

第二，选择哪个安装包。Git 官网（git-scm.com）主页会自动检测你的操作系统，显示对应的下载按钮。Windows 用户认准 “Windows” 字样，进去后选择 “64-bit Git for Windows Setup” 这种完整版安装包。不要选 “Portable” 便携版，那适合免安装的场景，对新手不友好。

第三，下载源的选择。官网仓库在 GitHub 上托管，如果你下载速度很慢，可以换成国内镜像，比如淘宝 npm 镜像站、华为云镜像站，都有 Git 的 Windows 安装包镜像，下载速度快很多，版本更新也基本同步。我个人习惯用官网，但下载超时就切镜像，几分钟装完不纠结。

2.2 Windows 安装过程逐项拆解，每个选项都讲清楚

安装包下载好之后，双击开始安装。网上很多教程直接让你“一路 Next”，但里面有几个选项直接影响后续使用体验，我逐个说下怎么选。

安装过程中会连续蹦出好几个配置页面，比较关键的是这几项：

Select Components（选择组件）：默认选项基本合理，但建议额外勾上 “Git Bash Here” 和 “Git GUI Here”，这两个会在鼠标右键菜单里添加入口，在任意文件夹里右键就能打开 Git 终端，非常方便。

Default editor（默认编辑器）：Git 在提交代码时需要你填写提交说明，这时会唤起一个文本编辑器。默认是 Vim，对新手来说简直是噩梦，进去之后连怎么退出都不知道。建议直接选 “Use Visual Studio Code as Git's default editor”，前提是你电脑装了 VS Code，没有的话选 “Use Notepad++” 或系统自带记事本也行。

Adjusting your PATH environment（环境变量）：这里强烈建议选中间项 “Git from the command line and also from 3rd-party software”。选了它，Git 才会被写进系统 PATH，这样你在任何终端窗口输入 git 命令都能被识别。如果选了第一项，只能从 Git Bash 里用 Git，命令行用不了，非常难受。

Checkout line endings（行尾换行符转换）：Windows 和 Unix 系统在换行符上不一样，Windows 是 CRLF，Linux/macOS 是 LF。这里保持默认的第一项 “Checkout Windows-style, commit Unix-style line endings” 即可。它会在拉取代码时把 LF 转成 CRLF，提交时再转回 LF，最大程度避免团队协作时换行符引起的差异问题。

其余页面按默认走就行。等安装完成，打开任意终端，输入下面的命令验证版本：

git --version

能正常输出 git version 2.x.x 之类的信息，说明安装成功。如果提示 “git 不是内部或外部命令”，说明 PATH 那一步你选错了，或者安装后没有重开终端。重开终端一般能解决，如果还不行，就手动把 Git 安装目录下的 cmd 路径加进系统环境变量（比如 C:\Program Files\Git\cmd）。

2.3 macOS 和 Linux 的安装方式，比想象中简单

macOS 用户上手 Git 比 Windows 简单。如果之前装过 Xcode Command Line Tools，系统可能已经自带了 Git，可以先在终端里输入 git --version 试探一下。没有的话，在终端执行：

brew install git

前提是装过 Homebrew 包管理器，没装的话先去官网按提示装 Homebrew。装完同样执行 git --version 验证。

还有一种更省事的方式，直接去 git-scm.com 下载 macOS 安装包，图形化安装，双击即可完成，适合不想折腾的人。

Linux 用户则看发行版。Debian/Ubuntu 系执行：

sudo apt update sudo apt install git -y

CentOS/RHEL/Fedora 系执行：

sudo yum install git -y

新版 Fedora 用的是 dnf，写成 sudo dnf install git -y 也行。Linux 用户注意一点：不要从源码编译安装，包管理器的版本足够用了，除非你对版本有特殊需求。

3. 安装成功后必做的初始配置，以及最常用的核心命令

安装完成只是万里长征第一步。Git 刚装好时像一个不认识你的陌生人，你得先告诉它“你是谁”，它才会在提交记录里正确署名。这一章讲的配置和命令，是每天开发都会用到的，我尽量压缩到最少但最实用。

3.1 先配好 user.name 和 user.email，否则提交报错

打开终端（Windows 用 Git Bash 或者 cmd 都行），依次执行下面两条命令：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

--global 的意思是对当前电脑上的所有仓库生效。把名字和邮箱换成你自己的，比如：

git config --global user.name "zhangsan" git config --global user.email "zhangsan@example.com"

这里有个细节：邮箱最好和你的 Gitee/GitHub 账号邮箱保持一致，这样提交记录才能正确关联到你的账号头像上，不然远端仓库里会显示成一个独立的灰色用户。

怎么确认配置生效了？执行：

git config --global --list

屏幕上会列出你刚配置的信息。有人会问，能不能不配？不能。如果你跳过这一步直接 commit，Git 会报错：Please tell me who you are，然后教你怎么执行命令，但报错信息对新手不太友好。所以装完第一件事，先配身份。

3.2 五个命令体验一次完整的 Git 工作流程

配置完成后，强烈建议新建一个练习目录，把核心流程走一遍。我用 /tmp/git-demo 举例，你换成自己的路径就行：

mkdir git-demo cd git-demo git init

git init 的作用是把当前目录初始化为 Git 仓库。执行后目录下会多出一个隐藏的 .git 文件夹，里面存着 Git 的全部“大脑”，别进去乱删。

接着新建一个文本文件：

echo "hello git" > demo.txt git status

git status 会告诉你当前仓库的状态：demo.txt 是 Untracked（未跟踪）文件。这时执行：

git add demo.txt git commit -m "first commit"

git add 把文件加入暂存区，git commit 生成一条历史记录。再执行 git log 查看提交记录：

git log --oneline

能看到类似 e3a5f9b (HEAD -> master) first commit 的一行输出，说明第一次提交成功了。这五个命令（init/status/add/commit/log）构成了 Git 使用最基础的工作闭环，后面不管操作多复杂，底层都是这几个动作的组合。

3.3 后悔药专题：git commit --amend 到底怎么用、什么时候用

前面热词里有个 “git commit --amend 怎么使用”，我判断这是很多新手特别关心的点。简单说，git commit --amend 的作用是修改最近一次提交。注意两个使用场景。

场景一，提交后发现漏了文件。比如刚才提交了 demo.txt，但你又新建了一个 readme.md，希望它并进上一条提交里，而不是生成一条新提交。操作方式是：

git add readme.md git commit --amend -m "first commit，包含readme"

执行后，刚才那次提交会被“改写”，新的提交里同时包含 demo.txt 和 readme.md，历史记录里不会出现两条提交。

场景二，提交信息写错了。比如把 “fix bug” 写成了 “fxied bug”，直接执行：

git commit --amend -m "fix bug"

就能把提交信息改过来，而不产生额外记录。请注意一个关键前提：--amend 只适合修改“还没有推送到远端”的本地提交。如果你的提交已经 push 到公共分支，并且团队其他成员已经拉取过，再用 --amend 改写历史，会造成大家仓库不一致，非常麻烦。这在多人协作时，是仅次于强制推送的一大坑。所以我的习惯是：git push 之前，先把本地提交检查清楚，需要合并修改就先用 amend 处理。

3.4 分支操作：branch、checkout、merge 三个命令快速上手

分支是 Git 的核心能力，也是和 SVN 拉开差距的地方。什么叫分支？你可以理解为平行宇宙：在主线（master/main）之外，另开一条开发线，在分支上改代码不影响主线，等需求做完再合并回去。

创建分支并切换过去：

git branch feature-login git checkout feature-login

也可以一行搞定：

git checkout -b feature-login

在 feature-login 分支上修改文件、提交，然后再切回主分支：

git checkout master

执行 git merge feature-login 就能把特性分支的改动合并到主分支。如果两个分支改的是同一文件的同一行，会触发冲突，Git 会在文件里用 <<<<<<<、=======、>>>>>>> 标记出冲突区域，你需要手动编辑文件，决定保留谁的改动，然后 git add、git commit 完成合并。

新手学分支，先掌握“建分支、切分支、合并分支”这三个动作就够了。分支命名规范建议用 feature/、bugfix/ 前缀，比如 feature/user-center，这样时间一长你还能一眼看出分支的用途。

4. 配置 Gitee/GitHub SSH 密钥，实现免密拉取和推送

装完 Git、走完基础工作流之后，接下来最重要的就是和远端仓库对接。现在国内最常用的代码托管平台是 Gitee（码云），国际上是 GitHub。不管用哪个，都绕不开一个话题：SSH 密钥。密钥配置好了，以后 push/pull 都不用输入密码，清爽得多。

4.1 为什么要用 SSH 而不是 HTTPS

Git 操作远端仓库有 HTTPS 和 SSH 两种主要方式。HTTPS 的优点是简单，克隆时直接输入账号密码就行；缺点是每次推送都要输入一次凭据，虽然可以靠系统凭证管理器记住，但遇到公司电脑、多账号切换时，体验还是很烦。

SSH 则是用一对钥匙来验证身份：私钥留在你电脑上（相当于钥匙），公钥放到 Gitee/GitHub 上（相当于锁）。连接时，服务器用公钥加密一段随机数据，你的电脑用私钥解密并回传，验证通过就建立连接。整个过程不用输入密码，而且安全性比单纯账号密码更高。

用哪种方式克隆，取决于仓库地址：HTTPS 地址格式是 https://gitee.com/用户名/仓库名.git，SSH 地址格式是 git@gitee.com:用户名/仓库名.git。配置好 SSH 后，记得统一复制 SSH 地址来克隆。

4.2 生成 SSH 密钥对，一条命令搞定

打开 Git Bash（Windows 用户强烈建议用 Git Bash，而不是 cmd，兼容性最好），执行：

ssh-keygen -t ed25519 -C "你的邮箱"

这里选 ed25519 算法，是目前安全性和性能都比较好的新算法。如果你的系统比较老，不支持 ed25519，可以用传统 RSA 算法：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

回车后会问你保存位置，默认在 ~/.ssh/id_ed25519，直接回车。接着会提示你设置 passphrase（口令），这个可以留空直接回车，也可以设置一个——我建议个人电脑上留空，免密登录才够“免密”；公司公用电脑建议设置，多一道防线。

生成完成后，执行：

cat ~/.ssh/id_ed25519.pub

屏幕上会输出一串以 ssh-ed25519 开头、以你的邮箱结尾的文本。这串就是公钥，从头到尾复制它。注意复制的是 .pub 后缀文件的内容，千万别把 id_ed25519（没有后缀的私钥）发给任何人。

4.3 把公钥添加到 Gitee 或者 GitHub

以 Gitee 为例，登录后点击右上角头像——“设置”——左侧菜单“安全设置”——“SSH 公钥”。把刚才复制的公钥粘贴到“公钥”输入框里，“标题”随便填，比如“我的办公电脑”，点击确定。GitHub 的路径类似：Settings -> SSH and GPG keys -> New SSH key，粘贴后保存。

这一步基本不会报错，唯一的坑是粘贴时复制了不完整的字符，或者多了换行。我见过几次这种情况，测试时一直连接失败，重新复制一遍就好了。

4.4 测试连接是否成功，以及常见的两个坑

配置完成后，执行下面命令测试与 Gitee 的连接：

ssh -T git@gitee.com

如果你用的是 GitHub，则执行：

ssh -T git@github.com

首次连接会提示确认主机指纹，输入 yes 回车即可。连接成功时，会输出欢迎信息，比如 Gitee 会提示 “Hi 用户名! You've successfully authenticated, but GIT does not provide shell access.” 这说明密钥已经生效。

常见的坑有两个。第一个是提示 “Permission denied (publickey)”，说明 Gitee/GitHub 上没有正确匹配的公钥，或者你当前 SSH 客户端没有使用默认的密钥文件。可以执行 ls ~/.ssh/ 查看文件是否生成，再用 ssh -vT git@gitee.com 打开调试信息，看到底是哪一步失败。第二个坑是多密钥管理问题：如果你同时有公司 GitLab 和个人 Gitee 的密钥，系统默认只读取 id_ed25519 一个文件，这时候需要在 ~/.ssh/config 文件里配置 Host 映射，让不同域名使用不同密钥文件。这个属于进阶内容，等遇到再折腾也不迟。

5. 隐藏的进阶参数：git -c 开头的命令到底在干什么

前面热词里还有一条非常眼熟的命令：git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks。这行命令一般用户根本不会手敲，但只要你用过某些 GUI 工具，就可能在日志里见过它。这一章我专门拆解这个命令，顺便给你补上 Git 的参数传递机制。

5.1 git -c 的含义：临时修改配置而不写入文件

git config 是持久修改配置，写进全局或仓库级配置文件里。git -c 则是在单次命令执行时临时指定配置项，命令结束后恢复原状，不写入任何文件。它的格式是：

git -c 配置项=值 子命令

可以重复写多个 -c，同时临时指定多条配置。这种做法的好处是不污染全局配置，适合一次性执行特殊操作时使用。上面那条命令一次传递了三个配置项：diff.mnemonicprefix、core.quotepath，以及一个 --no-optional-locks 开关。逐个拆开看。

5.2 三个参数逐个解读：mnemonicprefix、quotepath、optional-locks

diff.mnemonicprefix=false影响的是 git diff 输出里的索引标识。默认情况下，git diff 对比两个文件时，前缀是 a/ 和 b/，比如 --- a/demo.txt、+++ b/demo.txt。开启了 mnemonicprefix 后，会按索引位置改成 i/ 和 w/（index 和 working tree 的缩写），在某些图形工具里显示得更直观。所以 -c diff.mnemonicprefix=false 就是在强制关闭这个带语义的前缀，让输出回归传统的 a/b 形式。一般命令行用户用不到，主要是防止图形工具自动生成的命令。

core.quotepath=false这个参数对中国开发者比较友好。Git 默认会对非 ASCII 字符（比如中文文件名）做转义输出，显示成类似 "\346\265\213\350\257\225.txt" 的八进制编码，很不好看。设置 core.quotepath=false 后，git status、git diff 等命令会直接显示中文文件名，可读性大幅提升。我建议你直接在全局配置里永久开启：

git config --global core.quotepath false

--no-optional-locks是个布尔开关选项，作用是禁止 Git 在执行某些只读命令时自动创建索引锁文件。正常情况下，git status 或 git diff 这些只读命令，为了避免和同时进行的其他 Git 操作冲突，会短暂地拿一个可选的锁。这在命令行交互场景问题不大，但如果某个 GUI 工具频繁调用这些状态命令，可能会因为锁文件导致操作延迟或冲突。加上 --no-optional-locks 后，只读命令不再创建锁文件，从而减少后台操作的干扰，适合工具链高频调用场景。

5.3 什么时候会遇到这种命令，对方想解决什么问题

你可能没有手敲过这种长命令，但在 IDE 集成终端、自动化脚本日志、或 Git 钩子输出里，很可能遇到过类似的命令串。说白了，这行命令是图形工具或脚本在调用 Git 时，为了保证输出格式稳定、避免中文乱码、降低锁冲突风险而追加的保护参数。

理解了它的结构，你的收获不是“照抄这串命令”，而是明白 Git 的参数体系：-c 可以临时覆盖配置，--no-optional-locks 可以调整命令行为。以后遇到别的工具生成的“看不懂的 Git 命令”，你就能自己拆解了。

6. 常见问题排查与避坑实录：我踩过的坑，你就别踩了

最后一个大章，集中回答安装和使用 Git 时最高频的几个问题。这些问题来自我多年带新人的经验，也来自各类技术社区里的高频求助帖。整理成问题速查表，你可以直接拿来当字典用。

6.1 下载太慢或者下载失败怎么办

官网下载太慢是常态，毕竟服务器在海外。解决方案是换国内镜像源，比如淘宝 npm 镜像里就有 Git 安装包的镜像，打开 npmmirror.com/mirrors/git-for-windows/ 就能看到各版本的 Windows 安装包，下载速度能跑到满带宽。另一个思路是使用 npm 自带的安装工具，但那个打包方式对新手不够友好，镜像站直接下 exe 是最快的。

如果下载到一半断了，不用重来，浏览器的断点续传一般会继续。实在不行就换一个网络环境，比如手机热点。这个完全是网络环境问题，跟 Git 本身没关系。

6.2 提示“git 不是内部或外部命令”怎么办

这在 Windows 上很常见。原因是安装时 PATH 选项没选对，或者安装后终端没重启。先彻底关闭所有终端窗口，重新打开一个再试。不行就手动检查环境变量：右键“此电脑”——“属性”——“高级系统设置”——“环境变量”，在系统变量的 Path 里确认有没有 C:\Program Files\Git\cmd。没有就点击编辑，追加进去，然后重新打开终端。

Linux/macOS 上如果提示 command not found，说明包没有安装成功，重新执行对应包管理器的安装命令就行。

6.3 推送时报错 Permission denied (publickey) 怎么排查

这个错误绝大多数情况下都是密钥对不上。按顺序排查：

1. 生成的公钥是否完整复制到了 Gitee/GitHub 上，重新复制一次试试。
2. 本地私钥文件是否存在，默认位置 ~/.ssh/id_ed25519，用 ls ~/.ssh/ 检查。
3. 是否指定了正确的密钥文件，如果 ~/.ssh/config 里配置了多个 Host，确认域名匹配的密钥是正确的。
4. 用 ssh -vT git@gitee.com 开启调试输出，看最后几行日志，通常能看到 “Trying private key: ... /path/to/key” 和结果。

我最常遇到的情况就是第 1 种，复制的时候多复制了一个空格或者漏了几个字符，重新粘贴一遍就能解决。

6.4 git commit 后想反悔，怎么撤回又保留改动

撤回最近的提交但不删除改动，执行：

git reset --soft HEAD~1

这时刚才提交的改动会回到暂存区，你可以重新调整后再次提交。如果想要连暂存状态也取消，改动回到工作区，执行：

git reset --mixed HEAD~1

这是 reset 的默认模式。如果连工作区的改动也想彻底丢弃（危险操作，不会进回收站），执行：

git reset --hard HEAD~1

--hard 是我评分里“谨慎使用”级别的命令。我用 git reset --hard 的次数非常少，每次都是确认自己记得改动内容、且远端已经有备份时才敢用。新手在练习环境随便试没关系，在公司仓库里别轻易用。

6.5 常用 Git 命令速查表

最后放一张我整理的命令速查表，覆盖日常开发 80% 以上的场景，建议保存一份。

6.6 最后分享一个我自己的使用习惯

装完 Git、配好 SSH 之后，我做的第一件事永远是设置全局参数 alias（别名）。比如我用 git st 代替 git status，用 git lg 代替一段冗长的 log 美化命令。这不算必须，但能显著提升日常效率。对于所有新人，我的建议是：前两周别配置任何 alias 和花哨的图形工具，老老实实敲完整命令，把四个区域的关系和每一条命令的实际行为吃透。等这些成为肌肉记忆了，再谈效率和个性化。

我见过太多人，第一周就装了一堆插件和 GUI，结果哪天 GUI 抽风，连基本的提交都做不了。说到底，Git 的本体就是那 20 多个命令，命令行掌握牢了，你到任何一台新机器上都能马上干活，这才是真正的从容。