企业官网建设流程全解析

上个月帮同事配了一台新的Windows开发机，原以为装个Git十分钟收工，结果卡在两个地方：安装向导里那一堆勾选框到底该怎么选，以及配SSH密钥时反复遇到Permission denied。折腾了快一小时，回头想其实Git在Windows上的"完整可用"从来不是双击exe一路Next就结束的，后面还跟着环境变量、换行符策略、中文编码、凭据管理、SSH密钥这一长串配置。这篇文章就按我实际操作的顺序，把Windows下Git的下载、安装、环境配置、SSH密钥生成与多平台绑定从头到尾走一遍。适合刚接触Git的新手，也适合每次换电脑都要重新翻资料的老手——你可以直接把这篇文章当作一份核对清单，装完一项划掉一项。

1. 为什么Windows下装Git不能一路Next：先搞懂PATH、Bash和换行符

1.1 Git for Windows到底装了什么

很多新手以为Git.exe装完就完事了，实际上Git for Windows这个发行版给你带来了三样东西：核心Git命令、Git Bash、Git GUI。

Git本身诞生于Linux生态，它的行为习惯、路径风格、换行符策略都是围绕Unix环境设计的。Git for Windows做的不是简单地把git.exe编译成Windows版，而是顺便打包了一个模拟的Unix环境——Git Bash。你打开Git Bash后能用ls、grep、sed、ssh-copy-id这些Unix命令，就是因为这个模拟环境里装了对应的工具集。后面配置SSH密钥时，我建议你在Git Bash里操作，而不是CMD或PowerShell，因为很多命令在Bash里的行为和教学示例完全一致。

这也是为什么Git的安装选项那么复杂的原因：它不是在问你要不要装这个软件，而是在问你"你希望这个Unix世界的工具以什么方式嵌入Windows环境"。理解这一点，后面很多问题都能想通。

1.2 PATH不配好，等于白装

PATH是Windows查找可执行文件的目录列表。你在CMD里输入git，系统会按PATH里写的目录顺序逐个查找git.exe，找不到就报"git不是内部或外部命令"。

安装向导里的"Adjusting your PATH environment"那一屏就是在决定要不要把Git的可执行文件目录加入这个列表。如果你选了第一项"Use Git from Git Bash only"，那么只有打开Git Bash才能用git命令，CMD和PowerShell里都用不了——这是我见过新手卡住最频繁的地方，明明装好了，一敲git就报错。

所以我会明确推荐第二项"Git from the command line and also from 3rd-party software"。这一项会把Git的核心命令加入系统PATH，同时不会把那些Unix工具也加进去，避免ls、find这些命令和Windows自带的同名命令打架。第三项"Use Git and optional Unix tools from Command Prompt"虽然看起来功能更强，但会把一堆Unix命令塞进PATH，很多开发机环境冲突就是从这里开始的，能避开就避开。

1.3 换行符的CRLF/LF之争

Windows的文本文件默认用回车加换行（CRLF，\r\n）表示一行结束，Linux和macOS只用换行（LF，\n）。这个差异在Git里会引发一个经典问题：同一个文件在不同系统上checkout出来，字节内容不一样。

Git解决这个问题的机制叫autocrlf。安装向导里有三个选项，推荐选第一项"Checkout Windows-style, commit Unix-style line endings"。它的含义是：从仓库取出代码到工作区时，自动转成CRLF让Windows工具舒服；提交到仓库时，再转回LF让仓库里保持Unix风格。这样多人协作时，仓库里的文件是统一的LF，不会因为不同系统导致整个文件被判定为全部改动。

如果不设置或设置不当，最常见的后果是Shell脚本在Linux上写好后，拿到Windows上一跑就报错"$'\r': command not found"，后面第6章我会专门讲这个坑。现在理解这一屏选项不是废话，后面能省很多事。

2. 下载前的三个决策：官网还是镜像、64位还是32位、稳定版还是尝鲜版

2.1 下载渠道：官网、镜像站、winget三选一

