企业官网建设流程全解析

刚接触Git的Windows用户，十个里有八个会栽在同一个地方：下载安装一路Next很快就完事，git --version也正常，可真要往远程仓库推代码，要么Permission denied，要么卡在SSH密钥上半天弄不明白。这篇教程我从下载安装讲起，一直写到SSH密钥配好、代码能顺畅推送，全程用的是我在Windows上反复验证过的最稳路径。适合完全零基础的新手，也适合那些装过Git但SSH一直没真正弄通的半新手。读完照着操作，基本能一步到位。

先说一个总原则：Windows上装Git，真正有技术含量的事情发生在安装完成之后。安装过程里大部分选项用默认值就可以，但有几个关键节点必须知道它在问什么，否则后面返工的代价比想象中大得多。

1. 下载安装的第一步：确定版本和下载渠道

1.1 先看清你的系统是64位还是32位

这个问题在2026年听起来有点多余，但我在帮人排查问题时真遇到过在32位系统上硬装64位软件的情况。Win11已经全面64位，Win10也几乎见不到32位了，不过保险起见，装之前花十秒钟确认一下：右键"此电脑"→"属性"，或者按Win+R输入dxdiag回车，看"操作系统"一栏。如果显示"基于x64的处理器"，下载64位版本；如果显示"基于x86"，下载32位版本。

判断系统架构这件事，直接决定你下载哪个安装包。选错了也不是装不上，而是安装过程会提示"不是有效的Win32应用程序"，直接拒绝执行。

1.2 官网下载与版本选择的逻辑

Git的下载渠道其实很多，国内也有各种镜像站，但我的建议始终只有一个：去官网git-scm.com下载。原因很朴素——官网永远是最新版本，不会有被篡改的风险，也不会捆绑乱七八糟的东西。进入官网首页，页面上通常有一个很大的下载按钮，会自动识别你的操作系统。如果你需要手动选择，就点Downloads→Windows，进入下载列表页面。

Windows版本一般提供两个文件：一个是纯64位版本（文件名类似Git-2.xx.x-64-bit.exe），一个是纯32位版本（Git-2.xx.x-32-bit.exe）。你可能还会看到.tar.gz或.zip的压缩包格式，那是便携版用的，新手不用管。下载时认准.exe结尾的安装程序就行。

版本号本身不太需要纠结——Git的版本迭代非常快，新版本几乎都是向下兼容的。你不需要追求最新，但也不建议用几年前的旧版本。旧版Git在Windows上有一些历史遗留问题，比如对ed25519密钥算法的支持不完整，或者对某些SSH配置解析有问题，这些在新版本里都陆续修掉了。如果电脑上已经装过旧版Git，直接覆盖安装新版即可，配置文件和密钥不会被清除。

1.3 便携版和安装版怎么选

Git官网还提供"便携版"，就是把Git解压到一个文件夹里直接用，不写注册表、不占系统全局环境变量。这个东西对U盘党、或者IT管理员批量部署有一定价值，对普通用户则完全不推荐。原因有三个：便携版不会自动写入系统PATH，意味着你在PowerShell或者CMD里敲git命令会提示找不到；便携版不提供右键菜单的"Git Bash Here"入口，每次都要手动打开Bash再切目录，体验非常割裂；便携版没有图形化的凭证管理器集成，后面配置SSH密钥时少了一层便利。

所以，老老实实下载.exe安装版，下一步开始逐项过安装向导。

2. 安装向导逐项过一遍：每个选项背后的逻辑

安装向导大部分界面直接点Next就行，但有几个界面承载了关键决策，下面按出现顺序逐个说明。

2.1 PATH环境变量：最容易埋雷的一项

这个界面标题是Adjusting your PATH environment，三个单选按钮的本意是决定Git命令能在哪些地方被直接调用，而它也是我见过新手踩坑最多的地方。

第一项Use Git from Git Bash only的含义是：只有Git自带的Bash窗口里才能识别git命令，CMD和PowerShell里识别不了。选了这一项，之后你在VS Code的终端里敲git会得到git不是内部或外部命令的报错，新手最容易在这里卡住，因为VS Code用的默认终端是PowerShell。

第二项Git from the command line and also from 3rd-party software的含义是：把Git加入系统PATH，CMD、PowerShell、VS Code终端都能直接用git命令。这一项是推荐选项，也是绝大多数教程默认你选择的选项。

第三项Use Git and optional Unix tools from the Command Prompt则会引入一堆Unix工具，甚至覆盖Windows系统自带的find、sort等命令，容易造成系统级命令冲突，一般只有特殊需求的人才会勾选。

