企业官网建设流程全解析

距离上次重装系统已经过去大半年，这几天换了台新电脑，光是折腾 Git 环境就花了我一个下午。倒不是说 Git 安装有多难，而是下载、安装、环境变量、SSH 密钥这一整套流程，分散在好几篇教程里，版本新旧不一，照着敲还容易踩坑。Windows 上的 Git 配置确实有点碎，但把它们串起来看，其实就是一个标准流水线。

这篇教程我把整个流程完整走了一遍：从下载安装包开始，到安装选项逐项解释，再到环境变量配置、换行符设置、SSH 密钥生成与添加，最后到多平台密钥管理和常见问题排查。不论你是刚接触 Git 的新手，还是被各种报错折磨的老朋友，照着这篇文章操作，基本能一次性把环境搞定。我尽量把每一步“为什么要这么选”也讲清楚，这样你以后遇到类似问题，自己也能判断该怎么处理。

1. 整体安装思路：先把“准备做足”再做“配置”

很多人安装 Git 的习惯是双击 exe、一路 Next、装完打开 Git Bash 就开始敲命令。大多数情况下是能用的，但等你 push 代码到 GitHub、Gitee 或者公司 GitLab 时，问题就来了——要么仓库地址输进去提示权限不足，要么每次操作都要输密码，要么中文文件名乱码。这些问题根子都在安装时的选项没选对，或者 SSH 密钥压根没配。

1.1 为什么建议走“完整配置路线”而不是“默认一路下一步”

Git 安装包的设计确实考虑了“开箱即用”，默认选项如果往后不管，日常练习 clone 公开仓库、本地提交是完全没问题的。但它默认带的编辑器是 Vim、默认的换行符处理规则靠自动判断、默认不创建桌面快捷方式，这些对于新手来说并不友好。尤其是换行符，如果不管，Windows 和 Linux/macOS 协作时很容易出现“明明没改过的文件，git diff 里却显示整文件变了”的诡异现象。

所以我的建议是，第一次安装就花两分钟把几个关键选项选对，后面能帮你省掉一大串麻烦。这篇教程的安装部分，就不只是给你“下一步下一步”的流程，而是每个关键选项都会解释一下它影响什么。关于 SSH 密钥，我建议直接生成，哪怕你现在只玩本地仓库，后面只要涉及到远程仓库就一定会用到。早配早省心。

1.2 准备清单：先确认这三样东西

开始操作之前，你先确认一下：

• 一个稳定的网络环境。下载安装包需要联网，后面用 GitHub 也需要联网。
• 一个邮箱地址。Git 的每次提交都会记录提交者信息，推荐用你注册 GitHub/Gitee 的邮箱，这样提交记录能正确关联到你的账号头像。
• 一个自己能记住的密码。SSH 密钥生成时可以设置口令（passphrase），后面用到私钥时需要输入。这个不急，可以先不设，但如果你所在环境对安全要求高，建议设置。

另外，如果你电脑上已经装了旧版 Git（比如 2.3x 版本），建议先卸载旧版再装新版。不过实测下来，高版本 Git 直接覆盖安装也可以，配置文件一般不会丢，只是个别安装选项会覆盖，稳妥起见还是先卸载干净。

2. 下载与安装：逐项拆解安装向导

Git 官网的下载页面有时候加载比较慢，这是正常现象。我一般是直接访问 git-scm.com/download/win，选择 64-bit 版本。如果你不确定系统是 32 位还是 64 位，右键“此电脑” -> “属性”，看“系统类型”那栏就知道了。现在基本都是 64 位系统，除非是特别老的机器。

2.1 安装向导关键选项怎么选

拿到安装包后，双击运行，看到许可证页面直接 Next。真正需要关注的从 Select Components 开始：

这里有两个选项值得单独展开讲讲。

PATH 环境变量那一页，很多教程直接让你选中间项，但没有解释为什么。如果选了第一项“仅从 Git Bash 使用 Git”，那你在 CMD 或 PowerShell 里敲 git 就会提示“不是内部或外部命令”。虽然你可以手动把路径加到环境变量里，但既然安装包提供了这个选项，直接用就好。选了它之后，git.exe 会被加到系统 PATH 中，CMD、PowerShell、Windows Terminal 里都能直接运行 git 命令。

