企业官网建设流程全解析

直接开始，不绕弯子。标题是《git的安装和使用（windows）》，但我得先说一句：在Windows上装Git，大部分人其实卡在了“安装之后”。点Next谁都会，真正让你头疼的是换行符替你改了文件、SSH连不上、提交记录里署错名、中文路径乱码这些烂事。这篇文章我会把安装过程、初始配置、日常命令、分支合并、排错这五个阶段全部过一遍，重点放在Windows环境下你一定会遇到的坑和对应的处理办法。

1. 第一步选型：为什么 Windows 上装 Git 会牵扯到一堆“版本”

先别急着下载，搞清楚你装的是什么东西。Windows上不能直接跑Linux那套Git，所以Git官方提供的是基于MSYS2环境编译的版本，Git for Windows就是最主流的那个。你可能在下载页见过“MinGit”“PortableGit”“Git for Windows Setup”这些选项，它们本质上是同一套东西的不同打包形式：

• Git for Windows Setup（官方安装包）：平时装机用这个就行，自带Git Bash、Git GUI、SSH客户端、系统PATH注入，一套全齐。
• PortableGit（便携版）：解压即用，适合不想要安装器、放在U盘里到处跑的人，但不会自动配置PATH和右键菜单。
• MinGit（最小版）：只有git.exe和核心依赖，一般给IDE或自动化工具内嵌用，不适合人类日常操作。

1.1 MSYS2/MinGW 构建与 Cygwin 构建的本质区别

Windows上跑Git这类命令行工具有两条技术路线，理解这个你以后就不会被各种“Git Bash怎么这么怪”“为什么在CMD里报错”的问题整懵。

Cygwin路线是模拟一个完整的POSIX层，把Linux的系统调用翻译成Windows调用，对开发者是最友好的，但性能差、体积大，像一个虚拟机里跑着半套Linux。MSYS2/MinGW路线是直接用GCC编译C代码到Windows原生程序，运行时库尽量最小化，Git for Windows选的就是这条路。Git Bash本质上是MSYS2提供的一个类似于Unix终端的模拟环境，它支持大部分Linux常用命令（ls、grep、sed、awk这些），也能跑bash脚本，但底层全部是Windows进程。

这个区分的实操意义是：Git Bash里能用的命令，不代表CMD和PowerShell里就能用。比如你在Git Bash里敲ls没问题，切到CMD敲ls报错，这不是Git坏了，是CMD根本不认识ls。反过来，Git Bash里访问Windows路径要用斜杠转换规则，比如C:\Users\YourName在Git Bash里通常写成/c/Users/YourName。

1.2 32位还是64位？其实没你想的那么纠结

现在下载页默认给你64位版本，机器内存小于4G的老电脑才需要考虑32位。更需要注意的其实是另外一个选项：

在安装向导的“Select Components”页面，务必保持默认勾选Git Bash Here和Git GUI Here，这两个选项决定了右键菜单里能不能直接出现“Open Git Bash here”和“Open Git GUI here”。很多人在这一步为了“表面清爽”把右键菜单取消，结果后面每次都要从开始菜单启动再cd到项目目录，纯粹给自己找罪受。

1.3 安装向导里那些容易忽略的选项

安装过程大部分点Next就行，但有三处值得停下来思考：

一是默认编辑器选择。如果你没装其他编辑器，默认的Vim会让你在输入commit message时彻底懵掉。没装编辑器的建议在安装前先装个VS Code或者Notepad++，然后在这步选“Use Visual Studio Code as Git's default editor”；已经装好的可以在安装后通过命令切换。

二是PATH环境变量配置。默认选项是“Git from the command line and also from 3rd-party software”，这表示把git放进系统PATH，同时尽可能兼容CMD和PowerShell。选中间那个最稳妥，如果你选择最下面的“Use Git and optional Unix tools from the Command Prompt”，会把一堆Linux命令一起加进PATH，遇到和Windows自带命令重名的情况容易踩雷。