安装时选第二项，这是最稳妥的。

2.2 换行符转换：团队协作的第一大坑

Configuring the line ending conversions界面，三个选项是：

• Checkout Windows-style, commit Unix-style line endings：拉取代码时转成Windows的CRLF换行，提交时转回LF换行
• Checkout as-is, commit Unix-style line endings：拉取时保持原样，提交时统一转成LF
• Checkout as-is, commit as-is：完全不做任何转换

对Windows用户来说，第一项是默认推荐，也是我建议的选择。它的好处是：你在本地用记事本、VS Code打开文件时不会遇到换行符显示异常，同时推送到远程仓库时统一成LF格式，不会把Windows的CRLF污染进仓库。

我见过不少团队因为换行符没配好，导致一次提交的diff里全是"整文件改动"——实际上只是换行符变了，代码逻辑一行没动。这种问题排查起来极度恶心。如果你在纯Windows环境的团队，第一项就够用；如果有跨平台协作，后面我会在最后一章补一个更高级的.gitattributes方案。

2.3 默认编辑器与终端模拟器的取舍

Choosing the default editor used by Git界面，默认是Vim。Vim对经常用命令行的老手来说没什么问题，但新手在git commit时如果误入了Vim界面，会被卡住出不来——网上那些"怎么退出Vim"的求助帖一大半都是从这里来的。如果电脑上装了VS Code，建议直接选Use Visual Studio Code as Git's default editor；如果没装，也可以选Notepad++等文本编辑器。这一步不影响功能，纯粹是使用体验。

Configuring the terminal emulator to use with Git Bash界面，默认选项是Use MinTTY。MinTTY比Windows自带控制台窗口的交互体验更好，支持调整窗口大小、更好的文本渲染、更方便的复制粘贴快捷键。虽然不是所有场景都必须用MinTTY，但Windows默认的conhost.exe在处理Vim、less这类全屏交互工具时经常渲染错乱，所以MinTTY依然是更合适的选择。

2.4 其他安装选项的快速说明

• Select Components页面：默认选项即可，但注意Git Bash Here和Git GUI Here这两个右键菜单项很有用，建议保留。
• Adjusting your PATH之后还有Choosing the SSH executable：新版Git默认使用自带OpenSSH，选择Use bundled OpenSSH即可。这一项和后面配置SSH密钥直接相关，选默认值就是对的。
• Configuring extra options里有一个Enable file system caching，默认勾选，保留它有助于提升大仓库的操作性能。
• Configuring experimental options里通常有一个Enable symbolic links，不建议新手勾选。Windows的符号链接需要管理员权限，而且不少Windows文件系统场景下行为怪异，勾了反而容易出问题。

安装完成后，右键桌面任意位置，如果能看到Git Bash Here，说明安装基本成功了。打开Git Bash，输入：

git --version

看到类似git version 2.46.0.windows.1的输出，就说明Git已经就位。

3. 装完先别急着用：把三处全局配置改对

3.1 用户名和邮箱：git提交记录里的身份ID

Git提交代码时，每次commit都会携带提交者的用户名和邮箱，这个信息独立于你在GitHub或Gitee上注册的账号。换句话说，即使你在GitHub上叫Alice，只要本机Git配置的用户名是Bob，提交记录里显示的提交者就是Bob——这会导致你的提交无法归到自己的账号名下。

配置方法很简单，打开Git Bash，执行两行命令：

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

这里的--global表示全局生效，也就是这台电脑上的所有仓库都用这个身份。如果你希望某个特定仓库使用不同的身份，在该仓库目录下不加--global重新配置即可，局部配置会覆盖全局配置。

建议用户名用GitHub/Gitee上的昵称，邮箱用注册时绑定的邮箱，这样提交记录的头像和账号能正确关联上。

3.2 用git config检查全局配置

配置完成后，用git config --list查看所有生效的配置项。你会在输出里看到user.name=你的名字和user.email=你的邮箱。如果来回配置过多次，想知道某个具体配置项的值，也可以用：

git config --global user.name git config --global user.email

分别查看。这一步看似简单，但值得养成习惯——很多SSH连接问题排查到最后，发现是配置里的用户名打错了。

配置文件的物理位置在C:\Users\你的用户名\.gitconfig，用记事本就能打开，里面是所有--global级别的配置项。如果哪天想删除某个配置项，可以直接编辑这个文件，也可以执行git config --global --unset 配置项名。

3.3 代理配置：只在确实需要时才动