换行符处理这个非常关键。Unix 系统（Linux、macOS）用 LF（\n）作为换行符，Windows 用 CRLF（\r\n）。Git 默认会帮你把仓库里的 LF 转成 CRLF 检出到本地，提交时再转回 LF。听起来很智能，但如果你团队里恰好有人写脚本处理文本内容，这种隐式转换会带来各种奇怪的 bug。所以我推荐选择“Checkout as-is, commit as-is”，也就是关闭自动转换。这么做的代价是，如果你用 Windows 自带记事本打开某些从仓库检出的文件，行尾可能不统一，但现代编辑器（VS Code、Sublime、Notepad++）都能正常处理，完全不是问题。

2.2 安装完成先别急着用，做这三步验证

安装完成后，先不要急着 clone 仓库。我习惯先做三个快速验证，确认 Git 环境是正常的。

第一步，打开 Git Bash（开始菜单搜索 Git Bash），输入：

git --version

能输出类似git version 2.4x.x.windows.1就说明安装成功。

第二步，确认 git 命令在 CMD 里也能用。按Win + R，输入 cmd，回车，在黑窗口里敲同样的命令：

git --version

如果提示“不是内部或外部命令”，说明 PATH 没有生效。可以先试着重开一个 CMD 窗口，还不行就手动检查环境变量。

第三步，打开 Git GUI 或直接运行git help，确认帮助文档正常加载。这步不是必须的，但能确认安装文件没有损坏。

如果你安装时选了 Git Credential Manager，首次执行涉及远程仓库的操作时，系统会弹出登录窗口，让你输入平台账号密码。这是正常的，输一次就会记住。

注意：Git Credential Manager 默认存储的是普通凭据，不是 SSH 私钥。后面配置好 SSH 密钥后，建议在 clone 仓库时使用 SSH 协议的地址（git@github.com:user/repo.git），这样才会走密钥认证。

3. 环境配置：让 Git 在你的终端里按你的习惯工作

安装只解决了“有没有”的问题，要让它好用，还得做一层环境配置。这层配置不复杂，但很容易被漏掉，或者因为搞不清该用哪条命令而放弃。其实企业里 Git 用得利索的人，配置文件大概率就那么几行。

3.1 全局用户信息：提交记录的“署名”

安装完成后，第一次提交代码前，Git 会要求你配置用户名和邮箱。如果不配置，push 时会报错，提示缺少 user name 和 user email。

打开 Git Bash，依次输入：

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

这里的“你的名字”建议用你自己习惯的英文 ID，后续所有提交记录里都会显示这个名字。邮箱建议用注册 GitHub/Gitee 的邮箱，这样提交记录能正确关联到账号。

你可以用以下命令验证是否配置成功：

git config --global --list

会输出 user.name、user.email 等条目，说明配置已经生效。配置文件的位置在用户主目录下的.gitconfig，你随时可以用文本编辑器去查看和修改。

有一些教程会让你顺手配置git config --global init.defaultBranch main，把默认分支名从 master 改成 main。这个看个人习惯，如果你和团队都用 main 分支，那建议也加上：

git config --global init.defaultBranch main

好处是以后执行git init时，初始分支直接是 main，少一步分支重命名操作。

3.2 换行符与编码设置：跨平台协作不闹心

换行符问题值得多说两句。如果你团队只有 Windows 成员，或只有 macOS/Linux 成员，那问题不大。但如果混合协作，换行符设置不合适，就等着被无意义 diff 折磨吧。

前面安装时建议选了“Checkout as-is, commit as-is”，对应的配置是：

git config --global core.autocrlf false

这个配置会告诉 Git，不要擅自转换换行符。仓库里存什么行尾，检出来就是什么行尾。假如你要把一个 Linux 服务器上管理过的仓库 clone 到 Windows，检出来的文件行尾是 LF，用记事本打开看起来可能没有自动换行，但现代编辑器都能识别，不影响编辑和保存。

如果你习惯 VS Code 或 Sublime 这类编辑器，我建议直接在编辑器里配置“默认行尾符为 LF”或“detect from content”，这样基本能做到无感。

中文乱码也属于编码问题。Windows 上 Git Bash 偶尔会出现中文文件名显示成"\346\265\213\350\257\225.txt"这类八进制转义序列，或者在 log 里看到中文乱码。处理方法是在 Git Bash 里执行：

git config --global core.quotepath false git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8

