企业官网建设流程全解析

用了这么多年 Git，我到现在都记得第一次在 Windows 上装它时被安装向导里那一堆英文选项问懵的场景。更别提后来换电脑重新配环境，明明装好了，跑git pull却一直报Permission denied (publickey)，一查才发现 SSH 密钥根本没加载进 agent。这篇文章就是奔着解决这些问题来的：从官网站点下载、安装时的每步勾选、全局身份配置到 SSH 密钥生成与托管平台绑定，全套流程我都按 2026 年当前的最新版本逻辑重新梳理了一遍，Windows 用户照着做基本不会再翻车。

1. 下载前必须想清楚的三件事：官方渠道、版本选择和安装预判

1.1 为什么我强烈建议绕开第三方下载站

很多新手搜“Git 下载”会直接点进下载站，页面花花绿绿，按钮倒是很大，但里面经常捆绑了浏览器助手、压缩软件、各种“加速器”。我帮朋友修电脑时见过不止一次，装完 Git 以后桌面多了几个莫名其妙的软件，浏览器主页也被改了。这不是夸张，是第三方下载站最常见的变现手段。

Git 的官方维护版本叫Git for Windows，一直由 Git 官方维护团队在负责，下载地址就是git-scm.com，页面顶部有个很显眼的下载按钮，会根据你的系统自动匹配 64 位安装包。如果官网打开速度不理想，可以使用国内高校或云厂商的镜像站，但同样要认准官方镜像身份，不要跑到不知名的“下载站”。

注意：下载安装包时看一眼文件后缀，.exe结尾的是 Windows 安装包。.tar.gz、.zip结尾的是源码或便携版，不适合普通用户日常使用。

1.2 2026 年了，该选哪个版本

官网首页通常提供两个下载入口：一个是当前最新稳定版，另一个是“64-bit Git for Windows Setup”这类指定架构安装包。2026 年的主流 PC 基本都是 64 位系统，直接选 64 位即可。如果你的电脑还是老旧的 32 位系统，才需要额外找 32 位支持版本，但这种设备现在真的很少见了。

还有一个容易忽略的点：Git 2.x 的版本号一直在滚动更新，安装包的版本号不用刻意追求最新，稳定版即可。比如你看到git version 2.5x这种版本号，直接下载安装就好。老项目一般不会因为你用了新版 Git 而崩掉，Git 的向后兼容性做得相当好。

判断系统架构最简单的方式是右键“此电脑”→“属性”，查看“系统类型”。确认是 64 位操作系统后，下载 x64 安装包，基本零风险。

2. 安装向导里的每个选项，到底在问你什么

双击安装包后会进入 Git Setup 向导。从“信息”页到“安装完成”大概有七八步，每一页都有选项，如果只是闭着眼点“Next”，大概率会在后面遇到 PATH 不对、编辑器不对、换行符混乱这类问题。我逐个拆开说。

2.1 组件勾选和安装路径

第一步需要关心的页面是Select Components（选择组件）。默认勾选了“Git Bash Here”和“Git GUI Here”，这两个建议保留，它们是 Windows 上使用 Git 最顺手的入口。桌面上如果不想被图标“污染”，可以取消勾选“Git Desktop Icon”，这个纯粹看个人习惯，不影响功能。

安装路径我习惯用默认的C:\Program Files\Git，不建议塞进带空格或中文的路径，虽然新版 Git 已经能处理大部分特殊情况，但命令行工具对路径的容错始终有限，咱没必要自己给自己挖坑。

C:\Program Files\Git

这个路径在后续配置 SSH 或某些 IDE 调用 Git 时，不会出现怪异的转义符问题。

2.2 默认编辑器：为什么我不建议保留 Vim

接下来是Select Default Editor（选择默认编辑器），默认选的是 Vim。Vim 本身没问题，但对 Windows 新用户极不友好：你提交代码时写错字想退出，按Esc、:wq、回车，这一套操作没练过的话直接卡死在编辑器里。我第一次用 Git 提交时就被 Vim 困住过，在命令行里折腾了十分钟才退出来。

现在多数人电脑里都装了 VS Code，安装向导里也能直接选“Use Visual Studio Code as Git's default editor”。如果你常用其他编辑器，选对应的选项就行。核心逻辑是：选择你熟悉的那一个，而不是教程里默认的那一个。

2.3 PATH 环境变量的三种模式怎么选

PATH 配置是安装向导里最重要的选项，直接影响你在cmd或 PowerShell 里能不能直接敲git命令。三种模式：

默认选的是第二项，这也是我多年反复推荐的选项。选这项之后，你在 Windows Terminal、PowerShell、VS Code 内置终端里敲git都能直接识别，省去很多环境变量手动画蛇添足的麻烦。

配置完成后可以在任意终端验证一下：

git --version

