企业官网建设流程全解析

才把一台Win11的电脑收拾干净，准备把前端几个项目从旧机器迁过来。装完Git、配好环境那会儿，同事在旁边问了一句：“这东西不是下一步下一步就完了吗？”我当时愣了一下——他说的没错，对老手来说Git安装确实就是“下一步×N”的事。但对刚接触开发没多久的朋友来说，光是安装过程中那几个英文选项就能劝退一拨人，装完右键菜单里找不到Git Bash又是另一拨，配好了SSH连不上远程仓库再劝退一拨。

这篇教程就是写给这些朋友的。我会用Win11（以2026年最新版本为例）从头到尾走一遍Git的下载、安装、环境配置、SSH认证、常用命令和问题排查。文中的每一步都会解释为什么这么选、不这么选会有什么后果，你照着做就行，后面遇到问题也知道去哪儿查。

1. 安装前的准备与核心工具理解

1.1 Git到底在解决什么问题

先说个容易混淆的概念：Git和GitHub/Gitee不是一回事。Git是一个分布式的版本控制系统，运行在你本地电脑上，它的核心能力是记录文件的每次变更、支持分支管理、允许你随时回退到任意历史版本。而GitHub、Gitee这些是基于Git的代码托管平台，相当于把本地仓库同步到云端，方便多人协作和多设备同步。

为什么新人经常把两者混在一起？因为日常操作中用到的命令都是同一套：git clone、git push、git pull……你确实是通过Git命令在和远程平台交互，于是Git就成了那层“看不见的中间人”。安装Git，就是在你的Win11系统里装上这个“中间人”，让命令行工具可以执行版本管理操作。

1.2 Win11环境下安装Git的前置检查

在双击安装包之前，有几件事值得先确认一下。

检查系统版本。写这篇教程时，Win11已经迭代到了27H2这个版本号。你可以在“设置 → 系统 → 系统信息”里看到完整的版本信息。只要你的Win11是64位系统（现在绝大多数都是），就可以放心使用官方文档推荐的64位Git安装包。如果你的系统还是Win10，安装步骤完全一样，只是右键菜单那个坑在Win11上多了一个坎，后面我会单独说。

确认系统架构。右键“此电脑”选“属性”，或者在“运行”里输入msinfo32回车，可以看到“系统类型”一栏写着“基于 x64 的电脑”还是“基于 ARM 的电脑”。绝大多数人是x64，但如果你用的是ARM架构的Win11设备（比如部分新款轻薄本），就需要去Git官网下载对应的ARM64版本安装包。

预留磁盘空间和关闭杀毒软件。Git本体安装后大概占300MB左右，空间不是问题。但有些安全软件会对Git的安装行为产生干扰（比如拦截Git写入环境变量、拦截安装Git LFS插件等）。如果你之前遇到过安装卡死或装完命令无法识别的问题，可以先临时退出安全软件再装。

下载源的选择。关于Git的下载渠道，最稳妥始终是官方站点。官方站点会根据你的系统自动推荐合适版本，下载速度通常也可以接受。如果官网打不开或者下载速度确实太慢，也可以选择一些正规的软件镜像站。但我要提醒一句：不要从不知名的第三方网站下载安装包，这类网站经常捆绑推广软件甚至恶意代码，每年代码托管平台和系统论坛都会有人因为下载了被篡改的Git安装包而中招。

2. Git最新版安装全程拆解

2.1 获取官方安装包与版本选择

Git官网的下载页面会列出当前最新的Windows版本。以2026年初为例，主流稳定版本已经到2.5x系列，新版本主要在性能优化、协议增强和Windows平台兼容性上做了改进。对多数人来说，认准官方推荐的最新稳定版本就够了，没有必要追Beta版。

下载时注意区分两个文件：

• Git-x.x.x-64-bit.exe：标准64位安装包，大多数人下载这个
• Git-x.x.x-arm64.exe：ARM架构设备使用

还有一个偏技术向的选择是PortableGit，也就是绿色免安装版。我建议新手还是老老实实用安装版，因为安装版会帮你配好路径、右键菜单、缓存目录等一堆环境，绿色版需要手动处理的部分太多，对不熟悉系统原理的人来说容易埋坑。

