企业官网建设流程全解析

很多年前我第一次在 Windows 上装 Git，以为就是“下一步下一步”的事，结果装完之后在各种终端里敲git --version，一会儿能用一会儿不能用，配个 SSH 密钥搞到半夜。所以这次我干脆把从下载到 SSH 密钥配置的完整流程，按我自己的实操习惯重新整理一遍。不管你是刚接触 Git 的新手，还是平时只会在 IDE 里点点点、突然被要求走命令行做代码同步的同事，这篇文章都值得你收藏一遍。

先说清楚这篇文章能帮你解决什么：拿到手就能照着做完 Windows 上 Git 的完整安装与环境配置，同时把 SSH 密钥生成、添加到代码托管平台、连接验证这几件事一次搞清楚。重点不是我告诉你“敲哪条命令”，而是让你知道“为什么是这条命令”“这一步不选会有什么后果”。这样才能真正避坑。

（为了照顾从零开始的读者，我会把每个步骤背后的原因也讲清楚。已经是老手的可以直接跳到你需要的章节，但建议至少扫一眼配置部分的几个细节，我踩过的坑你可能正在踩。）

1. 下载安装前的两个关键选择

1.1 官网下载还是国内镜像下载

Git 官网（git-scm.com）其实提供了 Windows 版本的安装包，但国内很多朋友反馈官网下载速度时快时慢，尤其是刚发布大版本那几天，有时候一个几十 MB 的包能卡半天。我之前也遇到过，等了十分钟进度条没动，气得直接退了。

如果你不想忍受这个速度，有两个替代方案比较稳：

• 清华大学开源软件镜像站：地址是 mirrors.tuna.tsinghua.edu.cn/git-for-windows/，里面有个v2.x.x.windows.x的目录结构，找最新的稳定版本就行。
• 阿里云镜像站：mirrors.aliyun.com/git-for-windows/，同样有完整的版本列表。
• 腾讯软件源：mirrors.cloud.tencent.com/git-for-windows/，也值得备用。

三个镜像的内容都是同步官方发布的，校验值也一致，不用担心“是不是改过的包”。如果你在公司内网，下载外网受限，这几个镜像有时候反而是唯一能用的通道。

提示：下载时优先选 64-bit 版本（现在绝大多数 Windows 系统都是 64 位）。如果你的电脑还是 32 位系统，那就只能选 32-bit 安装包了。不确定的话，按Win + Pause打开系统信息，看“系统类型”那一栏。

1.2 安装包版本怎么选

Git for Windows 的版本号一般长这样：2.47.1.windows.1、2.48.1.windows.2。我的习惯是选择“非 rc、非 preview”的正式发布版本，并且避开刚发布的 .0 版本。因为 Git 属于底层工具，安装之后要配合各种 IDE、脚本、CI 流水线使用，太新的版本有时候会和旧系统组件有小冲突，虽然过几天官方就会修，但没必要用自己的环境去试错。

另外，当你看到Git-2.x.x-64-bit.exe和Git-2.x.x-64-bit.tar.bz2这两种文件时，选.exe那个。.tar.bz2是绿色便携版，解压就能用，不需要安装，但环境变量、右键菜单之类的都要自己配，不适合大多数人。

我的建议版本策略：如果你之前已经装了某个版本且用着正常，不用急着升级。工具链稳定比版本新更重要。真正需要升级的场景是：你发现当前版本无法识别某个新平台推送的密钥格式，或者 IDE 提示 Git 版本过低。

2. 安装过程的每一步都不白点

2.1 安装向导核心选项图解

Git 的安装向导看起来就是“Next 到底”，但其中有几步的选择会影响后续使用。下面我把几个关键步骤拆开讲。

第一步：选择安装路径

默认路径一般是C:\Program Files\Git，我建议直接保持默认。有人喜欢改到D:\Git，也不是不行，但要注意：如果路径带空格，部分老脚本处理起来会出问题，C:\Program Files\Git其实本身就带空格，不过 Git 官方已经处理得很好，不会再像十年前那样有兼容问题。

第二步：选择组件

这一步会有很多复选框，默认选项很合理，但有两个地方值得单独看一眼：