有些公司内网环境访问外部Git仓库是通过代理服务器中转的，这种情况下Git需要单独配置代理，否则连接会卡住或超时。如果你确定自己的网络环境需要代理，可以在Git Bash里配置：

git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890

端口号要根据你实际使用的代理工具来填。但如果你不确定，或者网络环境本身正常，就不要动任何代理配置——我曾经见过有人照着网上的帖子乱配了一通代理，结果Git访问变得奇慢无比，最后还得挨个--unset清掉。记住：Git默认能连上的时候，别画蛇添足。

4. SSH密钥从生成到推送：一条龙实操

4.1 为什么优先用SSH而不是HTTPS

连接远程仓库有两种主流方式：HTTPS和SSH。HTTPS的优点是配置简单，克隆时输入账号密码就行；但缺点是每次推送代码都要认证，即使配了凭据管理器，也远不如SSH来得顺畅。SSH的优点是配置一次之后永久免密，推送、拉取、切换分支都不需要再输入任何账号信息，而且SSH本身是加密传输，安全性有保障。

GitHub、Gitee等平台对SSH的支持非常成熟，我个人的习惯是：只要是长期使用的仓库，一律用SSH方式克隆。HTTPS只用于偶尔一次的快速克隆。

4.2 生成密钥：ed25519还是RSA

打开Git Bash，先检查是否已经有密钥：

ls -la ~/.ssh/

如果看到id_ed25519和id_ed25519.pub这对文件，说明之前生成过，可以跳过生成步骤。如果目录不存在或文件为空，就执行：

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

命令解释：

• -t ed25519：指定密钥算法。ed25519是比RSA更现代的算法，密钥更短、生成更快、安全性更高
• -C：添加注释，通常是邮箱，仅用于标记密钥来源

执行后，系统会提示你选择密钥保存位置，默认是/c/Users/你的用户名/.ssh/id_ed25519，直接回车用默认路径就行。接着会提示设置passphrase（密码短语），这是给私钥加的一层保护，每次使用私钥时都要输入。如果你不想每次都输密码，可以直接回车留空。考虑到这是本地私钥的安全防线，我的建议是设置一个，然后配合后文的ssh-agent实现一次输入、长期免密的效果。

如果某些老旧的GitLab服务器或内网系统不支持ed25519，那就改用RSA：

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

两条命令生成的文件名不同，注意区分。

4.3 让ssh-agent记住你的私钥

设置了passphrase的私钥，如果每次都手动输入太麻烦，可以借助ssh-agent把私钥加载到内存中。Git Bash里执行：

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

第一条命令启动ssh-agent进程，第二条命令把私钥加进去。执行ssh-add后会提示输入passphrase，输入一次即可，之后在当前会话中就不再需要重复输入了。

这里有一个Windows特有的坑：如果直接用Windows自带的PowerShell来执行ssh-add，有可能提示找不到ssh-agent服务。这时可以用管理员权限打开PowerShell，把OpenSSH Authentication Agent服务设为自动启动：

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

做完之后，PowerShell里的ssh-add也能正常工作了。

4.4 把公钥交给GitHub/Gitee/GitLab

私钥留在本地，公钥需要上传到代码托管平台。查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出长这样：

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... 你的邮箱

复制整段内容。然后登录你用的代码平台，以GitHub为例：右上角头像→Settings→SSH and GPG keys→New SSH key，Title随便填（比如Windows-laptop），Key框粘贴公钥内容，保存。

Gitee的位置在：设置→安全设置→SSH公钥。GitLab在：Preferences→SSH Keys。三者的操作逻辑完全一样，核心就一句话：把.pub文件的完整内容贴到平台后台。

4.5 第一次连接测试与trust提示

公钥添加完成后，测试连通性：

ssh -T git@github.com

如果是Gitee，执行ssh -T git@gitee.com；GitLab按实际域名替换。

第一次连接时，系统会提示：

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

这是SSH在询问是否信任这台主机，输入yes回车，该主机指纹会被记入~/.ssh/known_hosts文件，之后就不会再提示了。

如果一切正常，GitHub会返回：

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

看到这行字，说明SSH密钥链路已经完全打通，接下来就能用git clone git@github.com:用户名/仓库名.git这样的SSH地址克隆或推送代码了。

5. 连不上远程仓库：完整排查链路与SSH over 443

配置过程通常不会一帆风顺，下面按实际排查顺序整理最常遇到的问题。

5.1 高频报错对照表

5.2 从ssh -vT开始的排查顺序