Git的官网是git-scm.com，打开后会自动识别你的系统，点击"Download for Windows"就会跳到最新版本的下载页。下载页里一般会有64-bit和32-bit两个安装包，选对应架构的exe即可。

不过有个现实问题：Git的Windows安装包挂在GitHub的Release上，如果你的网络访问GitHub不稳定，下载速度可能让人想摔键盘。这种情况我建议直接用国内镜像站，清华TUNA镜像、阿里云开源镜像站、腾讯软件源都有git-for-windows的完整归档。以清华TUNA为例，进站后找git-for-windows目录，点进最新版本号，下载对应架构的exe即可，速度通常快很多。

如果你喜欢命令行操作，Windows 10以上系统还能用winget装：

winget install --id Git.Git -e --source winget

winget装的是官方发行版，安装选项走默认值。它的默认配置对大多数人够用，但如果你想要更精细的控制（比如指定默认编辑器、调整终端模拟器），还是手动跑一遍exe安装向导更踏实。

2.2 架构和版本怎么选

判断系统架构很简单：右键"此电脑"→属性，查看"系统类型"显示64位还是32位；或者在运行窗口输cmd /c echo %PROCESSOR_ARCHITECTURE%，输出AMD64就是64位。

现在新电脑基本全是64位，选64-bit安装包不会错。32位系统才需要特地去下载32-bit版本。这里有个细节：即使你日常工作会用到一些老旧的32位工具，Git本身装64位也没有问题，Git主要是命令行工具，不太涉及跨位数调用兼容的问题。

版本策略上，我建议直接下载官网标记的"最新稳定版"，不要刻意追Beta或RC候选版。Git官方对Windows版的发布其实比较审慎，每季度左右出一个版本，稳定版的bug修复很及时。对绝大多数使用者来说，"当前最新稳定版"就是最好的选择，既不需要担心新版本不稳定，也不用等所谓的"更成熟"版本——你等不起那个时间成本。

2.3 安装前的最后检查

下载完成后，右键exe文件，打开属性→数字签名，确认签名状态显示"正常"。Git for Windows的安装包是有官方签名的，这一步能避免下载到被篡改的安装包。同时确认一下文件大小，通常在50MB到80MB之间，如果只有几百KB，多半是下载到了不完整文件。

如果你电脑上已经装了旧版Git，不需要卸载，直接跑新版本exe覆盖安装就行。Git的全局配置文件在用户目录下的.gitconfig，不会因为覆盖安装丢失，但为了保险，升级前可以把这个文件备份一下。接下来进入安装向导，这才是整篇文章的重头戏。

3. 安装向导逐屏拆解：每个勾选框背后的含义和推荐选项

3.1 从组件选择到默认编辑器

安装向导第一屏是GNU General Public License，直接Next。

选择安装路径时，默认在C:\Program Files\Git。如果你要改到D盘，注意路径保持全英文、不要带空格。新版Git对带空格的路径支持已经不错了，但中文路径偶尔还是会有工具不认，为省心就直接用默认路径。

Select Components这一屏是第一个需要动脑的地方。我的建议是：

• "Git Bash Here"和"Git GUI Here"：保持勾选。安装后在文件夹右键菜单里能看到"Git Bash Here"，非常方便，强烈建议保留。
• "Add a Git Bash Profile to Windows Terminal"：如果你用的是Windows Terminal，建议勾上，这样打开Windows Terminal时可以直接选择Git Bash作为终端。
• "Scalar"：建议不要勾。这是微软出的部分克隆工具，普通开发场景用不到，勾了只会让右键菜单更臃肿。

接着是选择默认编辑器。如果你电脑上装了VS Code，直接选"Use Visual Studio Code as Git's default editor"；没装VS Code就选Vim。这里我不推荐选Notepad，Windows记事本对UTF-8无BOM文件和LF换行符的支持很糟糕，遇到冲突编辑时体验极差。Vim虽然上手有点门槛，但只是作为git commit时的编辑器临时用一下，敲个i进入编辑、按Esc后输入:wq保存退出，够用了。

3.2 PATH、HTTPS后端、换行符三个关键选项