三是换行符转换，这是Windows上最坑的一步。默认选项是“Checkout Windows-style, commit Unix-style line endings”，也就是检出时把LF自动转换为CRLF，提交时把CRLF自动转换为LF。这个选项对绝大多数人是正确的，但它也意味着你以后会频繁看到warning: LF will be replaced by CRLF这类提示。想彻底关掉自动转换，选最下面的“Checkout as-is, commit as-is”，但这会给你和你的队友埋下“明明没改文件却显示全部改动”的大坑。具体处理办法在第二章详细展开。

提示：装完以后Windows搜索框里输入git --version，看到版本号就说明PATH配置成功。如果提示“不是内部或外部命令”，多半是PATH没生效，重启命令行窗口或者注销重登一次。

2. 装完不是结束：三件配置事没做等于白装

Git装完不等于能用。你随便找一个目录执行git commit，大概率会得到一段红色报错，核心是找不到user.name和user.email。很多新手在“git config --global user.name”这一步就开始出问题，下面按优先级说清楚。

2.1 user.name 和 user.email：提交记录上署名是谁

这两个配置决定了你的每次提交在Git记录里显示成谁。需要注意：

• user.name不是你的Windows用户名，也不是GitHub昵称，是你想在提交记录里显示的名字，可以和账号无关。
• user.email建议和你托管平台的邮箱保持一致（比如GitHub的邮箱），这样提交记录才能正确关联到你的账户。GitHub后来出于隐私考虑支持了noreply邮箱，如果你用了这个，也要和平台设置一致。

配置命令如下：

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

--global表示当前用户全局生效，不带这个参数就只对当前仓库生效。检查是否配置成功的命令是：

git config --global --list

这会把所有全局配置项列出来。修改的话重复执行一次同名命令即可，配置错了不可怕，可怕的是提交完之后全队人都看到你用了错误身份。

2.2 换行符问题：为什么明明一行没改却显示整个文件都变化

这是Windows用户最绕不开的坑。简单说，Windows用回车加换行（CRLF）作为行结尾，Linux和macOS只用换行（LF）。Git默认在检出时把LF转成CRLF，提交时把CRLF转回LF，这个机制保证了仓库里的文件永远是LF，而你在Windows上编辑时看到的是CRLF。

麻烦出在下面几种情况：

• 你关闭了自动转换，然后一个文件在Windows上编辑后提交，仓库里就变成了CRLF。
• 队友在Linux上编辑同一行代码，本地是LF，两边都提交后，Git会认为整个文件的所有行都被修改了。
• 你打开一个本来就带CRLF的文件，在某些编辑器和Git的交互下，diff界面看到一个文件全部被标记为修改。

处理原则：仓库里统一用LF，检出时Windows上要不要自动转CRLF取决于你的团队约定。一般情况下保持默认的core.autocrlf=true就行。如果你在一个两位成员分别用Windows和macOS的团队里，可以在仓库根目录放一个.gitattributes文件，对特定类型文件强制声明行结束符，这比依赖每个人的本地配置要可靠得多：

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

以后遇到“没改文件但diff显示全部变动”，先执行git add --renormalize .再重新提交，能解决一部分历史坏记录。

2.3 SSH vs HTTPS：本地免密方案怎么选

在Windows上连远程仓库（GitHub、GitLab、Gitee等），传输方式一般是HTTPS或SSH两种。HTTPS方式每次push要输入用户名和密码，但Windows上有Git Credential Manager帮你在首次输入后记住凭据，之后自动静默提交，适合大多数人。配置方式是：

git config --global credential.helper manager-core

这是新版Git for Windows的默认值，如果发现老版本没有，改成wincred也行，用得省心。

SSH方式需要生成密钥对，把公钥放到托管平台。Windows上用SSH的好处是你自己控制了认证密钥，多设备场景更好管理。生成密钥：

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

一路回车会在C:\Users\你的用户名\.ssh\下生成id_ed25519（私钥）和id_ed25519.pub（公钥）。把公钥内容复制到GitHub的Settings-SSH keys里，然后测试连接：

