企业官网建设流程全解析

1. 为什么 2026 年了还要认真装一次 Git

先把结论放前面：Git 这东西，装是五分钟的事，装对却是很多人卡半天的坎。我见过太多人，安装包一路“下一步”点到底，结果命令行里敲git提示找不到命令，或者提交代码时中文文件名变成一串八进制乱码，又或者换行符在 Windows 和 Linux 之间来回横跳，把整个团队的 diff 搞得一团糟。这些问题的根子，八成都在安装和初始配置那几步。

这篇内容就是围绕Windows 平台下载安装 Git这件事，把从下载、安装选项、环境变量、初始配置到验证的完整链路讲透。它适合三类人：一是刚接触版本控制、第一次在 Windows 上装 Git 的新手；二是装过但没搞明白那些安装选项到底啥意思、想重新梳理一遍的老手；三是需要给团队写一份标准安装文档、或者要在多台机器上批量部署的运维同学。核心关键词就几个：Git、Windows、安装、配置，但我会把每个选项背后的“为什么”都掰开讲清楚。

我自己的习惯是，任何工具装完不验证等于没装。Git 尤其如此，因为它涉及路径、换行符、编辑器、凭据管理这一堆和系统环境强相关的东西，装完不跑一遍验证流程，等到真正提交代码时才发现问题，排查成本会翻好几倍。所以这篇不只是“下一步下一步”，而是把每一步的取舍逻辑、踩坑点和验证方法都给你摆出来，你照着做，基本能一次到位。

另外说一句，Git 的版本迭代挺快，2026 年当前的稳定版在功能和默认选项上和几年前有些变化，比如默认分支名的讨论、凭据管理器的集成方式等。我会以当前主流稳定版的安装向导为准，同时把那些“版本之间可能不一样”的地方标出来，避免你照着老教程装完发现界面对不上。

2. 下载前的准备工作与版本选择

2.1 确认系统架构与下载渠道

动手之前先确认一件事：你的 Windows 是 64 位还是 ARM 架构。绝大多数台式机和笔记本是 x64，但近几年搭载 ARM 芯片的轻薄本越来越多，如果你用的是这类设备，装 x64 版本虽然能靠兼容层跑起来，但性能和体验都不如原生 ARM 版。查看方法很简单，按Win + I打开设置，进“系统 - 关于”，看“系统类型”那一栏，写着“基于 x64 的处理器”就下 64 位版，写着“基于 ARM64”就下 ARM64 版。

下载渠道我只推荐一个：Git 官方站点 git-scm.com。别去各种软件下载站，那些地方捆绑安装包、版本陈旧、甚至被篡改的情况都出现过。官方站点打开后首页就有醒目的下载按钮，它会自动识别你的系统给出对应版本。如果你想下特定版本或者 ARM 版，进“Downloads”页面手动挑。

提示：下载下来的安装包文件名一般形如Git-2.xx.x-64-bit.exe，认准这个命名格式，如果下到的是压缩包或者带别的后缀，多半不是官方原版。

2.2 版本号怎么读，要不要追最新

Git 的版本号是“主版本.次版本.修订号”三段式。对普通用户来说，修订号（第三段）的更新基本是 bug 修复，无脑跟；次版本（第二段）会带新功能和新配置项，通常也建议跟；主版本（第一段）变动很少，一旦变动往往意味着有较大的行为调整，升级前值得看一眼发布说明。

我的建议是：新机器直接装当前最新稳定版；已经在用的机器，如果没遇到具体问题，不必频繁升级，半年到一年跟一次大版本就够。追最新版的意义在于拿到更好的性能和更少的已知缺陷，但生产环境里“稳定压倒一切”，没必要为了版本号好看去冒风险。

2.3 安装前的环境检查

装之前花两分钟做两件事，能省掉后面很多麻烦。第一，确认你的用户账户有管理员权限，Git 安装需要写入系统目录和注册环境变量，权限不够会中途失败。第二，如果你机器上已经装过旧版 Git，先想清楚是覆盖升级还是先卸载。覆盖升级一般没问题，配置会保留；但如果旧版装得很乱（比如手动改过环境变量、装过多个版本），建议先卸载干净再装新版，避免路径冲突。