遇到连接问题，别急着百度，先自己动手排查。第一步，确认本地是否有密钥被加载：

ssh-add -l

如果输出The agent has no identities，说明私钥没加载成功，回头重做4.3的步骤。如果能看到密钥指纹，但依然连不上，第二步，用详细模式查看连接过程：

ssh -vT git@github.com

输出会拉出一大段debug信息，其中几个关键位置值得关注：

• debug1: Offering public key: ...：说明本机正在向服务器提供密钥，如果能走到这一步，说明本地侧基本没问题
• debug1: Authentications that can continue: publickey：说明服务器还在等待匹配的密钥
• 如果直接卡在debug1: Connecting to github.com [IP] port 22后没有下文，说明22端口出站被卡了

第三步，核对平台后台的公钥是否完整。很多人复制公钥时只复制了前半段，或者不小心复制了多一个换行符，都会导致认证失败。

5.3 SSH over 443：官方支持的备用通道

有些网络环境会限制22端口出站连接，但443端口几乎都是放行的——因为HTTPS流量走的就是443。GitHub官方专门提供了一个备用SSH服务，监听在443端口，地址是ssh.github.com。测试方法：

ssh -T -p 443 git@ssh.github.com

如果这条命令返回Hi 你的用户名!，说明443端口是通的。之后在~/.ssh/config文件里添加如下配置，让Git自动走443端口：

Host github.com HostName ssh.github.com Port 443 User git

保存后，重新执行ssh -T git@github.com，Git会自动切换到443端口连接。这里的原理很简单：SSH协议本身支持指定任意端口，而Git在连接时完全听从~/.ssh/config的指挥。

5.4 多账号场景：用config文件管理多把密钥

如果你同时使用GitHub和公司内部的GitLab，或者有多个GitHub账号，一把密钥就不够用了。正确的做法是为每个平台生成独立的密钥，然后用~/.ssh/config文件做路由。

假设你有两个密钥：id_ed25519_github和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

Host后面的值是连接别名，HostName才是真实域名，IdentityFile指定该域名使用哪把私钥。配置完成后，分别用ssh -T git@github.com和ssh -T git@gitlab.company.com测试，两条链路互不干扰。网上很多多账号配置写得很玄乎，实际上就是在config文件里多写几个区块而已。

6. 日常使用中值得顺手配好的几个点

6.1 Git Credential Manager：HTTPS方式的免密方案

虽然我推荐SSH，但HTTPS场景依然广泛存在——比如某些企业GitLab只开放HTTPS，或者临时克隆一个公开仓库。如果使用HTTPS协议且不想每次输密码，Git自带的Credential Manager能帮上忙。这个组件在安装Git时默认被选中，它的机制是第一次推代码时弹出凭据窗口，输入一次账号密码后，凭据会被安全存储，之后自动复用。

检查是否安装成功：

git credential-manager --version

如果输出版本号，说明组件可用。现在用HTTPS克隆并推送一次代码，系统会自动处理凭据存储，基本不需要手动干预。

6.2 别名配置：少敲几个字母

Git的命令有些比较长，比如看提交历史要敲git log --oneline --graph --decorate，每次都打一遍很烦人。用别名简化：

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

配置之后，git lg就能输出漂亮的提交历史图，git co等价于git checkout。对于高频操作，别名的收益是不可忽视的。

6.3 跨平台换行符的终极方案：.gitattributes

回到2.2节提到的换行符问题。如果你的团队里有Windows、macOS、Linux三种系统的开发者，单靠core.autocrlf很难彻底统一，最好的方案是在仓库根目录放一个.gitattributes文件，强制指定文件的换行符规则：

* text=auto *.js text eol=lf *.md text eol=lf *.bat text eol=crlf

这个文件的意思：大部分文件交给Git自动处理换行符；.js、.md等文本文件统一用LF；.bat批处理文件强制用CRLF，因为Windows的批处理文件在LF下可能运行异常。

.gitattributes比全局配置更可靠，因为它是写进仓库的，全团队共享。如果你在维护一个跨平台项目，建议尽早加上这个文件，并在提交前执行git add --renormalize .把历史文件的换行符统一一次。

我在实际配置新电脑时，整个流程压缩下来大概十分钟：下载安装五分钟，全局配置和SSH密钥三分钟，测试连接两分钟。这套流程重复了很多次，最深的体会是——Git在Windows上绝大多数问题都不是Git本身的问题，而是环境变量配错、换行符混乱、SSH密钥链路没接通这三个老问题。希望这篇教程能帮你一次性把这三点全部搞定，少走我当年走过的弯路。