2.2 安装向导每一页到底怎么选

Git安装向导从2.x版本开始变化不大，但每一页的选项都有它的用处。我按顺序带大家过一遍关键页面，顺便说明哪些可以放心用默认值。

阅读许可协议页、选择安装路径页：这两页没什么好说的，路径建议保持默认或者放到一个不含中文和空格的路径下。如果你后面打算用一些需要调用Git的程序（比如VS Code、JetBrains全家桶、Sourcetree等），路径里有中文或空格容易引起奇怪的问题。

选择组件页：这里最核心的选项是Git Bash Here和Git GUI Here，一定要勾选。前者让你在文件夹右键菜单里直接打开Git命令行，后者提供图形化操作界面。其他选项保持默认即可。附加图标那个选项选了也只是在桌面生成快捷方式，看你习惯。

选择默认编辑器：这里默认是Vim，很多新手在这一步会困惑。如果你平时不用Vim，强烈建议在下拉框里选择VS Code或者Notepad++。因为你在执行git commit时，Git会调用默认编辑器让你填写提交说明，Vim对新手太不友好了——打开之后不知道怎么写、不知道怎么保存退出，卡在那里很崩溃。如果你电脑上还没装VS Code，就先保持默认Vim，后面改配置也很简单。

调整PATH环境变量页：这页非常关键，三个选项的差异很大。

第一个选项Use Git from Git Bash only表示只有Git Bash能使用Git命令，CMD和PowerShell里敲不了git。第二个选项Git from the command line and also from 3rd-party software会把Git加入系统PATH，推荐绝大多数人选这个。第三个选项Use Git and optional Unix tools from Command Prompt会覆盖Windows自带的某些工具（比如find、sort），容易引发冲突，不建议新手选。

选择HTTPS后端传输：这一步用默认的Use the OpenSSL library即可。另一个选项是Windows原生证书库，主要用在学校和某些企业环境下，普通用户没必要折腾。

配置行结束符转换：这页是很多人忽略但很重要的坑。Windows系统用CRLF表示换行，Linux和macOS用LF，Git在下载和上传代码时需要在这两者之间做转换。这里建议选第三个选项Checkout as-is, commit as-is，也就是不做任何自动转换，让文件保持原样。这样就避免了不同系统克隆同一仓库时，因为换行符不同而出现“整个文件都被标记为修改”的尴尬情况。如果你和团队都统一用Windows，或者统一用macOS/Linux，选这个最省心。

配置终端模拟器：选默认的Use MinTTY。MinTTY比Windows自带控制台体验好很多，支持更多快捷键和颜色显示。

配置额外选项：三个默认选项都建议保留。启用文件系统缓存可以提升Git操作大仓库时的性能；启用Git凭证管理器可以让Git记住你输入过的账号密码，省去重复认证的麻烦。

配置实验性选项：新手不要勾选实验性的rebase内置支持或伪控制台支持（如果你看到这个选项的话），这些功能还不稳定，没必要折腾。

2.3 Win11右键菜单的坑：安装完右键没有Git Bash

这是Win11用户最常遇到的问题，值得单独拿出来说。

Win11的右键菜单和Win10做了大改版，默认折叠在一组“显示更多选项”里。你刚装完Git时，在文件夹里按右键，只看到“显示更多选项”，点开后才能在二级菜单里找到Git Bash Here和Git GUI Here。这不是安装失败，而是Win11把经典菜单藏起来了。

有两个解决方案：

方案一：接受Win11的默认设计。每次需要打开Git Bash时，先按Shift+F10或者点“显示更多选项”，然后选Git Bash Here。好处是不用改系统设置，坏处是多一步操作。

方案二：把右键菜单改回经典模式。网上流行的改回Win10右键菜单的方法是修改注册表，本质上是把Win11的“显示更多选项”默认展开。具体操作是：按Win+R输入regedit回车，导航到HKEY_CURRENT_USER\Software\Classes\CLSID，新建项{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}，再在它下面新建项InprocServer32，将默认值留空，重启资源管理器（任务管理器里重启“Windows资源管理器”进程）即可生效。

改动前记得系统还原点。这是改动注册表的基本安全操作，不然出问题想反悔就麻烦了。

3. 环境配置三步走