PATH那一屏前面已经详细说过，选第二项"Git from the command line and also from 3rd-party software"。

HTTPS后端选择建议默认的"Use the OpenSSL library"。Git通过HTTPS克隆仓库时，需要验证服务器的SSL证书，OpenSSL是Git官方默认的验证库，兼容性最广泛。另一项"Use the native Windows Secure Channel library"使用Windows系统自带的证书存储，如果你所在公司内网使用自签证书的Git服务器，这个选项可能更合适。但对大多数个人用户来说，OpenSSL是稳妥选择。

换行符转换那一屏，我建议绝大多数Windows用户选第一项"Checkout Windows-style, commit Unix-style line endings"，具体原理在第1.3节已经讲过了。这里补充一点：如果你参与的是一个纯Linux/Mac环境维护的项目，团队约定所有文件都用LF，那你可以选第二项"Checkout as-is, commit Unix-style line endings"；如果你确定团队没人用Windows，选第三项也没问题。但一开始没有明确倾向时，第一项最安全。

3.3 终端模拟器、pull行为、凭据管理和实验选项

终端模拟器有两个选项："Use MinTTY"和"Use Windows' default console window"。MinTTY是Git for Windows默认推荐的模拟终端，功能更丰富，鼠标选中复制、窗口缩放、中文显示都更友好。我建议保持默认MinTTY。

不过要注意一个细节：如果你习惯在VS Code或Windows Terminal里使用Git Bash，这个选择的影响并不大，因为终端外层由VS Code或Windows Terminal接管，MinTTY只在独立打开Git Bash时生效。

git pull的默认行为，默认选项是"Default (fast-forward or merge)"。如果你熟悉rebase工作流，可以选Rebase那一项；不确定时就保持默认。git pull本质上等于fetch加merge，默认行为不会额外制造麻烦，团队习惯用merge就最合适。

"Choose a credential helper"这一屏是很多人忽略但很重要的选项。默认会选中"Git Credential Manager"，这个一定要保留。它负责在HTTPS方式推拉代码时帮你保存凭据，Windows下会把账号令牌存进系统凭据管理器，这样你不需要每次push都输入用户名密码。实测下来，这个组件在Windows上的体验稳定，不要选None。

后面的实验选项默认都不勾，不用动。

3.4 从git --version开始的第一轮验证

安装完成后，打开一个新的CMD窗口（注意是新的，不然PATH不会刷新），输入：

git --version

能输出git version 2.x.x.windows.x就说明PATH配好了。再输入where git，能看到git.exe的完整路径，确认它指向你安装的目录。

接着打开Git Bash，输入：

git config --global --list

此时应该没有任何输出，说明配置文件还没有写入内容。不用慌，下一步就开始配置。

4. 安装后的环境配置：身份、分支、中文和命令优化

4.1 全局身份：user.name和user.email

安装完Git后的第一件事就是配置身份。这两项会写进每次commit的元信息里，GitHub、Gitee、GitLab等平台在网页上显示提交人，用的就是这个邮箱和名字。

git config --global user.name "你的名字" git config --global user.email "you@example.com"

邮箱务必使用你注册代码托管平台时用的那个邮箱，否则提交记录可能无法关联到你的账号。个人项目建议统一用一个邮箱，避免贡献记录散落。

配置完之后可以查看所有全局配置：

git config --global --list

输出里应该能看到user.name、user.email。如果你想看某个配置来自哪个文件，用git config --show-origin --get user.email，会输出类似file:"C:/Users/你的用户名/.gitconfig" your@example.com的结果。

4.2 默认分支、凭据助手和配置层级

Git 2.28之后支持配置默认分支名。现在主流代码托管平台新建仓库的默认分支已经是main，本地也要跟上：

git config --global init.defaultBranch main

这样你在本地执行git init建仓库时，默认分支就是main，不会出现"本地master、远端main"的别扭情况。

确认一下凭据助手是否正常工作：

git config --global credential.helper