• “Git Bash Here”和“Git GUI Here”建议保留。这给你的鼠标右键增加了入口，在文件夹里直接打开 Git Bash 非常方便。
• “Add a Git Bash Profile to Windows Terminal”如果系统是 Windows 11 或者有 Windows Terminal，建议勾上，之后可以在 Terminal 下拉菜单里直接开 Git Bash。

第三步：选择默认编辑器

这里默认是 Vim，很多新手在这步都会懵：以后不管提交代码还是改配置，弹出来的全是 Vim，操作不熟悉的话真的会卡住，不知道怎么保存退出。如果你不是专门用 Vim 的人，建议下拉选成“Notepad++”（如果你装了的话）或者 Visual Studio Code。要是电脑上啥编辑器都没有，那就选 Nano，它比 Vim 友好得多——不过实际上 Git 自带的安装环境里通常会提供 Nano 选项。我个人推荐用 VS Code：界面友好、语法高亮清晰，提交信息写起来舒服很多。

注意：如果安装完成后想改默认编辑器，不用重新安装，执行命令即可：git config --global core.editor "code --wait"前提是 VS Code 已经安装了“Shell 命令安装 code”那一项（在 VS Code 里按Ctrl+Shift+P，输入 “Shell Command: Install ‘code’ command in PATH”）。

第四步：调整 PATH 环境变量

这一步有3个选项：

• “仅从 Git Bash 使用 Git”（Use Git from Git Bash only）：选这个的话，在 CMD 和 PowerShell 里敲git会提示找不到命令，只能打开 Git Bash 用。
• “从命令行以及第三方软件使用 Git”（Recommended）：把 Git 加入系统 PATH，CMD、PowerShell 也都能直接调用。这是官方推荐，也是大多数人的选择。
• “从命令提示符使用 Git 和可选的 Unix 工具”：除了 Git 还把一些 Unix 工具注入到系统 PATH，容易和系统自带命令产生覆盖冲突，不建议选。

第五步：选择 HTTPS 传输后端

这里有两个选项：OpenSSL 和 Windows 原生通道（SChannel）。默认是 OpenSSL，原因很简单：Git 生态和证书体系默认都是走 OpenSSL 的，兼容性更好。如果你在一个强企业管控环境里，公司要求用 Windows 证书库来验证 SSL 证书，那才需要切到 SChannel。这种情况属于少数，其他朋友保持默认就好。

第六步：行结尾转换方式

这一步非常重要，也是新手最容易忽略的：

• 默认选项是“检出 Windows 风格，提交 Unix 风格”（Checkout Windows-style, commit Unix-style line endings）。意思是：从远端拉代码到本地时，自动把行尾从 LF 转成 CRLF；提交到远端时，自动把 CRLF 转回 LF。好处是本地 Windows 工具链兼容性好，坏处是仓库里可能出现“整个文件被标记为修改”的诡异情况（后面我会讲）。
• 第二个选项是“按原样检出，提交时转成 Unix 风格”（Checkout as-is, commit Unix-style line endings）。适合团队统一使用 Unix 风格行尾、你本地也不用那些老旧的 Windows 文本编辑器的场景。
• 第三个选项是“按原样检出，按原样提交”。如果你在纯 Windows 环境且不跨平台协作，可以选这个；但只要是跨平台协作，我都不推荐这个，因为它会把 Windows 行尾直接提交进仓库，团队里其他 Unix 系统成员就会看到一堆“文件变更”。

我的实际建议：如果你常用 VS Code 或现代编辑器，可以选第二个或者干脆用.gitattributes文件统一规范（这个后面细说），新手默认用第一个也能跑通，没必要在这步纠结太久。

第七步：选择终端模拟器

这一步问你 Git Bash 使用哪个终端模拟器：MinTTY 还是 Windows 默认控制台窗口。默认是 MinTTY，它支持一些更丰富的终端控制序列，比如颜色、光标定位，看起来更接近 Linux 终端体验。保留默认即可。只有当你觉得 Git Bash 窗口里选中文本、复制粘贴的交互不习惯时，才考虑切到 Windows 默认控制台。

2.2 安装完成后先做两个小验证

安装结束后，先别急着配 SSH。打开任意终端（Git Bash 或 PowerShell 都可以），依次做两个验证：

git --version

能看到类似git version 2.47.1.windows.1的输出，说明安装成功且 PATH 生效了。

where git

