企业官网建设流程全解析

去年年底我帮三四个同事配完 Git 环境之后发现一个共性：大家卡住的地方几乎一模一样——不是安装本身，而是装完之后不知道怎么配、配完 SSH 又连不上仓库。网上教程倒是很多，但要么太老，要么只讲 GitHub 不讲 Gitee，要么一上来就让敲命令，连 Bash 是什么都不解释。这篇我就把 2026 年当下 Windows 上从零配置 Git 的全流程完整写一遍，包括下载、安装、环境变量、换行符处理、SSH 密钥生成和多平台配置，所有操作步骤我都按实际踩过的坑做了标注。

这篇文章主要解决两个问题：一是让完全没装过 Git 的新手能独立完成整个配置流程；二是让已经在用但经常遇到 clone 慢、推送被拒、密钥失效这些问题的老手，能有一套可以对照排查的完整方案。我自己从最早的 msysGit 时代就开始用 Git for Windows，换了至少三代配置方式，这里写的是目前最稳、最不容易出错的组合。

1. 安装前的准备工作与版本选择

1.1 Git 在 Windows 上到底装的是什么

很多人会把 Git 和 GitHub 搞混，这里先理清一个基本概念。Git 是一个分布式的版本控制系统，它本身只是命令行工具，不依赖任何图形界面。GitHub、Gitee、GitLab 这些是基于 Git 协议提供的托管平台，我们日常说的“把代码推到远程”，指的就是把本地仓库同步到这些平台上。

Windows 上安装 Git，实际上安装的是 Git for Windows——这是 Git 官方在 Windows 平台的发行版本。它不只包含 Git 核心命令，还附带了几样非常重要的东西：

• Git Bash：一个基于 MinGW 的类 Unix 终端环境。没有这个的话，在 Windows 的 CMD 或 PowerShell 里虽然也能用 Git，但很多 Unix 风格的命令会出现兼容问题。Git Bash 能把大部分 Linux 下的体验搬到 Windows 上。
• Git GUI：一个简单的图形化提交工具，说实话不太好用，但关键时刻能应急。
• SSH 客户端：Git for Windows 自带了 SSH 相关工具，这也是为什么我们能直接在 Git Bash 里生成 SSH 密钥。

还有一个非常容易忽略的点：Git for Windows 还提供了一套独立的 SSL 证书库。什么意思呢？就是你在克隆 HTTPS 协议的仓库时，Git 会用它自己带的证书文件来验证服务器身份，而不是用 Windows 系统证书库。这个细节在后面排查 clone 报错时很关键。

1.2 下载地址与版本选择建议

Git for Windows 的官方下载地址只有一个，就是 git-scm.com。进入网站后，页面顶部一般会自动识别你的操作系统，直接点击 Download 就能拿到 64 位版本的安装包。如果你的系统是 32 位（说实话现在很难遇到了），需要在 Downloads 页面里找 32-bit 版本。

版本选择方面，我只有一个建议：不要在官网首页点击那个显眼的 Download 大按钮之前先看一下当前最新版本号。官网首页展示的通常是最新稳定版，当前 Git for Windows 的版本号已经进入到 2.4x 系列。如果你在第三方下载站看到 1.x 或者 2.1x 这种非常老的版本号，直接关掉，不要去用。旧版本在 TLS 协议、SSH 算法兼容性上都有问题，尤其是 2021 年之后 GitHub 和 Gitee 都启用了更严格的加密协议，老版本 Git 会出现无法连接的问题。

提示：下载安装包时注意看文件大小，正常 64 位完整版安装包大约 50-70MB。如果下载的安装包只有几兆，说明可能是精简版或损坏文件。

1.3 安装前的系统检查与路径污染排查

在开始安装之前，我建议花一分钟做两件事。

第一件事，确认系统里有没有装过 Git。直接在 开始菜单 里搜索“Git”，如果已经装了，会看到 Git Bash 或 Git GUI 的快捷方式。也可以在 CMD 里输入git --version，如果返回了版本号，说明系统里已有 Git。这种情况我建议先卸载干净再重新装新版本，因为不同版本混用很容易导致环境变量冲突，最常见的就是多个版本的 Git.exe 同时存在于 PATH 里，你根本分不清当前命令到底调的是哪个。

第二件事，确认用户目录路径是否包含中文或空格。打开文件资源管理器，在地址栏输入%USERPROFILE%回车，看看弹出的路径。如果路径里有中文，比如C:\Users\张三，或者有特殊字符，那么后续 Git Bash 和 SSH 配置会遇到各种奇怪的问题。比如 npm 项目安装依赖报错、SSH 密钥路径识别异常等。这个问题的解决方案只有一个：新建一个英文名的 Windows 用户账户，或者直接重装系统，没有其他更省事的办法。我之前在给一台用户名为“Administrator”的机器配置时没遇到问题，但另一个用户名为“李工”的就遇到了 SSH 密钥权限不生效的怪问题，折腾了几个小时最后发现是路径的锅。