新版应该输出manager或manager-core。有输出就没问题，后续HTTPS方式首次登录时，Git Credential Manager会弹出Windows凭据管理器窗口让你登录，之后就不会再问了。

Git配置分三个层级：system（全系统）、global（当前用户）、local（当前仓库），优先级是local大于global大于system。global配置保存在用户目录下的.gitconfig，local配置保存在仓库目录下的.git/config。排查问题时先弄清当前配置来自哪一层，能少走很多弯路。

4.3 中文乱码问题一次讲透

Windows下Git的中文乱码主要有两种，解决方法不同，别搞混。

第一种是git status和git ls-files里中文文件名显示成\346\226\207\345\255\227这种八进制转义字符。原因是Git默认把非ASCII字符做了转义，叫core.quotepath，默认值是true。关掉它：

git config --global core.quotepath false

这条命令能解决文件名乱码。它也让git diff和git status输出的中文路径变得可读，实测在VS Code里调用Git输出时同样有效。

第二种是git commit时输入中文提交信息，或者git log接口输出时显示乱码。在Git Bash里执行：

git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8

再在Git Bash里执行：

echo 'export LANG="zh_CN.UTF-8" export LC_ALL="zh_CN.UTF-8"' >> ~/.bashrc

重新打开Git Bash后，中文提交信息就能正常显示了。这个解决方案同样适用于解决git log里中文乱码的问题。

4.4 常用alias和体验优化

配置好基础项之后，我建议顺手加几个alias，日常操作能省不少敲击次数：

git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg "log --oneline --graph --all --decorate"

如果你希望在终端提示符里显示当前分支名，可以在~/.bashrc里加一段简单的PS1配置。不想折腾的可以用一些现成的bash-git-prompt脚本，或者最简单的做法：用VS Code自带的源代码管理面板，分支名、改动文件一目了然，不依赖终端提示符。

5. SSH密钥：从生成到多平台落地，一次配好终身免密

5.1 为什么用SSH而不是HTTPS

HTTPS方式配合Git Credential Manager，虽然也能记住密码，实际用起来还是有几个麻烦：开双重验证后密码变成了Token，很多人搞不清到底要填哪个；公司内网的GitLab如果证书配置有问题，HTTPS克隆也可能被拦。SSH密钥则不同，公钥放在服务器上，私钥留在本地，推拉代码全靠密钥认证，不需要每次输入任何凭据。

对比一下：

SSH密钥还有一个额外好处：它不止用于Git托管平台，远程服务器登录、VS Code Remote-SSH远程开发、scp传文件都复用同一套密钥机制，配一次能用很久。

5.2 生成密钥：ed25519还是RSA，passphrase要不要

打开Git Bash，执行：

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

-t指定加密算法，-C是注释，通常填你的邮箱，纯粹用于标识，不参与认证。

我推荐ed25519，它是Curve25519曲线上的签名算法，密钥长度短、生成快、安全性高，而且得到了GitHub和绝大多数现代服务器的支持。如果你需要连接的服务器比较老旧，比如某些老版本libssh或老交换机，可能不支持ed25519，那就改用RSA：

ssh-keygen -t rsa -b 4096 -C "you@example.com"

执行后会有几个交互问题。第一问是保存路径，默认是C:\Users\你的用户名\.ssh\id_ed25519，直接按回车用默认路径。第二问是设置passphrase，也就是私钥的使用密码。设置了的话，每次加载私钥需要输一次口诀，但Git Bash会通过ssh-agent记住，后续操作不再询问；留空的话，本地私钥被拷走就能直接使用，风险更大。我建议设置一个passphrase，尤其是办公电脑，安全多一层。

生成完成后，检查文件：

ls -l ~/.ssh

你会看到两个文件：一个是私钥id_ed25519，一个是公钥id_ed25519.pub。记住一个铁律：私钥永远不要发给任何人，不要放进仓库，不要上传到任何云盘。公钥才是可以到处分发的那一个。

5.3 公钥分发到GitHub、Gitee、GitLab和远程服务器

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出是一长串字符串，以ssh-ed25519开头。复制时注意粘完整，不能多一个空格、不能缺一个字符。更稳的办法是用clip命令直接复制到剪贴板：