这个命令在 Windows 上会列出 git 可执行文件的路径。如果结果里有多个路径，要留意是不是装了多个 Git 版本。多版本并存是很常见的问题根源：终端里敲git用的是旧版，你以为是新装的，结果行为千奇百怪。遇到这种情况，把旧版本卸载干净，只留一个。

另外建议把 Git 自带的usr/bin目录里的常用命令（比如ls、grep、find）也说一下——它们只作用于 Git Bash 环境，不会影响系统里原来的同名的工具，所以不冲突。有些人以为选第三项才会引入这些工具，其实 Git Bash 内部一直有，第三项只是把它们暴露到系统全局 PATH 而已。

3. 基础环境配置：不配这几项，后面全是坑

3.1 必须设置的 user.name 和 user.email

很多人安装完 Git 直接就去克隆仓库，结果提交代码时要么报错，要么提交记录里的作者信息是一串乱码。原因是 Git 在提交时需要一个作者身份，它优先读取本地的user.name和user.email，没设置的话它就去猜，猜不出来就报错。

打开 Git Bash，执行下面两行，把你自己的信息填进去：

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

这里有两个细节值得注意：

• --global表示当前 Windows 用户全局生效，也就是你这个账号下所有仓库都会用这个身份。如果公司项目和私人项目需要不同身份，不要在这里设置，而是去特定仓库目录下执行不带--global的版本。
• email 建议和你的代码托管平台（GitHub / Gitee / GitLab）注册邮箱保持一致。尤其是 GitHub，它通过邮箱关联提交者头像和主页，不一致的话你的提交不会显示在贡献图上。

验证设置是否生效：

git config --global --list

会输出你设置过的所有全局配置。

3.2 行尾符、缓存与常用优化配置

先看行尾符，这是 Windows 用户最容易踩的坑之一。默认配置是core.autocrlf=true（对应前面安装时选的第一项），它会在检出时把 LF 转成 CRLF，提交时把 CRLF 转回 LF。听起来很贴心，但实际场景里它可能导致一个问题：某些文件（比如.sh脚本、.gitlab-ci.yml、Dockerfile）被强制转换后行为异常，或者在某些编辑器里整个文件被标记为改动。

更推荐的做法是：在仓库根目录放一个.gitattributes文件，显式声明各类文件的换行规则。比如：

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

这样不管团队成员用 Windows、macOS 还是 Linux，行尾都会按照声明统一处理，比每个人的本地配置靠谱得多。如果你不想折腾.gitattributes，那至少把全局的core.autocrlf设置为false或input，结合现代编辑器的自动处理，也能减少一些诡异问题。

再补充几个我常用的配置项，它们对提升日常体验很有用：

# 让 Git 记住 HTTPS 登录凭据 git config --global credential.helper manager # 提交时显示短状态 git config --global status.short true # 默认分支名设为 main（GitHub 风格） git config --global init.defaultBranch main # 设置别名，简化常用命令 git config --global alias.co checkout git config --global alias.ci commit git config --global alias.st status git config --global alias.lg "log --oneline --graph --all --decorate"

关于凭据管理器多说一句：Windows 上 Git 默认会带一个 Git Credential Manager，第一次用 HTTPS 方式推送时，它会弹出一个窗口让你登录托管平台，登录成功后凭据会安全地存在 Windows 凭据管理器里。之后你再推代码就不会重复要求输账户密码了。如果你不想弹这个窗口，或公司自建 GitLab 用 HTTPS 但总提示认证失败，可以在控制面板的“凭据管理器”里查看、修改或删除已有的 Git 凭据，删掉后再重新推一次代码就会重新认证。

3.3 配置文件的存储位置与优先级

Git 配置有三个层级，按优先级从高到低分别是：仓库级（.git/config）、全局级（用户主目录下的.gitconfig）、系统级（安装目录下的etc/gitconfig）。同名配置项，仓库级会覆盖全局级，全局级会覆盖系统级。

在 Windows 上，全局配置文件的路径通常是C:\Users\你的用户名\.gitconfig，可以直接用文本编辑器打开。不过我更推荐用命令来改，因为文件编码和格式如果手动改坏，Git 可能会直接报解析错误。

查看层级配置时，在命令后面加--show-origin能显示每一项来自哪个文件：

git config --global --list --show-origin