3.1 配置全局用户信息

装完Git后第一件事，不是急着clone，而是先告诉Git“你是谁”。因为你在提交代码时，Git会把作者信息写入每一次提交记录里，没有配置的话提交会直接报错。

打开Git Bash，输入下面两条命令：

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

名字建议用英文或拼音，避免在跨平台协作时出现编码问题；邮箱建议用你注册代码托管平台时用的邮箱，这样提交记录能正确关联到你的账号头像。

查看配置用git config --list。如果哪天想改某一条，重新执行对应的git config命令覆盖就行。

3.2 生成SSH密钥并配置到托管平台

用Git操作远程仓库有两种常用认证方式：HTTPS和SSH。HTTPS方式每次推送代码要输账号密码，虽然Git凭证管理器可以帮你记住，但还是不如SSH密钥认证干净利落。SSH方式生成一对密钥，公钥放到代码托管平台，私钥留在本地，之后推送代码时就不需要反复输入账号密码了。

生成密钥前先检查一下是否已经存在：

ls -al ~/.ssh

如果看到id_ed25519或id_rsa这类文件，说明已经生成过密钥，可以复用。否则执行：

ssh-keygen -t ed25519 -C "你注册平台时用的邮箱"

这里选ed25519算法是因为它比传统RSA算法更安全、密钥更短、生成速度也更快。如果你使用的托管平台或老系统不支持ed25519，可以用-t rsa -b 4096生成长度4096位的RSA密钥。

执行后会问你保存路径和密码短语（passphrase）。保存路径默认即可，直接回车，我建议初学者密码短语也不要设置，因为每次用密钥时都会有额外交互，容易让新手困惑。等以后你明白了passphrase的作用再给私钥加锁也不迟。

生成完后查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的整段内容。然后登录你的代码托管平台（GitHub、Gitee、GitLab都可以），进入“设置 → SSH密钥”或“SSH公钥”页面，把内容粘贴进去保存。

测试连接：

ssh -T git@github.com

如果看到类似“Hi 用户名! You've successfully authenticated”的提示，说明SSH配置成功。

这里补充一个Windows上常见的坑：如果你执行上面命令时报错Permission denied (publickey)，先确认自己是不是把私钥路径弄错了，或者私钥文件权限过大。Windows下对~/.ssh目录权限要求比较严格，可以用下面两条命令调整：

chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519

3.3 让每次提交更省心的全局优化项

我建议在正式使用Git之前，先把这几个全局配置写进配置文件，可以在很大程度上避免后续踩坑。

# 默认分支名设为 main（更主流的叫法） git config --global init.defaultBranch main # Git 命令输出颜色高亮 git config --global color.ui true # 不处理中文文件名转义，解决中文文件名显示为乱码的问题 git config --global core.quotepath false # 缓存凭证，避免每次都要输入账号密码 git config --global credential.helper manager-core

其中core.quotepath false值得多说一句。默认情况下，Git会把非ASCII字符的文件名转义成八进制形式，你在Git Bash里看到的是一串\346\226\207\344\273\266之类的乱码，而不是正常的中文文件名。把这项设为false，中文文件名就能正常显示了。

credential.helper manager-core在Windows上对应Git Credential Manager，它会把密码或令牌加密存储在Windows凭据管理器中，第一次输入后第二次开始就自动带上了。

4. Git Bash使用与常用命令实战

4.1 为什么推荐你用Git Bash而不是CMD

Git装好后，自带的Git Bash是Windows上体验最接近Linux终端的环境。它基于MinTTY和MSYS2实现，支持大部分Unix命令，比如ls、pwd、touch、grep、sed、awk等。这意味着你可以在Windows下练习Linux风格的文件操作，后续用到更复杂的Shell脚本也能跑得通。

相比之下，CMD和PowerShell用的是另一套命令规则（dir、type、copy），粘贴复制快捷键的体验也差一些。对新手统一用Git Bash还有一个好处：网上绝大多数Git教程都假定你在类Unix环境下执行命令，用Git Bash可以减少和教程之间的“翻译”成本。

4.2 从零到第一次提交的完整流程

我这里用一个真实场景带大家走一遍基本流程。假设你建好了一个专门放学习项目的文件夹，现在要把第一个项目托管到远程仓库。