core.quotepath false这个配置最实用，它让 Git 直接显示中文文件名，不再转义。后面几个配置则是确保提交信息和 log 输出都按 UTF-8 处理。Windows 系统默认代码页可能不是 UTF-8，但 Git for Windows 的 MinTTY 终端对 UTF-8 的支持还不错，配置好之后基本不会乱码。

3.3 初始化仓库与首次提交：验证环境配置是否真能用

配置做完，建议立刻初始化一个本地仓库，走一遍完整提交流程，确保后续实操时不会有环境问题。

我这边的具体操作记录如下：

mkdir demo-git cd demo-git git init echo "# Hello Git" > README.md git add README.md git commit -m "first commit"

执行到git commit时，如果前面用户信息没配置，Git 会直接把错误甩你脸上，提示Please tell me who you are，并告诉你该执行哪两条命令。这条报错信息本身就相当于一个引导，照着做就行，但提前配置好会省事很多。

提交完成后执行git log --oneline，能看到类似abc1234 first commit的输出，说明 Git 环境的读写、提交、日志输出全部正常。

到这里，本机 Git 环境已经可以正常使用了。如果你还需要和远程仓库（GitHub、Gitee、GitLab）交互，那紧接着做 SSH 密钥的生成与配置。

4. SSH 密钥生成与配置：从生成到免密登录

SSH 密钥听起来挺高大上，但它本质上就是一对文件：一个公钥，一个私钥。公钥放到代码托管平台上，相当于一把锁；私钥留在本机，相当于钥匙。每次 Git 通过 SSH 协议连接远程仓库时，服务端用公钥验证你的身份，验证通过就放行。这样你就不必每次 push 都输用户名密码。

4.1 生成密钥的具体步骤

打开 Git Bash，执行：

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

这里选 ed25519 是因为它比传统的 RSA 密钥更安全、更短，而且现代代码托管平台都支持。如果你的 Git 版本比较老（2.3x 之前）或者要连接的公司 GitLab 版本比较老，可能不支持 ed25519，那就用 RSA：

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

执行后会提示你设置保存路径，默认是/c/Users/你的用户名/.ssh/id_ed25519，直接回车使用默认路径即可。接着会提示你输入 passphrase，这相当于给私钥再加一道口令保护。如果你希望每次使用私钥时都输入密码，就设置一个；嫌麻烦就留空直接回车。我个人的做法是本地开发环境留空，公司电脑设置 passphrase，防止电脑丢失后私钥泄露。

生成完成后，进入.ssh目录：

cd ~/.ssh ls

正常情况下能看到两个文件：id_ed25519（私钥）和id_ed25519.pub（公钥）。私钥绝对不能泄露给任何人，公钥可以放心发给代码托管平台。

4.2 查看公钥并配置到代码托管平台

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出是一行以ssh-ed25519开头的长字符串。把这整行内容复制下来。

以 GitHub 为例，登录后进入Settings -> SSH and GPG keys -> New SSH key，Title 随便填（比如“我的Windows电脑”），Key 粘贴刚才复制的内容，点 Add SSH key。Gitee 的操作路径是设置 -> SSH公钥，GitLab 是用户设置 -> SSH 密钥，基本逻辑一样。

4.3 测试连接：证明密钥没白配

配置完后，在 Git Bash 里测试一下：

ssh -T git@github.com

如果看到类似Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.的输出，就说明 SSH 密钥已经生效，Git 可以免密访问 GitHub 了。

这里有个细节要说清楚：使用 SSH 协议 clone 仓库时，地址格式是git@github.com:用户名/仓库名.git，不是https://github.com/用户名/仓库名.git。很多人密钥半天配不起来，结果是 clone 时用的还是 HTTPS 地址，自然会不断要求输入密码。你可以在仓库页面点击 Code 按钮，选择 SSH 标签页，复制 SSH 格式的地址。

4.4 多个代码平台的多密钥管理

有同学既用 GitHub 又用 Gitee，甚至还有公司内部的 GitLab，三套账号，三套密钥，怎么处理？

最简单粗暴的方法是生成多个密钥对，然后靠~/.ssh/config文件来区分。举个例子：

ssh-keygen -t ed25519 -C "github邮箱" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "gitee邮箱" -f ~/.ssh/id_ed25519_gitee