2. Git for Windows 完整安装步骤

2.1 安装向导中的每一步该怎么选

双击安装包后出现的向导界面，大部分选项直接用默认值就没问题，但其中有几个界面需要手动调整。我按顺序把关键页面说一遍，你跟着操作就行。

• Select Components（选择组件）：这里默认会勾选 Git Bash Here、Git GUI Here、Add a Git Bash Profile to Windows Terminal。我建议额外勾选Check daily for Git for Windows updates，开启自动检查更新。如果经常需要处理大文件，还可以勾选Scalar，这是微软贡献的 Git 性能增强工具。
• Select Start Menu Folder（开始菜单文件夹）：保持默认即可，不需要改。
• Choosing the default editor（选择默认编辑器）：这个页面非常关键。默认值是 Vim。如果你没学过 Vim，一旦在提交信息或合并冲突时进入 Vim 界面，会整个人懵掉——因为 Vim 里按 Ctrl+C 是复制不了东西的，输入文字后按 Esc 再输入:wq才能保存退出。我强烈建议在安装时，把这个选项改成你用过的编辑器，比如 Notepad++、VS Code 或者 Sublime Text。改这个设置不会影响任何其他功能，却能避免 90% 的新手卡在 Vim 里出不来的问题。
• Adjusting your PATH environment（调整 PATH 环境变量）：默认选项是“Git from the command line and also from 3rd-party software”。这个选项的意思是，Git 的命令既可以通过 Git Bash 使用，也可以在 CMD 和 PowerShell 里使用（因为会把 Git 的 bin 目录加到系统 PATH）。这一项保持默认就好。

2.2 换行符转换是新手重灾区

安装向导里最需要考虑清楚的一步就是换行符（Line Ending）处理。Windows 系统用回车加换行（CRLF）来表示行尾，而 Linux 和 macOS 用换行（LF）。Git 的职责之一就是处理这两种风格的差异。

安装向导会给出三个选项，这里我推荐所有初学者选第一个：Checkout Windows-style, commit Unix-style line endings。意思是：从仓库拉取代码时，Git 自动把 LF 转成 CRLF，方便 Windows 工具打开；提交代码时，Git 再把 CRLF 转回 LF，这样仓库里保存的永远是 Unix 格式。

为什么推荐这个？因为你一个人选了第二种（按原样检出），队友在 Linux 上改了几行代码推上去，你再拉下来的时候，如果项目里没有.gitattributes文件，会出现整个文件都被标为“已修改”的情况，因为 Git 检测到整个文件的换行符都被改变了。这种问题在团队协作中非常容易引发冲突，而且排查起来很费劲。你要不清楚自己项目到底该用哪种策略，先选第一个，不稳定再说。

提示：如果你的项目本身很规范，维护了一份完善的.gitattributes文件，那么 Git 会优先以该文件中的规则为准，安装向导里的选择影响优先级会降低。但从零开始配置的话，选择推荐的第一个选项仍然是最稳妥的。

2.3 终端模拟器、Pull 行为与凭据管理器

接下来的几个页面很多人会直接点 Next，但其实值得多看一眼。

• Choosing the default terminal emulator：默认是Use MinTTY。MinTTY 比 Windows 自带控制台窗口好用得多，支持真彩色输出和快捷键缩放，我建议保持默认。如果你之前用的是 ConEmu 或 Windows Terminal，也可以在安装后通过git config --global core.askpass等方式调整，但新手不建议折腾。
• Default behavior of git pull：这里默认是Fast-forward or merge。快速合并模式在绝大多数场景下是最稳的。另一个选项是Rebase，虽然能让历史更干净，但如果你对 Rebase 操作不熟，遇到冲突时容易把历史弄乱，新手不推荐。
• Choose a credential helper（凭据管理器）：这里默认选择Git Credential Manager。这个一定要保持默认。它解决的是 HTTPS 协议下的账号密码记忆问题，配置好了之后，第一次 push 会弹出窗口让你登录 GitHub 或 Gitee，之后就不再重复要求输入账号密码。如果你选了 None，每次 HTTPS 推送都得重新输一次密码，纯属折磨自己。

Install之后等进度条走完，重启终端（关闭并重新打开），然后就可以进行环境配置了。

3. 安装完成后的环境配置