第一步，初始化本地仓库：

cd /d/projects/my-first-project git init

执行后文件夹里会多出一个隐藏的.git目录，这就是Git的版本库，所有的版本信息都存放在这里。

第二步，创建一个文件并让Git接管它：

echo "# My First Project" > README.md git add README.md git status

git add的作用是把文件从工作区加入暂存区。git status用于查看当前仓库的状态。你会在状态输出里看到Changes to be committed，下面列着README.md，意思是它已经被Git捕获为待提交状态。

第三步，提交：

git commit -m "Initial commit"

-m参数后面跟的是本次提交的说明文字。好的提交说明应该清晰地表达“本次改了什么”，比如“Fix login bug”、“Add user profile page”。尽量不要用“修改”、“更新”、“提交”这类泛泛的词，日后翻历史记录的时候你一定会感谢自己当初写了清楚的说明。

第四步，推送到远程仓库。去代码托管平台新建一个空仓库，拿到仓库地址后，在本地添加远程源并推送：

git remote add origin git@github.com:用户名/仓库名.git git branch -M main git push -u origin main

git branch -M main把默认分支名重命名为main，-u参数把本地main分支和远程main分支建立关联，之后直接执行git push就能推送到对应的远程分支。

4.3 分支、回滚与撤销操作的常用命令

分支和回滚是Git的核心能力，也是新手最容易绕晕的部分。我用最少的命令帮你建立操作框架。

分支相关

# 查看所有分支（当前分支前会有*号） git branch # 新建并切换到新分支 git checkout -b feature/login # 切换分支 git checkout main # 或者用新版命令 git switch main # 合并分支（先切换到目标分支，再合并另一个分支进来） git merge feature/login # 删除已合并的分支 git branch -d feature/login

回滚相关

# 查看提交历史 git log --oneline # 输出示例：a1b2c3d (HEAD -> main) 修复登录页样式 # 撤销工作区的修改（还没git add过的） git checkout -- 文件名 # 把暂存区的文件退回工作区（已经git add但没commit） git reset HEAD 文件名 # 回退到上一个提交（同时保留改动在工作区） git reset --soft HEAD~1 # 回退到上一个提交（丢弃改动） git reset --hard HEAD~1

有个铁律值得刻在脑子里：不要对已经推送远程的公共提交使用reset --hard。因为远程仓库的其他协作者可能已经基于那个提交做了后续操作，你强行改写历史会导致大家的仓库分叉。对已推送的提交想要修正，应该用git revert <commitId>，它会生成一个反向提交来抵消目标提交的改动，不会破坏历史线。

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

我整理了一份自己在教学和实际项目中遇到频率最高的问题清单，每一条都是我亲历过、确实解决过的。

5.1 安装阶段的问题

安装时卡住不动。安装向导停在某个页面超过几分钟没反应。常见原因是安全软件拦截了Git安装程序对环境变量的修改或对部分系统目录的写入。解决方法是彻底退出安全软件后重装，装完再重新启用。

安装完成后提示“git不是内部或外部命令”。在CMD或PowerShell里输入git没反应。说明安装时PATH环境变量没配上，或者安装的是绿色版。重装一次，在调整PATH那一步务必选择第二个选项Git from the command line and also from 3rd-party software。如果重装后还是不行，手动检查“系统属性 → 环境变量 → Path”，确认里面有C:\Program Files\Git\cmd。

安装后右键菜单没有Git Bash Here。参考前面2.3节的内容。

5.2 使用过程中的高频报错

5.3 换行符导致整个文件被标记为改动

这个问题在团队协作中非常常见。现象是：你只是打开文件保存了一下，什么都没改，git status却显示这个文件被修改了，git diff显示整个文件的每一行都变了。

原因就是前面安装步骤里提到的换行符配置。Windows默认CRLF，Linux/macOS默认LF。如果仓库里原本是LF，你用Windows的Git默认配置（autocrlf=true）检出时会被转换成CRLF，再提交时又被转回LF，导致Git认为你动了所有行。

如果团队以Windows为主，就让仓库统一用CRLF；如果团队是跨系统协作，最推荐的方式是使用.gitattributes文件在仓库层面固定换行符规则。新建一个.gitattributes文件放在仓库根目录，内容写：