这样会生成两组不同的公钥和私钥。然后在~/.ssh目录下新建一个名为config的文件（注意没有扩展名），写入：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee

保存后，Git 就会根据你访问的域名自动选择对应的私钥。这样 GitHub 和 Gitee 都能免密访问，互不干扰。这个配置文件同样适用于公司 GitLab，只要把 Host 改成你公司 GitLab 的域名即可。

我第一次用这个方案的时候踩过一个坑：Git Bash 在新建 config 文件时会自动加.txt后缀，导致配置文件没被识别，连接一直报错。后来我在 Git Bash 用touch config创建纯文本文件，路径才正确。如果你用 Windows 资源管理器右键新建，注意把文件名改成config，不要保留.txt。

5. 常见问题与排查：我踩过一遍的坑大汇总

教程写到这，基本流程已经完整了。但我知道你实际操作时大概率会遇到下面这些报错之一二，这些是我这些年真实踩过的坑，整理成速查表，方便遇到问题直接对照。

5.1 Permission denied 的排查边界

SSH 连不上时，我习惯按顺序排查三步。第一步看本地是否持有私钥，执行ls -la ~/.ssh；第二步看密钥 agent 是否在运行，如果ssh-add -l报错，执行eval "$(ssh-agent -s)"再ssh-add；第三步看公钥是否已加入平台且和本机私钥匹配，这个过程把本机公钥内容与平台记录逐个字符比对一下，很容易发现是粘贴时漏了字符。

还有一种是公司 GitLab 场景下，如果登录时提示login failed. check api token or gitlab version，这通常是 Git 客户端或 IDE 集成插件使用 API Token 认证失败，先把本地缓存的凭据清掉，重新用浏览器授权登录一次。如果 GitLab 版本很老，记得检查它是否支持你当前 Git 客户端的认证方式。

5.2 换行符警告值的处理思路

第一次用 Git 拉代码时，很多人会被warning: LF will be replaced by CRLF这类输出吓到。这个提示其实只是告知你 Git 的换行符转换策略正在生效，不一定是错误。关键是全团队约定统一。如果你按前文建议设置了core.autocrlf false，检出和提交都按原样处理，就不会有这种警告。如果你所在团队是 Windows 为主，大家统一用 CRLF 也没问题，设置core.autocrlf true即可。最怕的是今天这个成员用 true，明天那个成员用 false，diff 满天飞。

5.3 仓库地址用错导致的免密失败

还有一种常见的免密失败是 clone 地址选错。如果复制的是 HTTPS 地址，那你配置的 SSH 密钥根本不会参与认证，Git 会一直要求你输入账号密码。这本不算 bug，但很多人会把它当成“SSH 密钥没配置成功”。结论是：使用 SSH 免密，就一定要用 SSH 协议地址。仓库页面 Code 下拉框里默认展示 HTTPS，记得切换标签再到 SSH 页签复制。

5.4 我的 Git 环境备份恢复习惯

环境配置好以后，建议把这些配置项沉淀成一个脚本或记录到自己的笔记系统里。我自己的.gitconfig内容其实是固定的，换新电脑时只需要复制过去改一下 user.name 和 user.email 就能恢复。.ssh/config也建议直接备份，配合私钥和公钥文件，换电脑半小时内就能恢复到和生产环境一致的 Git 工作环境。

这个小习惯帮我省过两次大麻烦：一次是电脑突然报废，一次是公司要求换发新笔记本。我只需要把.gitconfig、.ssh目录整体拷过去（或者用自己搭建的私有仓库同步），然后执行ssh-add把私钥加入 agent，新环境立刻可用。如果你有更精细的管理需求，也可以把这些配置统一放到 dotfiles 仓库里管理，Git 本身就是一个顺手的配置同步工具。

我个人的体会是，Git 环境的稳定运行，一半靠安装配置正确，另一半靠平时的使用习惯。SSH 密钥生成完最好做一次备份，放到加密的 U 盘或者密码管理器里；日常使用中留意 Git Bash 里的警告信息，不要一看到英文提示就直接忽略；每隔一段时间用git config --global --list检查自己的配置，及时发现异常项。这样一套操作下来，你的 Git 环境不敢说绝对不出问题，但遇到问题的概率会低很多。后面如果你们团队需要上 CI/CD，这套配置好的 SSH 密钥还能直接复用到服务器上，算是提前打好底子。