ssh -T git@github.com

这里有个实操细节：Git for Windows自带的SSH和你系统OpenSSH可能发生端口冲突。如果你装了Windows OpenSSH客户端（通常Win10以上自带），又使用Git默认配置，可能会看到ssh: connect to host github.com port 22: Connection refused或调度器错误。解决办法是让Git使用系统自带的OpenSSH，而不是内置的：

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

也可以把/c/Windows/System32/OpenSSH/加到系统PATH最前面。这一步查不出来的时候，千万别贸然重装Git，先看看是不是两个SSH打架。

3. 日常三连之外，Windows 上最容易踩的坑

很多人把Git用成“add-commit-push三连”，这没错，但你得知道每一条命令到底做了什么，以及Windows上有哪些特有的大坑。

3.1 add、commit、push 的正确姿势与工作区概念

先花三十秒理解Git的三个区：工作区是你的文件目录，暂存区是git add之后文件暂存的地方，本地仓库是git commit之后写入的地方。git add是把改动选入暂存区，git commit是把暂存区快照提交到本地仓库，git push才是把本地仓库的提交推到远程。

实操中最常犯的一个错误是：在项目根目录执行git add .，把一堆不该提交的临时文件一起加了进去。解决办法是养成先看状态再add的习惯：

git status git diff git add <具体文件> git commit -m "feat: 描述你的改动"

git status永远是第一道防线，它告诉你哪些文件被修改了、哪些还没被追踪。Windows上新手常见问题是把node_modules、bin、obj这类依赖生成目录也提交上去，正确做法是在仓库根目录创建.gitignore文件：

node_modules/ dist/ build/ *.log .DS_Store Thumbs.db

Windows上特别容易漏掉.gitignore自身，新建文件时注意文件名开头有点暂时改不了，用命令行创建即可。

3.2 Git Bash、CMD、PowerShell 的差异

Windows下操作Git有三种终端，我在实际教学里会建议初学者优先用Git Bash，原因很简单：Git Bash 是 Git 官方打包的 Unix 环境，语法兼容性最好，教程里几乎所有的命令都能直接复制粘贴跑通。

如果你在CMD或PowerShell里跑Git，有几点要留意：

• CMD不支持单引号，所有git commit message里的单引号要改成双引号，否则报错。
• PowerShell对@符号和某些字符的解析方式不同，比如git log --oneline --all这种参数，个别版本解析时需要用引号包裹参数。
• PowerShell的curl是Invoke-WebRequest的别名，想用真正的curl得先输入curl.exe才能访问真实程序。这个坑曾经让我在处理GitHub API时浪费了半小时。

在Windows上真正要小心的是路径中包含中文或空格。Git本身支持unicode路径，但某些老插件或外部工具（特别是涉及SSH和打包类的程序）对中文路径处理得不好，建议项目文件夹尽量用英文小写命名，senior开发者的习惯是my-project而不是我的项目。

3.3 文件权限和大小写不敏感的坑

Windows文件系统默认不区分文件名大小写：你创建一个Readme.md，再创建一个README.md，在Windows上会是同一个文件。Git在默认配置下对文件名是区分大小写的，这就会导致你在Windows上clone一个仓库、然后把Readme.md改名为README.md，git status显示是正常的重命名，但在Linux上这两个文件同时存在会导致直接无法clone。

如果遇到还需要保留两个大小写不同文件的情况，得调整Git的配置，让文件系统大小写敏感：

git config core.ignorecase false

但要注意，core.ignorecase设为false之后，Windows上原有的文件可能突然消失（因为文件名不匹配），操作前一定备份。大多数情况下我建议维持默认，只在团队跨平台时通过约定来限定文件名格式。

另外一个容易忽略的是文件权限。Windows上Git不会记录可执行权限位，但如果你被git diff中的old mode 100644 / new mode 100755困扰，这说明有队友在Unix环境修改了文件权限。Windows下没法直接调整仓库里记录的权限位，但可以批量修复：