3.1 初始化用户信息：用户名和邮箱必须配

Git 装完后第一件事不是创建仓库，而是告诉 Git 你是谁。这一步通过以下命令完成：

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

这两项配置会记录在每次提交（commit）的元信息里。如果你不配，提交时会报错，Git 会拒绝生成提交记录。值得注意的一点是，邮箱不一定要用注册 GitHub 的邮箱，但最好使用你能收到邮件的有效地址。因为如果某个提交出问题，维护者会通过提交记录里的邮箱联系你。

配置好之后，可以用下面的命令确认是否生效：

git config --global --list

输出里会看到user.name和user.email两项，这就对了。--global的意思是全局生效，作用于当前 Windows 用户下的所有仓库。如果某个特定项目需要不同的身份，可以在项目目录里不加--global单独设置。

3.2 让 Git 更好用的三个隐藏配置

除了用户信息，我每次装完 Git 还会做三件小事，这三件事现在的 Git for Windows 安装包大部分已经预设好了，但最好还是确认一遍。

第一是配置默认分支名。以前 Git 默认分支叫master，现在官方和各大托管平台都在推main，新版的 Git for Windows 在安装时就会问你要不要用main，如果你当时没注意选了master，可以手动改：

git config --global init.defaultBranch main

这样以后git init创建的仓库默认分支就是main，避免每次手动创建再切换。

第二是开启彩色输出。默认情况下 Git 在终端里是有颜色的，但某些终端模拟器下可能没有自动开启。手动确认一下：

git config --global color.ui true

这个配置能让git status、git diff等命令的输出按增删改分类着色，绿看新增、红看删除，非常好用。

第三是设置常用别名。个人比较推荐的几个：

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

设置完这些之后，git st就等价于git status，git lg能直观地看到提交历史的分支拓扑图。这属于极少投入、极大回报的配置，强烈推荐。

3.3 解决 Windows 终端中文乱码的正确姿势

在 Windows 上使用 Git Bash，乱码问题一直是个老大难。主要有两种情况：一种是git status时中文文件名显示成转义字符（\346\265\213...），另一种是提交信息里的中文说明变成了问号或乱码。

第一种乱码，解决办法是在 Git Bash 里执行：

git config --global core.quotepath false

顶层配置好之后，中文文件名会正常显示。第二种乱码，通常是因为 Git 的默认编码和文件实际编码不一致。Git 默认把提交信息当作 UTF-8 处理，如果你的提交信息里输入了中文，而 Git Bash 本身能正常显示 UTF-8，理论上不会乱。但如果你在界面上设置了系统区域为“简体中文（GBK）”，就有可能出现提交信息在日志里变成乱码。一个比较稳妥的做法是确保编辑器保存文件时使用 UTF-8 编码。

如果你在用 VS Code 作为默认编辑器，基本不用处理这个问题，因为 VS Code 默认就是 UTF-8。

4. SSH 密钥配置全流程

4.1 为什么需要 SSH 密钥，以及和 HTTPS 的区别

常规的 Git 远程操作支持 HTTPS 和 SSH 两种协议。HTTPS 的优势是配置门槛低，第一次 clone 时输入账号密码就能拉代码，但缺点是：

• 输入账号密码的次数一旦多起来就很烦，就算凭据管理器能记住，也时常出现缓存失效需要重新认证。
• 个人访问令牌（PAT）有有效期，过期后 push 会报权限错误，需要重新生成。
• 部分网络环境下 HTTPS 克隆的稳定性会差一些。

SSH 的方式完全不同。它的原理是：本地生成一对密钥（公钥和私钥），把公钥放到代码托管平台上，之后本地发起请求时，远端会验证你持有的私钥。验证通过就直接放行，全程不需要输入账号密码。这种方式省心、稳定、适合长期使用。

我给你的建议是，所有需要长期操作的仓库，一律用 SSH 协议。HTTPS 可以作为应急备选手段。

4.2 用 ED25519 算法生成 SSH 密钥（2026 年依然是最优解）

Git Bash 提供了生成密钥的能力。具体操作如下：

1. 打开 Git Bash。
2. 执行以下命令，创建密钥：

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

这里选用ed25519算法而不是传统的 RSA。原因很简单：ED25519 密钥更短（公钥 68 个字符左右，而 RSA 2048 的公钥有 400 多个字符）、生成速度快、安全性更高，而且 GitHub、Gitee、GitLab 等平台都完全支持。

命令中的-C参数是注释，最好填你常用的邮箱，方便以后在托管平台上识别这个密钥是做什么用的。