如果输出类似git version 2.47.1.windows.1，说明 PATH 配置成功。

2.4 换行符转换、终端模拟器这些默认值动不改

安装向导到了Configure the line ending conversions（配置行尾转换）时，大部分人开始纠结。这里默认选第一项“Checkout Windows-style, commit Unix-style line endings”，对应core.autocrlf=true，我建议普通用户保留默认。

简单解释为什么：Windows 用CRLF来换行，Linux/macOS 用LF。如果不做转换，你在 Windows 上写的脚本提交到远端后，Linux 服务器上可能出现^M这种结尾乱码。Git 在检出时自动转成CRLF，提交时又自动转回LF，就能把这种冲突化解于无形。

再往下，Choose a credential helper默认是“Git Credential Manager”，保留即可。Enable file system caching也建议保留，能提升 Git 读写文件时的性能。

还有一个选项是“Use bundled OpenSSH”还是“Use external OpenSSH”。这里务必选Use bundled OpenSSH，也就是 Git 自带的 SSH 实现。有些同学电脑上装过 Windows 自带的 OpenSSH（C:\Windows\System32\OpenSSH），版本和 Git 自带的不一定一致，混用容易出现密钥路径识别不一致的问题。

3. 装完之后的三条命令，把 Git 先“激活”再干活

装好 Git 只是第一步。直接开始git clone大概率会被身份信息或凭据问题卡住。我建议按照下面的顺序做一次初始化。

3.1 打开 Git Bash 的正确姿势

安装完之后，在任意文件夹里右键就能看到“Git Bash Here”。我推荐在某个专门放代码的目录下打开，比如建一个D:\code或C:\Users\你的用户名\code。在这个目录右键 → Git Bash Here，打开后的路径会自动定位到当前文件夹，很方便。

Git Bash 的界面是黑底白字的终端窗口，它可以执行绝大多数 Git 命令，同时支持很多 Linux 常用命令，比如ls、cd、touch、rm。对于从 macOS 或 Linux 转过来的用户来说，这种感觉很像回到家。

3.2 设置 user.name 和 user.email

身份信息必须设置，否则提交代码时 Git 会强制要求你补全。打开 Git Bash 执行：

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

这两条命令设置了全局身份信息，之后的每一次提交都会带上这两个字段。需要说明的是：

• user.name不一定非要填真名，但建议填一个团队能认出你的名字。
• user.email建议与代码托管平台的账号邮箱一致，提交记录才能正确关联到你的账号。

查看当前配置可以执行：

git config --global --list

我见过有人抄教程时把邮箱写错，导致 GitHub 上的提交不显示绿色小方块，头像也一直是灰色。这种问题追溯起来很麻烦，不如一开始就填对。

3.3 记住密码这件事，别依赖“缓存密码”选项

很多人在配置完身份信息后，第一次 push 时 Git 会弹出一个登录窗口，输入账号密码后就能正常推送。这个功能来自Git Credential Manager，它会把凭据存在 Windows 的凭据管理器里，下次推送不再询问。

这套机制本身没问题，但有几个注意点：

• 如果公司 GitLab 或代码托管平台启用了双重认证，密码框里填的不是登录密码，而是访问令牌（Personal Access Token）。
• 凭据管理器在 HTTPS 方式下生效，SSH 方式完全不经过它。
• 如果有一天你换了账号密码，发现 Git 一直用旧凭据报Authentication failed，需要到“控制面板 → 用户账户 → 凭据管理器 → Windows 凭据”里删掉对应的 Git 凭据记录，重新触发登录。

控制面板 > 用户账户 > 凭据管理器 > Windows 凭据

删掉那一条以git:https://github.com开头的记录，下次操作就会重新弹窗输入新账号密码。这个排查步骤我教过很多人，属于“知不知道能省半小时”的典型问题。

4. SSH 密钥生成全流程：从选密钥类型到加载到本地

HTTPS 方式每次推送都要走凭据管理器，虽然能记住密码，但遇到自建 GitLab 或者需要多账号切换时略显繁琐。SSH 密钥方式更干净，一把私钥配一把公钥，公钥放到托管平台，私钥留在本地，之后推送拉取都不需要再输密码。下面从零开始走一遍。

4.1 为什么我推荐用 Ed25519 而不是 RSA

密钥类型方面，新手通常会在 RSA 和 Ed25519 之间纠结。GitHub、GitLab、Gitee 现在都支持 Ed25519，它生成的密钥更短、生成速度快、安全性也足够。RSA 4096 也不是不行，但密钥文件更长，计算开销更大，属于“能用但没必要”的老方案。

除非你连接的服务器还是老旧的 GitLab 版本或不支持 Ed25519 的自建平台，否则我建议统一用 Ed25519。

提示：如果公司内部平台特别老，连 Ed25519 都不认识，那才退回去用ssh-keygen -t rsa -b 4096。