git config core.filemode false

设置之后Git在Windows上忽略文件权限差，就不会过度报告这类变更了。

4. 分支与合并：在 Windows 上处理冲突的实操

分支是Git相对SVN等老版本控制工具的核心优势。新手往往开发都在master上直接提交，这是最危险的习惯。建立分支让你的功能开发、修复、试验都互不影响。Windows上做分支合并主要的问题是合并冲突的提示与编辑器集成，下面拆开讲。

4.1 分支创建合并的日常流程

一个标准流程是这样的：

# 切到主分支并拉取最新代码 git checkout main git pull origin main # 创建并切换到功能分支 git checkout -b feature/awesome-feature # 开发完提交 git add . git commit -m "feat: 完成新功能" # 回到主分支合并功能分支 git checkout main git pull origin main git merge feature/awesome-feature # 推送并删除远端分支 git push origin main git push origin --delete feature/awesome-feature

建议把目标分支更新到最新再合并，避免合并出一堆无谓的历史分叉。git pull是fetch和merge的组合，旧版本默认会生成一次merge提交，这会让你日志看起来很乱。Windows用户可以在拉取时加上--rebase参数让历史更线性：

git pull --rebase origin main

个人体会是：功能分支的生命周期越短越好，尽量让分支只承载一个功能，合并完即刻删除。不要因为“留着备用”就把分支堆满地。

4.2 合并冲突的识别与解决

合并时如果两处修改对同一行都有改动，Git会停下并提示冲突，生成一堆带标记的文件：

<<<<<<< HEAD 当前分支的代码 ======= 被合并分支的代码 >>>>>>> feature/awesome-feature

Windows用户常犯的错是手动用记事本打开改完、保存并直接提交。这错的严重性在于：Git只能通过标记识别冲突，你只删掉标记并没有实际解决冲突，它会认为冲突已解决。

推荐解决方式是用Git GUI合并工具，Git for Windows自带Git GUI但配置麻烦，我比较推荐VS Code（装了之后Git会询问是否作为合并编辑器）。VS Code里冲突部分会高亮成三种颜色：当前内容、传入内容、两者都采用，直接点按钮选择，保存后执行git add并提交。全程不用碰符号。

如果冲突文件数量太多，建议把合并拆成小步骤：先合并一个文件、解决完再继续，比一次性解决所有冲突更容易出错砸锅。

4.3 反悔药：reset、revert、stash

人人都会犯错，Windows上使用reset和revert的差别必须分清：

• git reset --hard HEAD~1：把本地历史彻底回退到上一个版本，工作区同步强制覆盖，所有未提交的改动直接消失，无法找回。
• git commit --amend：把最后一次提交合并并覆盖，适合“commit信息打错了”这种场景。
• git revert <commit>：生成一个反操作的提交，历史是完整的，适合已经push到远程、需要保留历史的情况下撤销某次改动。

需要特别强调的是：已经推送到远程的提交，不要用reset去撤销。因为如果你推回一个和远端历史不匹配的分支，你的队友pull时会进入一个“两个历史不相干”的混乱状态。正确做法用git revert，生成一条新的撤销提交，所有人都能平滑同步。

stash是Windows环境下特别顺手的一个功能，因为你经常要“临时放下手里开发到一半的活儿，去修生产紧急bug”：

git stash # 暂存当前工作区改动 git stash pop # 恢复最近的暂存 git stash list # 查看暂存列表 git stash drop # 丢弃某个暂存

实测中遇到过一个问题：在Windows上git stash pop之后出现冲突，因为你stash里的改动和当前分支的新改动对同一行动了手。这时Git会打出冲突标记，处理方式和普通冲突一样。另外嫉久不恢复的stash一定记得drop，否则积攒一堆无用的快照。

5. 排错：从 SSH 认证失败到乱码的完整排查链路

最后用一个完整的排查过程讲Windows上最容易被搜索到的三类问题。你以后遇到问题，按这个思路来，不要上来就卸载重装。