执行后，Git Bash 会询问Enter file in which to save the key，这里默认是C:\Users\你的用户名\.ssh\id_ed25519，直接按 Enter 就行。如果之前已经生成过，它会提示Overwrite (y/N)?，这里千万想清楚，覆盖之后旧密钥就作废了。建议你另外指定一个文件名，比如~/.ssh/id_ed25519_github。

接下来会要求输入口令（passphrase），这里可以留空直接回车，也可以设置一个。我的建议是本地个人电脑上留空，这样 clone、push 时不需要反复输口令，省事。如果是公司电脑且保管较严，建议设置口令，安全性更高。就算设了口令，Windows 下只要启动了 SSH Agent，第一次输入后也会在一段时间内记住口令。

最后，确认两个文件已经生成：

ls -la ~/.ssh

正常情况下，会看到id_ed25519（私钥）和id_ed25519.pub（公钥）两个文件。私钥绝对不能泄露，公钥可以公开。

4.3 查看并拷贝公钥内容

拷贝公钥有两个常用办法。第一种，在 Git Bash 里直接查看并手动复制：

cat ~/.ssh/id_ed25519.pub

输出内容的格式大致是：

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAxxxxxx your_email@example.com

用鼠标从ssh-ed25519开始选中到结尾，复制即可。如果复制不完整，可以改用下面的命令把公钥内容直接写入剪贴板：

clip < ~/.ssh/id_ed25519.pub

这个命令的意思是：把id_ed25519.pub文件的内容作为输入，重定向给 Windows 的clip命令，这样公钥就直接进入剪贴板了。随后在 GitHub 或 Gitee 的设置页面，直接 Ctrl+V 粘贴即可。

4.4 把公钥配置到 GitHub 和 Gitee

GitHub 的操作路径是：登录后点击右上角头像，进入 Settings，左侧菜单选择 SSH and GPG keys，然后点击 New SSH key。在 Title 里随便填一个便于识别的名字（比如My-Windows-PC），在 Key 里粘贴刚复制的公钥，最后点 Add SSH key。

Gitee（码云）的操作路径是：登录后点击头像，进入设置，左侧找到安全设置里的 SSH 公钥。同样填写标题、粘贴公钥，点击确定。

这里有个细节：如果你同时用了 GitHub 和 Gitee，最好在两个平台都加上公钥，不用生成第二对密钥。同一个公钥是可以配置到多个平台的。

4.5 配置多平台时的密钥管理方案

如果你真的需要在同一台电脑上管理多个平台的多个密钥，事情会稍微复杂一点。最常见的场景是：个人 GitHub 一套密钥，公司 GitLab 一套密钥。如果只有一对密钥，你在公司 GitLab 上配置了个人公钥，虽然很多情况下能通，但一旦平台设置了严格的指纹白名单，就会出现密钥不对应的问题。

更稳的姿势是：为每个平台单独生成一对密钥。操作方法：

ssh-keygen -t ed25519 -C "personal@example.com" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "work@company.com" -f ~/.ssh/id_ed25519_gitlab

然后创建一个~/.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_gitlab

这个文件的作用是告诉 SSH 客户端：当你连接github.com时，使用指定的密钥；连接公司 GitLab 时，使用另一把密钥。写好后重启 Git Bash，再测试连接即可。这样能有效避免同一台机器上密钥文件互相踩踏的问题。

4.6 验证 SSH 连接是否成功

配置好公钥后，先别急着 clone 大项目，先验证一下能不能连上托管平台。以 GitHub 为例：

ssh -T git@github.com

首次连接会提示确认远程主机指纹，输入yes回车即可。如果一切正常，会看到类似下面的输出：

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

这就说明 SSH 密钥配置成功了。需要特别注意的是，如果你连接 Gitee，执行：

ssh -T git@gitee.com

成功的提示会不一样，但同样是看到了你的用户名。

测试过程中如果卡住不动（挂了十几秒没有任何输出），先检查网络是否能访问对应平台，再检查 SSH 配置里 HostName 是否写错，最后检查.ssh文件夹的权限是否正常。

5. 高频问题与避坑指南

5.1 常见报错速查表

以下表格中的问题，是我这两年帮人配置 Git 时遇到频率最高的几类，按照故障现象列出了排查方向和解法，可以直接对照使用。

5.2 私钥权限问题：Windows 上最容易忽略的坑

在 Linux 或 macOS 上，SSH 对密钥文件的权限要求非常严格，.ssh目录权限必须是700、私钥文件必须是600，否则 SSH 会直接拒绝用这个密钥。

Windows 上的权限机制和 Unix 不同，但 Git for Windows 提供的 OpenSSH 在检测到私钥文件权限过宽时，同样会拒绝加载。典型的表现是：执行ssh-add ~/.ssh/id_ed25519时报Permissions for 'id_ed25519' are too open。