这在排查“我明明改了配置，为什么没生效”的时候非常有用。

4. SSH 密钥配置：从生成到验证一条龙

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

有两个原因让我建议 Windows 用户优先配置 SSH：

• 不用反复输密码：HTTPS 方式配合凭据管理器也能记住密码，但 SSH 用的是密钥对，天然就是免密的，尤其在命令行里操作时更顺畅。
• 更安全：SSH 密钥本身不会在网络中传输，传输的只是基于密钥派生出的验证信息。HTTPS 则依赖密码或令牌（Token），一旦终端被记录或截图外泄，风险面更大。

当然，SSH 也有一些不适合的场景：比如某些公司内网出于安全审计要求，只开放 HTTPS 端口（443），不允许 SSH 端口（22）外连，那就只能走 HTTP。这种情况不能硬来，先确认网络策略再选方案。

4.2 生成密钥前的准备与算法选择

先打开 Git Bash，检查一下是否已经有现成的密钥：

ls -al ~/.ssh

如果看到id_ed25519和id_ed25519.pub这类文件，说明已生成过密钥。如果你不记得这个密钥的密码，或者想让新设备用新密钥，可以跳过旧密钥，重新生成一份。

生成密钥的语法是：

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

有几个参数我需要解释一下：

• -t ed25519：指定密钥算法。现在推荐 Ed25519，比传统的 RSA 更短更安全，且 GitHub、GitLab、Gitee 都已经支持。有些老旧的内部系统不支持 Ed25519，那种场景下用 RSA 更稳妥：

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

  新旧选择的核心是看目标平台和服务器支持哪种算法，而不是盲目追新。
• -C：添加备注信息，常见写法是邮箱，但这不是登录凭证，只是方便你记住这个密钥是干嘛用的。
• 执行后会问你保存路径，一般直接回车存到默认位置~/.ssh/id_ed25519即可。
• 然后会让你设置 passphrase（口令短语）。这里我建议设置一个，它是密钥文件的额外保护层。就算别人拷走了你的私钥文件，没有口令也用不了。日常使用可以通过 ssh-agent 把私钥加进内存，之后一段时间内都不用重复输入口令（后面讲）。

设置口令的唯一“缺点”是脚本自动化场景里可能触发交互输入，如果你是纯自动部署环境，可以用ssh-agent或部署平台自己的密钥管理机制，而不是不设口令。

4.3 将公钥添加到代码托管平台

生成结束后，用下面的命令读取公钥内容：

cat ~/.ssh/id_ed25519.pub

输出以ssh-ed25519开头的一大串内容，把它全部复制（注意不要漏掉结尾的邮箱备注）。

然后登录你的 GitHub（或 Gitee / GitLab），路径基本是：

• GitHub：右上角头像 → Settings → SSH and GPG keys → New SSH key
• Gitee：设置 → 安全设置 → SSH 公钥
• GitLab：偏好设置 → SSH 密钥

把复制的内容粘贴到 Key 文本框，Title 随便写一个能认出来的名字，比如“My Windows PC”。保存之后公钥就生效了。

这里有一个容易踩的坑：公钥是一次性显示的内容，不是私钥。id_ed25519.pub可以给别人看，但id_ed25519（没有后缀）是私钥文件，绝不能外传。很多人截图时不小心连私钥一起发到群里，那基本等于把门钥匙给了别人。

4.4 把私钥交给 ssh-agent 管理

每次用 SSH 连接时，如果私钥设置了口令，终端会再问一次口令。为了避免反复输入，可以把私钥交给 ssh-agent：

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

执行ssh-add时会要求你输入一次私钥口令，之后当前终端会话内就不再询问了。

不过这里有个 Windows 特有的问题：Git Bash 里启动的 ssh-agent 只对当前终端有效，关掉窗口就没了。如果你希望每次打开 Git Bash 都自动加载密钥，可以考虑配置~/.bashrc，把上面两行加进去。但这不是必须的，如果你是临时用，每次手动执行也不是很麻烦。

4.5 测试 SSH 连接是否成功

配置完成后，用下面的命令测试和 GitHub 的连接：

ssh -T git@github.com

第一次连接时，终端会提示确认远端主机的指纹（fingerprint），输入yes回车即可。如果一切正常，会看到类似这样的输出：

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