还有一点容易被忽略：如果你装了杀毒软件或者系统自带的防护，安装过程中它可能会拦截写入操作，导致安装“看起来完成了”但实际文件不全。遇到这种情况，临时把防护调低或者把安装目录加白名单，装完再恢复。

3. 安装向导逐项拆解：每个选项到底在选什么

3.1 许可协议与安装路径

双击安装包后，第一屏是许可协议，这个没什么好说的，读完点同意继续。接下来是安装路径选择。默认路径一般是C:\Program Files\Git，我建议保持默认，除非你的 C 盘空间实在紧张。原因有两个：一是默认路径下各种工具和脚本对 Git 的查找逻辑最顺，二是路径里带空格虽然 Git 自己能处理，但某些老旧的构建脚本可能会因为空格出问题，默认路径反而最省心。

如果你非要改路径，记住一条铁律：路径里不要出现中文和特殊符号。我见过有人把 Git 装到D:\软件\Git下面，结果某些命令行工具调用时直接报错，排查半天才发现是路径编码问题。英文、数字、短横线、下划线，这些是安全的。

3.2 组件选择：哪些必装，哪些可以砍

组件选择这一屏信息量最大，我逐个说。

Additional icons（附加图标）里的“On the Desktop”是桌面快捷方式，可勾可不勾，看你习惯。但“Windows Explorer integration”这一组值得留意，它包含两个子项：一个是右键菜单里的“Git Bash Here”，另一个是“Git GUI Here”。这两个我强烈建议勾上，尤其是 Git Bash Here，它让你在任意文件夹里右键就能打开一个已经定位到该目录的终端，日常操作效率提升非常明显。

Git LFS（Large File Support）是处理大文件的扩展，如果你会往仓库里放图片、视频、模型文件这类大体积资源，勾上它。纯写代码、仓库里都是文本的话，不勾也行，后面需要了再单独装。

Associate .gitconfiguration files with the default text editor* 这个选项，意思是把.gitconfig这类配置文件关联到默认编辑器。勾上之后双击配置文件就能编辑，方便。但如果你默认编辑器是记事本，编辑这种带格式的配置文件体验一般，可以后面自己配更好的编辑器。

Use a TrueType font in all console windows是给控制台换字体的，勾上让 Git Bash 里的中文显示更正常，建议勾。

3.3 默认编辑器：别小看这一项

安装向导会让你选 Git 的默认编辑器，选项里通常有 Vim、Nano、Notepad++、VS Code 等。这一项看着不起眼，但它决定了你每次写提交信息、解决合并冲突时用什么工具。

如果你不熟悉 Vim 的操作（比如不知道怎么退出），千万别选 Vim，否则第一次git commit没写-m参数时，你会被困在一个全屏编辑器里出不来，那种体验对新手极不友好。我的推荐是：装了 VS Code 就选 VS Code，没装就选 Nano（操作提示直接显示在屏幕底部，对新手友好），实在不行选记事本。

注意：这一项后面可以改，通过git config --global core.editor命令重新指定。所以选错了也不用重装，但第一次就选对能省事。

3.4 分支名与 PATH 环境：两个最关键的决策

默认分支名这一项，安装向导会让你选master还是自定义（比如main）。这是近几年 Git 社区讨论比较多的话题，很多平台新建仓库时默认用main。我的建议是：跟你团队或你常用的代码托管平台保持一致。如果你主要在个人项目里折腾，选main更符合当前主流；如果团队老仓库都是master，那就选master避免混乱。这个值后面也能改，用git config --global init.defaultBranch命令。

PATH 环境变量这一项是整个安装里最重要的决策，没有之一。它有三个选项：

第二个选项是默认推荐，选了之后你在 CMD、PowerShell、VS Code 终端里都能直接敲git。第三个选项会把find、sort这类 Unix 工具也塞进系统 PATH，可能和 Windows 自带的同名命令冲突，导致系统行为异常，除非你明确知道自己要什么，否则别选。