如果你的私钥文件是从别的机器复制过来的，或者被某些工具自动修改过权限，会遇到这个问题。解决办法是在 Windows 里调整文件的 ACL 权限，操作步骤比较麻烦，需要右键私钥文件 -> 属性 -> 安全 -> 高级 -> 禁用继承 -> 删除所有继承的权限，然后手动添加当前用户为唯一所有者并授予完全控制权。

更省力的办法是：不用修复了，直接把原来那对密钥重新生成一次，然后把新公钥重新配置到远端。折腾旧文件的权限还不如重新生成来得快。

5.3.gitattributes和换行符不要看运气

换行符问题在团队协作里是最隐蔽的。前面安装向导里选择了“Checkout Windows-style, commit Unix-style line endings”，解决的是个人环境的问题。但团队合作时，还需要一份.gitattributes文件来统一规则，否则不同成员的 Git 配置不一致时，仓库里的文件会因为换行符不同而频繁出现 diff。

一个最简单的.gitattributes写在这个位置：仓库根目录下，文件名就叫.gitattributes，内容建议：

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

解释一下：

• * text=auto：让 Git 自动判断文本文件的换行符格式，文件入库时统一转成 LF。
• *.sh text eol=lf：Shell 脚本必须保持 LF，否则在 Linux 服务器上执行会报错。
• *.bat text eol=crlf：Windows 批处理文件用 CRLF，用 LF 的话有时会有奇怪的兼容性问题。

这份文件提交到仓库后，所有成员的 Git 都会按这个规则处理换行符，不再依赖个人安装时的选择。

5.4 更新 Git 时的注意事项

Git for Windows 更新频率不算低，尤其是小版本更新比较多。更新方式有两种：一是安装向导设置里开启自动检查更新后，Git 会定期提醒；二是直接去官网下载最新版安装包覆盖安装。

覆盖安装时要注意，新版安装包不会覆盖你之前的user.name、user.email、SSH 密钥等全局配置，因为这些配置存放在用户目录的.gitconfig文件和.ssh文件夹里，不在安装目录中。所以升级基本是安全的。

但有一个例外：如果跨大版本升级（比如从 2.3x 升到 2.4x），建议升级后执行一次git config --global --list，确认配置没有丢失。同时重新验证一下 SSH 连接，确保~/.ssh/config里的路径仍然有效。

6. 一条龙调试命令清单

最后送你一份实际排查 Git 环境时我用得最多的调试命令清单，全部在 Git Bash 里执行，按顺序跑完就能定位绝大多数环境问题。

# 1. 查看 Git 版本 git --version # 2. 查看当前全局配置 git config --global --list # 3. 查看 SSH 目录内容 ls -la ~/.ssh # 4. 查看 SSH 已加载密钥 ssh-add -l # 5. 测试 GitHub 连接 ssh -T git@github.com # 6. 测试 Gitee 连接 ssh -T git@gitee.com # 7. 测试公司 GitLab 连接（把地址换成你的域名） ssh -T git@gitlab.company.com

如果第 1 步版本正常，第 2 步能看到 user 信息，第 4 步能看到你生成的密钥，第 5 步能通过认证，那么你的 Git 环境基本就是完全健康的。剩下的问题基本都和具体仓库配置有关，而不是环境问题。

7. 一点实操体会

配置 Git 环境这件事，本质上是一次性的。只要把安装、用户信息、换行符、SSH 密钥这几件事一步到位配置好，后面的日常使用会非常省心。我自己当年第一次装 Git 时，因为不熟悉 Vim，在提交信息界面被卡住，最后直接把终端关了重来，后来才知道是编辑器的问题。现在回看，这些坑基本都是信息差的问题——不是不会用，而是没人告诉你该避着什么走。

另外我强烈建议在配置早期就把 SSH 协议作为首选。也许你一开始只在本机玩，不需要远程仓库，但只要后续有 push 到 GitHub、Gitee 或者公司 GitLab 的需求，提前配置好 SSH 密钥能省掉后面大半天的折腾。毕竟等真需要 push 的时候，发现自己连密钥都还没生成，那才叫尴尬。

最后再说一个我个人的小习惯：装完 Git 后，我会顺手在终端里执行一次git config --global --get-regexp alias，看看自己配置的别名都在不在。这个习惯能帮你确认全局配置文件没有被误改或丢失。环境配置这种事，平时多花五分钟，能避免临到头时多花五小时。

希望这篇教程能让你少走几个弯路。有问题欢迎在评论区留言，看到都会回。