4.2 ssh-keygen 实操与每条参数的意义

打开 Git Bash，执行：

ssh-keygen -t ed25519 -C "your_email@example.com"

解释一下各段参数：

• -t ed25519：指定密钥类型为 Ed25519。
• -C：添加注释。这里常用邮箱，作用是让别人在查看公钥时知道这把钥匙属于谁，本身不影响加密功能。

执行后回车，终端会询问：

Enter file in which to save the key (/c/Users/你的用户名/.ssh/id_ed25519):

直接回车，使用默认路径即可。接下来会要求输入 passphrase（口令）：

Enter passphrase (empty for no passphrase):

这里可以选择空着直接回车，以后用密钥时就不用输口令。但我个人建议输入一个口令，哪怕设个简单的也行：私钥文件一旦泄露，口令是最后一道防线。当然，设了口令后会带来一个副作用——每次使用都要输入一次口令。所以很多开发者干脆不设，完全凭私钥文件权限来保证安全。

如果设了口令，下面第三步的 ssh-agent 就非常重要了，它能在一次会话内帮你记住口令，避免每次操作都重复输入。

4.3 把私钥加载到 ssh-agent，这是 Windows 用户最容易漏的环节

密钥生成好了，但如果你直接去ssh -T git@github.com测试，很可能会收到Permission denied (publickey)。原因很简单：SSH 客户端默认只会读取.ssh目录下固定文件名（如id_rsa、id_ed25519）的密钥，有时候找得到，有时候因为权限或配置问题找不到，还可能因为设置了 passphrase 需要交互输入。

解决办法是把私钥显式加载到ssh-agent里。Git Bash 中执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

第一条命令启动 ssh-agent，第二条命令把私钥添加进去。如果刚才设置了 passphrase，这里会要求输入一次，之后当前终端会话内不再重复询问。

但这里有一个 Windows 特有的坑：Git Bash 窗口一关，ssh-agent 进程就结束了，下次打开终端又要重新执行一遍ssh-add。解决方案有两种：

方案一：每次开新终端都手动执行前两条命令，简单但麻烦。

方案二：把 Windows 系统自带的 OpenSSH Agent 服务开机启动，并设置为自动。这样 ssh-agent 以后台服务形式运行，密钥一次加载，长期有效。操作如下：

1. 以管理员身份打开 PowerShell，执行：

Get-Service -Name ssh-agent

2. 如果服务状态是禁用，执行：

Set-Service -Name ssh-agent -StartupType Automatic Start-Service ssh-agent

3. 再回到普通终端执行ssh-add ~/.ssh/id_ed25519，把私钥加进去。

之后只要 Windows 系统不重启，ssh-agent 会一直运行。重启电脑后服务会跟着系统自动启动，但已添加的密钥可能需要重新ssh-add，这是正常现象。

注意：不要同时混用 Git 自带的 ssh-agent 和 Windows 的 OpenSSH Agent 服务，否则可能出现密钥加载了但实际连接时又被另一个 agent 拦截的问题。我建议要么统一走 Git Bash 里的eval "$(ssh-agent -s)"方式（每次终端临时加载），要么统一走 Windows 服务方式（开机自启，长期有效）。二选一即可。

5. 公钥上云：GitHub、Gitee、GitLab 的配置入口与验证

5.1 把公钥内容复制到托管平台

私钥生成后，同目录下会多一个.pub结尾的公钥文件，这才是要放到托管平台上的内容。在 Git Bash 里查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出是一行ssh-ed25519 AAAA... 你的邮箱格式的字符串。从行首复制到行尾，不要漏字符。

不同托管平台的公钥添加入口：

• GitHub：右上角头像 → Settings → SSH and GPG keys → New SSH key。
• Gitee：设置 → 安全设置 → SSH 公钥。
• GitLab：左侧偏好设置 → SSH 密钥，不同版本界面略有差异，但关键词都是“SSH Keys”。

把公钥粘贴进去，标题随意，保存即可。这一步在三个平台的操作逻辑完全相同，区别只在入口位置。

5.2 用 ssh -T 验证连通性

添加完公钥后，回到 Git Bash 测试：

ssh -T git@github.com

如果首次连接会提示：

The authenticity of host 'github.com (IP)' can't be established. Are you sure you want to continue connecting (yes/no)?

输入yes，回车。之后如果看到类似：

Hi 用户名! You've successfully authenticated, but GitHub does not provide shell access.

说明 SSH 密钥已经配置成功。同理：

• Gitee 验证命令是ssh -T git@gitee.com，成功会提示“Hello 用户名”。
• GitLab 验证命令是ssh -T git@gitlab.com，成功会提示Welcome to GitLab, @用户名!

5.3 多平台多账号的 config 文件怎么管理