clip < ~/.ssh/id_ed25519.pub

接下来分发到各平台：

• GitHub：右上角头像→Settings→SSH and GPG keys→New SSH key，Title随便填一个你记得的设备名，Key框里粘贴公钥。
• Gitee：设置→安全设置→SSH公钥→添加公钥。
• GitLab：右上角头像→ Preferences → SSH Keys，粘贴公钥。

如果是连接远程Linux服务器，不需要登录网页，Git Bash自带ssh-copy-id，一条命令搞定：

ssh-copy-id user@服务器IP

这条命令会把本地的公钥追加到服务器的~/.ssh/authorized_keys文件里，完成后就能免密登录这台服务器了。有多台服务器时，把命令里的user和IP换掉逐台执行，就是所谓的"SSH批量分发公钥"，原理其实就这么简单。

5.4 验证连接和切换remote URL

配置完成后，测试GitHub连接：

ssh -T git@github.com

第一次连接会提示确认主机指纹，输入yes回车。如果配置成功，GitHub会返回Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access.。

Gitee的验证命令是ssh -T git@gitee.com，GitLab则根据你的服务器域名来。只要能看到类似"successfully authenticated"或者"欢迎回来"的提示，就说明密钥已经被服务器认可。

接下来把你本地仓库的远程地址从HTTPS切换为SSH。先用git remote -v看当前地址，如果显示的是https://github.com/用户名/仓库名.git，就执行：

git remote set-url origin git@github.com:用户名/仓库名.git

再执行git remote -v确认地址已经变成git@github.com:...的格式。以后push和pull不再需要任何密码交互。

5.5 多账号多密钥的config配置

如果你同时使用GitHub个人账号和公司GitLab，不希望两边的密钥混用，就需要为不同域名指定不同的私钥。先生成第二把密钥：

ssh-keygen -t ed25519 -C "yourname@company.com" -f ~/.ssh/id_ed25519_company

-f参数指定保存文件名，避免覆盖默认的id_ed25519。

然后编辑~/.ssh/config文件，注意这个文件没有扩展名：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_company

Host后面写的名字很重要，它决定了你在这条规则里怎么称呼这个主机。保持HostName和实际域名一致最省心。配置完成后分别测试：

ssh -T git@github.com ssh -T git@gitlab.company.com

多密钥初学者最容易犯的错误是直接测试时报Permission denied，翻半天日志才发现SSH按默认文件名找错了私钥。一旦在config里指定了IdentityFile，SSH才会在连接对应Host时选用正确的密钥。

5.6 顺手解决服务器免密登录

搞定了上面的流程，你会发现同样一套密钥已经能用来登录远程服务器。VS Code装好Remote-SSH插件后，按F1输入"Remote-SSH: Connect to Host"，选服务器，就能直接打开远程目录，全程免密。逛逛服务器、改配置、上传文件都不需要再反复输密码，和本地编辑体验几乎一致。

如果你要登录的设备比较特殊，比如老交换机只有旧版SSH，可能支持不了ed25519，这时你需要单独生成一把RSA密钥，并把公钥追加到对应设备的配置里。不同设备的配置方式和Linux服务器不一样，但核心思路不变：私钥留在本地，公钥放到设备上。

6. 我实际踩过的坑和完整排查链路

6.1 Permission denied (publickey) 的六个排查步骤

这个报错几乎每个用Git的人都会遇到，我总结了一套排查链路，按顺序走基本能定位。

第一步，用详细模式测试连接：

ssh -vT git@github.com

输出里重点看Offering public key和Authentications that can continue这几行，能直观看出SSH尝试了哪个私钥文件。

第二步，确认私钥文件确实存在，路径要对应。如果默认文件名被改过，SSH不会自动识别，需要在config里指明IdentityFile。

第三步，检查ssh-agent有没有加载密钥：

ssh-add -l

如果你的密钥设置了passphrase，重启电脑后ssh-agent是空的，执行ssh-add ~/.ssh/id_ed25519重新加载一次，输入passphrase即可。