* text=auto

然后提交一次，Git会根据仓库中现有文件的实际情况自动统一换行符规则。这个文件同样需要提交到远程，确保每个协作者都使用同一套规则。

5.4 Win11终端里中文乱码

在Git Bash里正常，但切到Windows Terminal或CMD时中文显示为乱码。这在Win11上经常出现，本质上是字符集不一致导致的。

Git Bash默认UTF-8编码，Windows控制台部分老版本默认GBK。解决方法是在Git Bash里设置：

git config --global core.quotepath false

然后用git config --global gui.encoding utf-8设置图形界面编码，用git config --global i18n.commit.encoding utf-8和git config --global i18n.logoutputencoding utf-8保证提交和日志输出使用UTF-8。最后在Windows Terminal的设置里，把控制台代码页改为UTF-8（执行chcp 65001），或者直接统一使用Git Bash，就一劳永逸了。

6. 实操心得：从“能用”到“好用”的几个习惯

教程写到这里，Git的基本安装和配置已经覆盖完整了。最后根据我自己的实操经验，分享几个让Git从“能用”变成“好用”的习惯。

习惯一：写好提交说明。每次提交时用一句话说清楚“为什么这么改”，而不只是“改了什么东西”。比如“重构登录逻辑以支持第三方OAuth认证”远好于“更新登录页面”。团队复盘时，这样的提交历史能帮你快速定位问题引入的版本。

习惯二：提交前先看差异。执行git commit之前，先跑一遍git diff看看具体改了哪些内容，避免把调试代码、临时打印、甚至敏感信息（比如密码、密钥）一并提交上去。密钥泄露进Git历史是灾难级的，后期清理极其麻烦。

习惯三：小步提交，频繁提交。一个功能拆成多个小提交，每次提交都是完整且可运行的状态。这样做的好处是，当某个改动引入Bug时，你可以精准回退到出问题的那一次提交，而不用被迫放弃整个功能的所有改动。我见过不少同事喜欢一天攒一个大提交，出问题时只能全部推翻重来，非常痛苦。

习惯四：利用别名提高效率。常用命令可以设置简写，比如：

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 --decorate"

之后输入git st就是git status，git lg可以查看带图形的完整提交历史。这些别名会在你频繁使用Git后大幅提升操作效率。

习惯五：定期清理无效分支。已经合并的分支尽早删除，本地远程都已无用的分支用git branch -d清理干净。分支不是越多越显得你工作饱和，它只是代码管理工具，干净整洁的分支列表才能让你在切换上下文时快速定位。

6.1 面对陌生概念时该怎么继续学

这篇文章覆盖了安装配置和基础操作，但Git本身的概念体系远不止这些。如果你发现自己还想深入理解Git的工作机制，我建议按这样的顺序往下学：

先彻底搞懂“工作区、暂存区、本地仓库、远程仓库”这四个概念之间的关系，这是理解一切Git命令的地基。然后学合并的各种方式：merge和rebase的区别、squash合并什么时候用。接着再学cherry-pick、stash、submodule这些进阶操作。最后等你对Git很熟之后，可以去了解一下Git的底层对象模型（blob、tree、commit），懂了这个，Git的绝大多数行为你都能自己推演出来。

学Git没有捷径，但也不用背命令。多用git help <命令>查文档，多在实际项目里操作，比看任何教程都管用。

6.2 关于开发环境的一点补充

这篇文章的标题是Git安装及环境配置，但搜索热词里还有不少关于Node.js、Vue、Python等环境配置的提问。如果在Git配置过程中你发现路径、环境变量这些概念比较陌生，后续在配置Node.js、Python等开发环境时，通常会遇到类似的环境变量配置问题。思路其实都一样：把可执行文件的目录加入Path环境变量，让系统任何位置都能直接调用对应的命令。把这次Git安装中理解到的环境变量概念迁移过去，后面配置别的开发环境会顺手很多。

如果你在安装配置过程中遇到了本文没覆盖到的报错，不妨花点时间阅读错误信息的完整文本来定位问题的方向，搜索结果自然会更准。Git的好处是，它在全球有庞大的用户群，你遇到的绝大多数坑，别人早就踩过并写了解决方案了。