看到这句话，说明 SSH 链路已经通了。同理，Gitee 的测试命令是：

ssh -T git@gitee.com

GitLab 需要根据实际域名来，如果公司自建 GitLab 的地址是gitlab.example.com，那就是：

ssh -T git@gitlab.example.com

注意：如果是自建 GitLab，且端口不是默认的 22（比如公司用了 2222），测试命令要改成ssh -T -p 2222 git@gitlab.example.com。端口信息一般在你创建代码仓库后的页面提示里能看到。

4.6 多平台、多账号的 SSH 配置方法

很多人问：我有 GitHub 和 Gitee 两个账号，甚至公司 GitLab 一个账号，怎么办？全用同一把密钥当然能通，但如果你想隔离不同身份，就需要在~/.ssh/config文件里做主机别名配置。

先创建配置文件：

touch ~/.ssh/config

然后编辑它，示例内容如下：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes Host gitlab.company.com HostName gitlab.company.com Port 2222 User git IdentityFile ~/.ssh/id_ed25519_company IdentitiesOnly yes

几个关键配置点说一下：

• IdentityFile指向对应的私钥路径。
• Port只在你确认目标服务器不是 22 端口时才需要指定。
• IdentitiesOnly yes告诉 SSH 只使用这里指定的私钥，不要自作主张用其他默认私钥去试。这一步很关键，否则系统按顺序尝试多个私钥，可能导致某个平台因为私钥不匹配而连接失败。

配置好后，对应平台的克隆地址直接按原样写就行，不用改 URL 里的主机名，SSH 会根据 Host 自动匹配到对应配置。

4.7 SSH 连接失败的常见排查

这里把我见过最多的几种异常列成表格，方便对照排查：

Windows 上还有一个比较隐蔽的坑：如果你同时安装了 Git for Windows 自带的 OpenSSH 和 Windows 系统自带的 OpenSSH（通常是可选功能），ssh命令调用的可能是版本不一致的那一个。排查方法：

where ssh

结果里如果出现两个路径，注意优先使用 Git 安装目录下的那个（比如C:\Program Files\Git\usr\bin\ssh.exe）。解决方法是调整系统 PATH 的优先级，或直接卸载 Windows 自带的 OpenSSH 客户端。

5. 让 Git 在 Windows 上更好用的几个技巧

5.1 推荐的终端与别名配置

很多 Windows 用户对 Git Bash 的黑底绿字无感，更喜欢 Windows Terminal 的现代外观。Windows 11 自带 Windows Terminal，Windows 10 可以在 Microsoft Store 免费安装。在 Windows Terminal 里可以添加 Git Bash 作为配置文件，体验比默认窗口好很多。

如果你也想折腾一下 Git Bash 的提示符，可以看下~/.bashrc文件，加入一些别名。比如：

alias gs='git status' alias ga='git add .' alias gc='git commit -m' alias gp='git push' alias gl='git pull' alias lg='git log --oneline --graph --all --decorate'

注意：Git Bash 使用的是 Bash 语法，不是 PowerShell。如果你平常用的是 PowerShell，需要另外配 PowerShell 的 profile，不能用这套别名。

5.2 解决 Git 命令中文乱码和文件名问题

Windows 上 Git 还常被问到一个问题：仓库里的中文文件名在git status中显示成\346\265\213\350\257\225.txt这种八进制转义。这是 Git 的转义显示策略，不是乱码，但它确实让人看着头疼。

执行以下配置，可以更友好地显示中文文件名：

git config --global core.quotepath false

core.quotepath=false之后，中文文件名会正常显示原字符。这不会影响仓库内部存储，只是改变了显示行为。

另外，如果你在 Git Bash 里看中文注释有乱码，主要是终端编码和 Git 的输出编码不一致导致的。可以在 Git Bash 窗口右键“Options” → “Text”里把字符集改成 UTF-8，并把本地提交信息的默认编码也统一为 UTF-8：

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

5.3 大仓库与 Windows Defender 的“爱恨情仇”

Windows Defender 默认会对文件实时扫描，而 Git 在操作大仓库时要读写大量文件，有时触发 Defender 扫描，导致git status、git pull慢得明显。如果你所在团队的仓库比较大（几百 MB 甚至几 GB），并且你自己电脑上已经用了别的安全软件，可以考虑把 Git 的安装目录和你的本地仓库目录加进 Defender 的排除列表。