日常开发中，很多人同时使用 GitHub 个人仓库、Gitee 仓库和公司 GitLab。如果每把密钥都叫id_ed25519，系统只会默认加载一个，就会遇到“GitHub 能连通，Gitee 报权限错误”的怪问题。

解决办法在.ssh目录下新建一个config文件，用不同 Host 映射不同密钥。例如：

# 个人 GitHub Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github # 工作 GitLab Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_gitlab

生成不同平台的密钥时，不要一路回车用默认文件名，而是指定不同的文件名：

ssh-keygen -t ed25519 -C "github@example.com" -f ~/.ssh/id_ed25519_github

-f参数指定密钥保存为id_ed25519_github。按同样的方式生成id_ed25519_gitlab，再在 config 中指定路径。这样配置之后，git clone git@github.com:用户名/仓库.git会自动使用id_ed25519_github，而克隆公司仓库时自动使用另一把。

我有一个经验是：config 文件的Host名称不一定要和真实域名一致，但它会被 Git 的 SSH 连接当作别名使用。如果写错 Host，SSH 就匹配不到对应的 IdentityFile，会回到默认密钥，导致权限失败。所以配置好之后，最好逐个ssh -T验证一遍。

6. 装完以后随手要做的事与高频问题排查

6.1 CRLF 警告：它不是错误，但会吵得你心烦

如果你用某个项目时，执行git add后终端突然冒出一堆：

warning: LF will be replaced by CRLF

不用慌，这是 GIt 在按之前说到的core.autocrlf=true规则做行尾转换的正常提示。它只是告知你“文件里的换行符会从 LF 转成 CRLF”，并不是错误。

但如果你在团队项目中频繁看到这个警告，或者发现 diff 里出现大量“整行变动”的情况，说明团队里混用了 Windows 和 Linux/macOS 开发环境，且缺少统一的换行符约定。这时候最规范的做法不是让每个人改全局配置，而是在仓库根目录加一个.gitattributes文件，统一锁定模块文件的行尾：

* text=auto *.sh text eol=lf *.bat text eol=crlf

这样的好处是：不管成员在什么系统上开发，Git 都会按规则强制转行尾，从源头杜绝“换行符幽灵改动”。

6.2 VS Code 集成 Git 时需要留意的细节

现代前端和后端开发者几乎都在 VS Code 里写代码，VS Code 自带的源代码管理面板已经能覆盖大多数 Git 操作。但有几个细节值得花两分钟确认：

第一，VS Code 内置终端默认可能是 PowerShell，如果你前面安装时选择了“Git from the command line...”，PowerShell 里敲git是能直接识别的。如果识别不了，多半是 PATH 没配置成功，需要检查上一节提到的安装选项。

第二，VS Code 第一次提交代码时，如果弹出“没有配置 Git 用户信息”之类的提示，说明全局 user.name 和 user.email 没配，回到第 3 节把配置补上。

第三，VS Code 的源代码管理面板点击“拉取”“推送”时，如果同时配置了多个远端，注意分支的 upstream 设置。常见做法是：

git push -u origin main

-u参数把本地分支和远端分支建立跟踪关系，以后直接git push或git pull就能自动匹配远端分支，不用每次写全。

6.3 重启电脑后密钥失效、多账号串key问题的处置

最后一个高频问题是：明明密钥配置成功过，重启电脑或者隔段时间后，突然git pull又报Permission denied (publickey)。

排除法按顺序来：

1. 确认私钥文件还在。很多人清理临时文件时误删过.ssh目录。
2. 确认 ssh-agent 里有密钥，执行ssh-add -l，如果输出The agent has no identities.，说明密钥没有加载，重新执行ssh-add ~/.ssh/id_ed25519。
3. 确认没有多个 ssh-agent 在打架。Git Bash 自带的 agent 和 Windows 服务版 agent 同时存在时，密钥可能被加载进其中一个，但连接请求被另一个接收。我的处理习惯是：工作机上只启用 Windows 的 OpenSSH Agent 服务，Git Bash 里不再手动eval "$(ssh-agent -s)"；临时用的电脑则直接用 Git Bash 手动加载，不用 Windows 服务。
4. 最后看.ssh目录下是否有 config 文件写错了 Host 映射。多账号场景下八成问题都出在这里。

这一套排查顺序我基本闭着眼睛背下来了，因为每次帮别人处理 SSH 问题，最后都能在这四步里找到答案。

最后再分享一个我个人的使用习惯：无论重装多少次系统，.ssh目录里只保留私钥、公钥和 config 文件，不要把整个.ssh文件夹丢到网盘或云笔记里。私钥一旦泄露，等同于别人拿到了你所有代码仓库的入场券。换电脑时重新生成一把新密钥，把旧公钥从平台上删掉，花不了五分钟，但能避免很多隐患。Git 本身是个极好用的工具，安装和配置的门槛一次跨过去之后，后面就是纯粹的舒服了。