3.5 换行符处理：跨平台协作的隐形杀手

换行符这一项，是 Windows 用户最容易踩坑的地方。Windows 用 CRLF（回车+换行）表示换行，Linux 和 macOS 用 LF（换行）。如果不处理，同一个文件在不同系统上会被认为“整个文件都改了”，diff 一片红，代码评审根本没法看。

安装向导给三个选项：

• Checkout Windows-style, commit Unix-style line endings：检出时转成 CRLF，提交时转回 LF。这是 Windows 上的推荐选项，兼顾本地编辑体验和仓库一致性。
• Checkout as-is, commit Unix-style line endings：检出不动，提交转 LF。适合在 Windows 上开发但要严格保持仓库 LF 的场景。
• Checkout as-is, commit as-is：完全不转换。除非你有特殊需求，否则别选。

我一般选第一个。但要注意，这个设置是全局默认，具体项目里如果团队有.gitattributes文件明确规定，会以项目配置为准。所以真正规范的做法是：全局设一个合理默认，项目里用.gitattributes锁定。

3.6 终端模拟器与凭据管理

终端模拟器这一项让你选 Git Bash 用哪个终端，默认的 MinTTY 就很好，支持调整窗口大小、字体、颜色，别折腾。凭据管理器建议选默认的 Git Credential Manager，它能在你推送代码到远程仓库时弹窗让你登录，并把凭据安全地存起来，省得每次输密码。这一项对经常和代码托管平台打交道的人来说是刚需。

后面还有几个选项，比如文件系统缓存（启用后能提升性能，建议开）、符号链接（一般不开，除非你有明确需求）。这些保持默认即可，不用纠结。

4. 安装后的初始配置与验证

4.1 必做的三项全局配置

装完第一件事，打开 Git Bash（或者任意终端），敲三条命令配置身份信息：

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

这两条是必须的，因为 Git 每次提交都会记录作者信息，没配的话提交会报错或者用一堆默认值，导致提交历史里作者信息乱七八糟。邮箱建议用你代码托管平台账号绑定的邮箱，这样提交能正确关联到你的账号。

第三条是设置默认分支名（如果你安装时没选或者想改）：

git config --global init.defaultBranch main

配完之后可以用git config --global --list查看所有全局配置，确认写进去了。

4.2 验证安装是否成功

验证分三步走。第一步，确认命令能找到：

git --version

正常会输出类似git version 2.xx.x.windows.x的信息。如果提示“不是内部或外部命令”，说明 PATH 没配好，要么重装时选对 PATH 选项，要么手动把 Git 的cmd目录加到系统环境变量里。

第二步，确认配置生效：

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

能正确回显你设置的值就对了。

第三步，做一次真实的提交测试。找个空文件夹，执行：

mkdir git-test && cd git-test git init echo "hello" > test.txt git add test.txt git commit -m "first commit" git log

如果能看到一条提交记录，作者信息正确，说明从安装到配置整条链路都通了。

4.3 中文乱码与换行符的验证

中文文件名乱码是 Windows 上的高频问题。验证方法：创建一个中文名文件，git add之后执行git status，看文件名是否正常显示。如果显示成一串\xxx\xxx的八进制，执行这条命令修复：

git config --global core.quotepath false

换行符的验证稍微麻烦点，但值得做。在一个测试仓库里创建文件提交，然后用git ls-files --eol查看每个文件的换行符状态，输出里i/lf表示索引里是 LF，w/crlf表示工作区是 CRLF，这就是我们想要的组合。如果发现索引里是 CRLF，说明换行符配置有问题，回去检查安装时的选项或者项目里的.gitattributes。

5. 常见问题与排查技巧实录

5.1 安装类问题速查

5.2 配置类问题排查

提交时提示“Please tell me who you are”：就是没配 user.name 和 user.email，按 4.1 节配一下即可。