坦白说这操作有安全风险，我一般只在确实感觉“慢到严重影响工作效率”时才会建议用户做。如果你公司安全策略不允许改，那就别折腾了，慢就慢点吧。

5.4 企业 Windows 环境下的代理配置技巧

如果你的开发环境需要走 HTTP 代理访问外网（比如拉取 GitHub 仓库），Git 需要单独配置代理，不会自动读取 Windows 的 IE 代理设置：

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

注意：上面只是格式示例，端口号按你自己的代理软件实际监听的端口填。如果不需要代理了，用git config --global --unset http.proxy和git config --global --unset https.proxy移除配置。

SSH 查询 GitHub 时，代理是按 SSH 配置走的，不是走 Git 的 http.proxy。可以在~/.ssh/config里加：

Host github.com HostName github.com User git ProxyCommand connect -H 127.0.0.1:7890 %h %p

不过这依赖connect工具（Git Bash 自带），如果你用的是 CMD 或 PowerShell 环境，会有额外的适配问题。日常用 Git 走 HTTPS 的话，配置好 http.proxy 就够了，SSH 这块按需处理。

6. Windows 环境下的特殊注意事项

6.1 Git Bash 与 CMD、PowerShell 的差异

很多新手分不清 Git Bash、CMD、PowerShell 到底是什么关系，我这里用一句话说清楚：Git Bash 是一个模拟 Linux 终端的环境，内置了一些 Unix 工具；CMD 是 Windows 传统命令行；PowerShell 是微软主推的现代 shell。Git 命令在这三者的语法基本一致，但脚本写法和路径规则不一样。

• Git Bash 中路径习惯用/c/Users/用户名，CMD 和 PowerShell 用C:\Users\用户名。
• 环境变量引用方式不同：Git Bash 用$HOME，PowerShell 用$HOME也可以，CMD 用%USERPROFILE%。
• 如果你在 PowerShell 里执行cat ~/.ssh/id_ed25519.pub，它会调用 PowerShell 的Get-Content，功能上差不多，但参数风格完全不同。

我的建议是：日常使用统一在 Git Bash 里操作，别一会儿 Bash 一会儿 PowerShell。尤其在执行本文的命令时，统一用 Git Bash 能避免很多莫名其妙的问题。

6.2 权限模型、管理员权限与符号链接

Windows 的权限模型和 Unix 差别很大，这也带来了一些 Git 相关的边界问题。

比如git clone一个包含符号链接（symbolic link）的仓库时，Windows 上可能需要开发者模式或管理员权限，否则符号链接可能被降级成普通文本文件或直接跳过。解决方法是打开“设置 → 开发者选项 → 启用开发人员模式”，这样普通用户也能创建符号链接，Git 就能正常处理这类仓库结构。

另外，有时候你在某些目录下执行git命令时提示“权限不足”，先别急着用“以管理员身份运行”去掩盖问题。很多情况是仓库目录所在的父目录被 OneDrive 同步或公司安全软件锁定，或者目录权限继承关系不正确。检查一下目录属性里的“安全”选项卡更稳妥。

6.3 升级与卸载的干净处理

Git 升级在 Windows 上比较简单：下载新版安装包，直接覆盖安装即可，全局配置和~/.ssh目录不会受影响，因为安装程序不会动用户目录里的配置。

如果因为某些原因要彻底卸载，我建议先备份C:\Users\用户名\.gitconfig和~/.ssh目录，再用“设置 → 应用”里卸载 Git，最后手动检查系统 PATH 环境变量里是否还残留 Git 相关的路径（有些版本卸载不彻底）。不清理干净的话，下次装新版可能出现 PATH 重复或版本冲突。

6.4 公司电脑的特殊策略：BitLocker、受管设备与证书校验

如果你在公司电脑上安装 Git，可能会遇到几类策略限制：

• 设备受 Intune 或域策略管控，无法安装从互联网下载的 exe。
• 公司可能要求 Git 走自建代理，且要求校验企业私有 CA 证书，这时 Git 的 SSL 校验会失败。

第一种情况通常要找 IT 部门申请白名单或使用公司软件中心安装，没什么技术捷径。第二种情况，可以在 Git 配置里指定 CA 证书：