5.1 SSH 认证失败的完整排查步骤

症状：git push时报Permission denied (publickey).，或者ssh: connect to host github.com port 22: Connection timed out。

排查链路逐条过：

第一步：确认当前本地Git用的SSH是哪一个

which ssh

如果输出路径是/usr/bin/ssh，说明你用的是Git自带的SSH；如果输出C:\Windows\System32\OpenSSH\ssh.exe，说明是系统OpenSSH。二者行为不同，尤其是密钥读取位置可能不一致（一个是/c/Users/你的用户名/.ssh/，一个是C:\Users\你的用户名\.ssh\，路径格式不一样但指向同一个物理目录）。

第二步：确认密钥文件存在且权限正确

在Git Bash里检查：

ls -la ~/.ssh/

正常情况下应有id_ed25519和id_ed25519.pub。私钥权限问题往往出现在刚拷贝过密钥文件时，Windows的NTFS权限系统和Unix不同，但Git Bash下偶尔会发生私钥权限过大的报错。修复办法是打开文件属性，把“继承”关掉，只留当前用户完全控制。

第三步：测试具体连接排错

ssh -T git@github.com -v

-v会输出整个握手过程的日志，重点看两行：debug1: Offering public key: id_ed25519表示本地在尝试用这个密钥；如果后面跟着server accepts key则成功。如果看到Load key "id_ed25519": incorrect permissions，那就是上面的权限问题。

第四步：检查仓库的远程地址协议

git remote -v

如果显示的是git@github.com:xxx/xxx.git说明走SSH，如果显示https://github.com/xxx/xxx.git说明走HTTPS。两种情况报错信息不同，处理方式也不同。

实际经验是：80%的SSH认证失败不是公钥没配好，是本地私钥权限不对或Git用了错误的SSH程序。而且Windows的防火墙或代理也可能阻断22端口。遇到超时问题的，检查你的安全软件和系统代理，但这里不展开——这种属于环境问题，不属于Git本身。

5.2 中文乱码问题

在Git Bash里git log看到中文commit message乱码，或者提交时中文文件名乱码，这是Windows中文环境下的历史遗留问题。

先检查三个配置：

git config --global core.quotepath false git config --global i18n.commitencoding utf-8 git config --global i18n.logoutputencoding utf-8

core.quotepath false解决中文文件名显示为八进制数字的问题，i18n.*解决编码转换问题。还有一类乱码出现在Git Bash窗口里——如果窗口编码不是UTF-8，中文就会显示成鈥樷这样的乱码。解决办法是在Git Bash窗口标题栏右键-选项-文本-本地编码里选UTF-8，或者直接运行：

echo "export LC_ALL=en_US.UTF-8" >> ~/.bashrc

这会把Git Bash环境变量的LANG和LC_ALL固定为UTF-8，避免大部分显示乱码。

5.3 常见警告与提示，以及一条救命的配置

新老手都会看到的一行提示是：

hint: You've added another git path inside your local git repository...

这通常是把Git仓库嵌套到了另一个Git仓库里，多见于你把项目直接clone到了桌面或“我的文档”，而父目录本身已经是一个Git仓库。解决办法是换个干净目录（比如D:\WorkSpace\）重新clone，或者确认子项目需要单独管理时用子模块机制，而不是直接在嵌套目录里操作。

还有一个Windows专属提示容易吓到人：

warning: in the working copy of 'xxx.js', CRLF will be replaced by LF...

这只是一个提醒，不是错误。它提示你本地检出的CRLF会在下次commit时自动转成LF再入库。说明core.autocrlf=true在工作，符合预期。真正需要担心的是，如果你换到Linux环境又关掉了autocrlf，才可能出现文件整体需要重写的状况。

最后给一条救命的配置：在Windows上务必备份你的~/.ssh/目录和全局.gitconfig，前者是你的所有机器身份，后者是你积累多年的配置习惯。重装或换电脑时把这些搬过去，你能在十分钟内恢复完整的Git使用环境，不用重新踩一遍所有坑。