推送时反复要求输密码：凭据管理器没生效。检查安装时是否选了 Git Credential Manager，或者执行git config --global credential.helper manager手动指定。

编辑器打不开或者打开后卡住：默认编辑器配错了。用git config --global core.editor "code --wait"改成 VS Code（前提是装了 VS Code 并把code命令加进了 PATH），或者改成notepad应急。

5.3 几个我踩过的坑

第一个坑：在中文路径下初始化仓库。有次我把项目放在D:\我的项目\demo下面，git init没问题，但后面某些操作莫名其妙失败，换成纯英文路径就好了。所以项目路径也尽量用英文。

第二个坑：换行符配置和.gitattributes打架。全局设了自动转换，项目里.gitattributes又规定某类文件必须 LF，结果提交时行为不一致。教训是：全局配置只做兜底，项目里一定要有明确的.gitattributes。

第三个坑：以为装了 Git 就有图形界面。Git 本身是命令行工具，安装包里带的 Git GUI 功能很基础。如果你想要好用的图形界面，得另外装 Sourcetree、Fork 这类工具，它们会调用你装好的 Git。别指望装完 Git 就有一个漂亮的界面。

第四个坑：多版本共存导致混乱。有人机器上同时装了系统级 Git 和某个 IDE 自带的 Git，命令行调用的和 IDE 调用的不是同一个，配置对不上。排查方法是用where git（CMD）或which git（Git Bash）看当前用的是哪个，统一到一个版本上。

5.4 卸载与重装的正确姿势

如果确实需要重装，先走控制面板卸载，卸载时勾选“同时删除配置”还是保留，看你需求。卸载完检查一下这几个地方有没有残留：C:\Program Files\Git目录、用户目录下的.gitconfig文件、系统环境变量里的 Git 相关路径。清理干净再装新版，能避免很多玄学问题。

6. 让 Git 更好用：装完之后的进阶配置

6.1 别名与输出优化

Git 命令有些挺长，敲多了累。可以配别名：

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

配完之后git st就等于git status，git lg能看一个带分支图的简洁日志，日常用起来顺手很多。另外建议开启颜色输出：

git config --global color.ui auto

这样 diff、status 的输出会有颜色区分，可读性提升明显。

6.2 与编辑器和终端的配合

如果你用 VS Code，装完之后它会自动识别系统里的 Git。在 VS Code 里打开一个仓库文件夹，左侧源代码管理面板就能直接操作。如果没识别到，在设置里搜git.path，手动指向git.exe的路径。

终端方面，Windows Terminal 是目前体验最好的选择，可以把 Git Bash 配置成它的一个 profile，这样在一个窗口里就能切换 PowerShell、CMD、Git Bash，不用开一堆窗口。

6.3 凭据与多账号管理

如果你同时用多个代码托管平台，或者同一平台有工作和个人两个账号，凭据管理会变得复杂。Git Credential Manager 支持多账号，但配置起来有点绕。一个实用的做法是：不同项目用不同的远程地址格式（比如 HTTPS 和 SSH 混用），配合 SSH 密钥来区分身份。SSH 密钥的配置是另一个话题，核心就是生成密钥对、把公钥传到平台、本地用ssh-agent管理。

提示：生成 SSH 密钥用ssh-keygen -t ed25519 -C "你的邮箱"，ed25519 是目前推荐的算法，比老的 RSA 更安全也更短。

6.4 保持 Git 更新的习惯

最后说个习惯问题。Git 本身也会更新，新版本会修安全漏洞、提性能。Windows 上更新 Git 就是下载新版安装包覆盖安装，配置会保留。我一般半年检查一次版本，或者遇到具体问题时顺手升级。不用太频繁，但也别几年不更新，尤其是安全相关的修复，该跟还是要跟。

装 Git 这件事，说到底就是把“下载、选对选项、配好身份、验证通过”这四步走扎实。我见过太多人卡在后面用的时候才发现前面装得不对，回头排查的成本远高于当初多花十分钟看清楚每个选项。你把这篇里的验证流程走一遍，后面用起来基本不会再有环境层面的糟心事。