git config --global http.sslCAInfo "C:\Users\用户名\company-ca.crt"

或者临时关闭 SSL 校验（强烈不推荐，除非你完全清楚风险）：

git config --global http.sslVerify false

我不建议用第二种方式，因为它会让你本地所有 HTTPS 推送都失去证书校验，很容易被中间人攻击。更好的选择是向 IT 部门要公司 CA 证书文件，然后配置到 Git 的信任列表里。

7. 提交代码的完整工作流演练

配置完毕，我带你走一遍从新建仓库到推送的完整流程，把前面讲的配置在真实操作里串起来。

7.1 初始化仓库和第一次提交

mkdir my-project cd my-project git init

此时 Git 会在当前目录生成一个.git隐藏文件夹，这就是仓库的“数据库”。然后新建一个文件，比如README.md，写点内容，再执行：

git add README.md git commit -m "初始化项目"

这里有两个新手常犯的细节问题：

• git add .把当前目录所有改动加入暂存区，这是常用操作，但如果你不想提交某些文件，需要提前准备好.gitignore。我建议git init之后立刻创建.gitignore，把编译器输出、依赖目录、系统文件都排除掉。比如 Python 项目至少要忽略__pycache__/和.venv/，Node 项目至少要忽略node_modules/，VS Code 项目忽略.vscode/（如果你不想把个人配置提交上去）。
• git commit时如果编辑器配置有问题，可能卡在 Vim 界面。前面配置了默认编辑器的话则不会遇到。万一已经卡住了，按Esc，输入:wq回车保存退出即可。

7.2 关联远端并推送

如果代码托管平台上已经建好了空仓库，它会给你一个远程地址，比如：

git remote add origin git@github.com:用户名/仓库名.git

然后把本地代码推上去：

git branch -M main git push -u origin main

这里做了一个操作：把本地分支名统一改成main，这是当前平台的默认习惯，避免本地叫master、远端叫main的混乱。-u参数设置了本地分支与远端分支的跟踪关系，之后直接敲git push就能推送。

如果这一步提示 SSH 连接失败，回到第 4 节的排查表格去检查。如果提示“远端已经存在同名仓库但内容不同”，说明远端不是空的，可以加--force强制覆盖，但确认这是你想要的，别在团队共享仓库上用--force。

7.3 拉取、分支与冲突解决

日常开发中，你还需要定期拉取远端更新：

git pull

如果要开一个新功能分支：

git checkout -b feature/login

改完提交后推送到远端：

git push -u origin feature/login

多人协作时，git pull可能报冲突。冲突文件里会出现类似这样的标记：

<<<<<<< HEAD 这是你本地的内容 ======= 这是远端的内容 >>>>>>> origin/main

你需要手动编辑文件，把冲突标记删掉，保留最终想要的版本，然后git add该文件再提交。很多人第一次看到这个标记会慌，其实它只是 Git 在问你“两个版本要我留哪个”。

8. 写在最后的个人经验

这套流程我在 Windows 11 上至少完整走了几十遍，帮同事排查过的更是不计其数。有几点体会想单独说一下。

第一，不要一上来就抄各种“高端配置”。Git 的默认配置对绝大多数人来说已经够用，你先跑通流程，再去按需优化，这样出了问题也能知道自己改了什么。

第二，SSH 密钥一旦生成，备份私钥时一定要加密压缩。我见过有人把私钥文件直接放在私人网盘里，虽然方便，但风险不低。如果必须备份，建议用带口令的压缩包，并存到安全的密码管理器里。

第三，遇到 Git 报错时，读报错信息比搜索更重要。Git 的报错提示已经很友好，大多数情况下它会直接告诉你是凭据问题、网络问题还是文件权限问题。很多人一看到满屏英文就复制去搜索，反而错过了最直接的答案。

第四，如果你在 Windows 上还是觉得 Git 的命令行交互不够顺，可以考虑给 PowerShell 装 posh-git 插件，它会给你显示当前分支、未提交改动等状态，视觉上更像一个增强版的终端提示符。不过这些都是锦上添花的事，核心的安装、配置、SSH 链路，只要按这篇文章走一遍，基本能覆盖你日常 90% 的需求。剩下的问题，等你真正遇到了再回来翻排查表格，往往能找到答案。