第四步，检查公钥是否完整粘贴。最简单的方法是重新clip < ~/.ssh/id_ed25519.pub，然后在平台设置里删掉旧公钥、重新粘贴一份。

第五步，确认仓库的远程URL是SSH格式而不是HTTPS格式。git remote -v一眼就能看出来，好多人排除半天问题，最后发现远程地址还是https开头，压根就没走SSH通道。

第六步，检查是不是同时存在多套SSH工具导致配置文件路径不一致。这个问题下面专门讲。

6.2 CRLF把Shell脚本搞崩了

从Linux仓库里clone下来的一个.sh脚本，在Windows上的Git Bash里执行，报这个错：

$'\r': command not found

原因就是脚本的换行符被Git在checkout时从LF转成了CRLF，bash看到每行末尾多了一个\r字符，把这个回车符当成命令来执行了。

临时解决办法是把脚本转回LF：

sed -i 's/\r$//' script.sh

想根治的话，在仓库根目录调整换行符策略：

git config core.autocrlf false git rm --cached -r . git reset --hard

这样这个仓库在本地不再做换行符转换，脚本保持LF原样。另一种更优雅的做法是在仓库里加一个.gitattributes文件，针对.sh文件强制使用LF，这样团队成员各自拉代码时，无论什么系统，脚本文件都会被当作LF处理，问题从源头上消失。对经常处理脚本和跨平台项目的仓库，.gitattributes值得研究一下。

6.3 Windows OpenSSH和Git自带SSH的版本冲突

Windows 10 1809之后自带OpenSSH客户端，Git for Windows也内置了一份ssh.exe。如果你在PowerShell和Git Bash里分别执行where ssh，很可能会发现它们指向不同的可执行文件。

这个冲突的典型表现是：配好的SSH密钥在Git Bash里一切正常，跑到PowerShell里测试却报错，或者反过来。Git在调用ssh时，默认使用PATH里的ssh，如果系统先找到的是Windows的OpenSSH，而你的密钥是用Git的ssh生成的，两边行为不一致就会出问题。

解决办法是统一版本。我的建议是以Git Bash里的ssh为准，因为Git for Windows的内置ssh和它的工具链版本配套，在Bash里执行ssh相关操作最稳定。如果你希望全系统统一到一个版本，可以改环境变量，把Git安装目录下的usr\bin路径放到C:\Windows\System32\OpenSSH前面。

如果你因为公司要求必须用Windows自带的OpenSSH，可以单独指定Git调用哪个ssh：

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

或者反过来指向Git自带的：

git config --global core.sshCommand "C:/Program Files/Git/usr/bin/ssh.exe"

这条配置可以针对单个仓库设置，去掉--global就行。实测中我遇到的最多是known_hosts路径不一致的问题，统一了ssh版本后基本消失。

6.4 配置迁移、升级和日常命令速查

换新电脑时，Git配置迁移非常简单，只需要拷贝两个东西：用户目录下的.gitconfig文件和.ssh文件夹。.gitconfig里是所有global配置，.ssh里是密钥和known_hosts。拷贝过去后，在新电脑上打开Git Bash执行ssh-add ~/.ssh/id_ed25519加载一次密钥，输入passphrase就全部恢复正常。

升级Git时不用卸载旧版，直接覆盖安装即可。我唯一会在升级前做的事是备份.gitconfig，虽然正常情况下不会被覆盖，但备份一下不占地方。

最后放一张常用命令速查表，方便日常查阅：

我自己在实际操作中的体会是：Git在Windows上的配置不需要一次全做完，但有几个点必须一次到位——身份信息、换行符策略、SSH密钥。这三个搞定了，日常开发基本不会再遇到让人抓狂的玄学问题。如果你在公司内网用GitLab，第6.3节提到的SSH版本冲突一定要提前排查，否则很可能在某个周一早上被一堆莫名其妙的连接报错搞得头大。下一次我换电脑，大概率会直接复制.ssh目录和.gitconfig过去，几分钟收工。