企业官网建设流程全解析

做开发这些年，Git是我装得最多、也最能确定“装完就有收益”的工具。不管你是刚转行写代码的新人，还是写博客、管文档、维护个人项目的朋友，只要跟文本、代码这类文件打交道，Git基本就是绕不开的那道坎。网上Git安装教程其实一抓一大把，但很多要么只讲命令不讲原理，要么把安装界面哗啦哗啦一路Next到底，选项什么意思完全没交代。你照着装完，后面一遇到报错还是一脸懵。

这篇教程我就用最直接的方式，从下载渠道、安装选项、初始化配置、SSH密钥，到日常高频命令和常见报错排查，一步一步拆开讲清楚。我会把每个安装界面里该勾什么、该选什么、为什么这么选，全部说明白。哪怕你之前完全没接触过Git，只要按着这篇走一遍，后面基本不会再因为环境问题卡壳。老手也可以直接跳到配置和报错部分，看看有没有自己踩过但没解决的坑。

1. 装Git之前，想清楚这三个底层问题

很多人上来就下载、双击、Next，装完就算了。但如果你不理解Git到底在干什么，后面每个选项你都会犯迷糊。所以我先花几分钟把最核心的概念讲透，这样后面安装选型的时候，你就能立刻反应过来每个选项在说什么。

1.1 版本控制到底解决了什么

想象一个最原始的场景：你写了一篇论文或者一份代码，改来改去，最后桌面上出现了“论文终版.doc”“论文终版2.doc”“论文终版2_改完.doc”“论文终版2_改完_真的不改了.doc”。这种情况在只处理单个文件时还能忍，一旦项目里有几十个文件、多人协同，这种“手工版本管理”会直接崩盘。

版本控制系统就是来解决这件事的：它会帮你记录整个项目在每个时间点的快照，你随时可以回到任何一个历史版本，可以对比任意两个版本之间的差异，可以拉出任何一条分支去尝试新想法而不影响主线。而在所有版本控制工具里，Git是目前事实上的标准，没有之一。

1.2 三个区域模型：工作区、暂存区、版本库

Git和其他版本工具最不一样、也最容易让人晕的点，就是它有“工作区”“暂存区”“版本库”三个区域。你可以把它想象成做饭流程：

• 工作区就像你厨房台面上正在切的菜，一切改动都发生在这里，但还没进冰箱。
• 暂存区就像你把切好的菜装进保鲜盒，相当于跟Git说“这些改动我确认要留下来了”，但还没盖盖子。
• 版本库就是冰箱，当你执行commit时，相当于把保鲜盒放进冰箱，这一瞬间项目状态被完整记录成一个版本，以后随时可以取出来看。

理解了这三个区域，后面所有命令你都好理解了：git add是把改动从工作区放进暂存区，git commit是把暂存区内容做成一个永久版本，git checkout或git switch是切换/恢复某个历史版本到工作区。

1.3 分布式和集中式的差异

Git是分布式版本控制系统，和老的SVN这种集中式系统有本质区别。集中式系统的仓库只有一个中心服务器，每个人从服务器拉代码、改完再提交回服务器；一旦服务器挂了，整个项目的历史就全完了。

Git则是每个开发者本地都有一份完整仓库，包含全部历史记录。就算远程服务器彻底没了，任何人手里那份完整克隆都能恢复一切。这也是Git在开源世界和现代公司里全面胜出的原因：离线能干活、冗余更安全、分支更轻量。

2. 安装前的准备：版本、渠道、路径一个都不能少

在双击安装包之前，有几个准备工作值得花两分钟做一下，能帮你省掉后面不少麻烦。

2.1 从官网还是国内镜像下载

Git的官网是git-scm.com，页面右上角有Downloads入口，进去后会自动识别你的操作系统，直接点Windows下载就行。官网下载的优点是永远是最新稳定版，缺点是部分网络条件下访问GitHub或者下载速度可能比较慢。

如果你发现官网下载速度很慢，或者直接打不开，可以用国内镜像。阿里云镜像和腾讯软件源都有Git的Windows安装包，下载速度基本是秒下，版本也只是比官网滞后一点点，完全不影响使用。

2.2 32位还是64位，别看到Next就乱点

Windows上安装Git，最常见的坑之一就是选错安装包的位数。现在的电脑内存如果超过4GB，系统基本都是64位的Windows 10或Windows 11。你可以右键“此电脑”选“属性”，在弹出的界面里看到“系统类型”一栏，写着“64位操作系统”就下载64位安装包。

如果你不确定，优先下载64位。只有在“系统类型”明确显示x86或32位时，才下载32位版本。装错位数的话，装完倒是也能运行，但会有兼容性隐患，尤其是后续装TortoiseGit这类GUI工具时，位数必须完全对上，否则会无法启用右键菜单。

2.3 安装前预备：关闭杀软、理清已有Git版本

还有两件小事值得在安装前处理：

第一，如果你电脑上装了某些实时扫描比较激进的安全软件，建议安装Git时暂时退出。Git安装包本身没毛病，但安装过程中需要往系统目录写入文件和修改环境变量，个别安全软件会拦截导致安装不完整。装完再重启安全软件就行。

第二，先确认电脑里是不是已经有一份Git。方法很简单，按Win+R输入cmd，回车后在黑窗口里输入git --version，如果返回了类似git version 2.40.0的信息，说明已经装过了。你只需要确认版本够不够新，没必要重复安装；如果返回“git not found”或“不是内部或外部命令”，那就是没装，继续往下走。

3. Windows全图文安装：每个窗口到底选什么

接下来进入正题：Windows下Git的完整安装过程。我会把每个安装界面的选项都拆开讲，告诉你每个选项是干嘛的、推荐怎么选、选错了会有什么后果。

3.1 组件与右键菜单

双击下载好的安装包，第一屏是GNU General Public License，直接点Next进入下一步。

选择安装路径这一屏，我一般就用默认的C:\Program Files\Git。除非你对C盘空间有洁癖，否则不建议改路径，因为很多GUI工具和IDE会自动去默认路径找Git，改到奇怪位置后可能出现“无法定位Git安装目录”的报错。

接下来是安装组件界面，这一屏有几个需要注意的勾选项：

• Additional icons -> On the Desktop：桌面快捷方式，个人觉得没必要，有需要的可以勾。
• Windows Explorer integration -> Git Bash Here 和 Git GUI Here：强烈建议都勾上。勾完后，你在任意文件夹里点右键，就能直接打开Git Bash或Git GUI，这后面做本地仓库操作实在太方便了。
• Git LFS (Large File Support)：建议勾选。它是Git对大文件的扩展支持，团队协作里传二进制大文件时必备，早装早省事。
• Associate .git* configuration files...：把.git开头的配置文件关联到默认文本编辑器，建议勾选。
• Associate .sh files to be run with Bash：让.sh脚本默认用Bash运行，建议勾选。
• Use a TrueType font in all console windows：控制台使用TrueType字体，建议勾选，终端字体会清晰不少。

组件界面下面的“Additional icons”“Windows Explorer integration”这些区块，你全部按上面说的选就行。

3.2 编辑器、PATH、换行符、终端模拟器这四个关键选择

组件选完，后面几屏是重点，很多人就是在这里一路Next然后踩坑的。

第一个关键选项是选择默认编辑器。Git有个重要操作是写提交信息，默认会用Vim编辑器打开，但Vim对新手不太友好，进去之后不知道怎么保存退出（按i进入编辑、按Esc然后输入:wq回车保存退出），很容易卡住。我建议这里直接选你自己熟悉的编辑器。如果你装了VS Code，在下拉框里选“Use Visual Studio Code as Git's default editor”；如果你平时用Notepad++、Sublime Text，也都可以选。实在没装任何编辑器，那还是用默认的Vim，记住刚才说的保存退出方法就行。

第二个关键选项是Adjusting your PATH environment，也就是把Git加到系统PATH里。这里有三个选项：

• ONLY use Git from Git Bash：只在Git Bash里能用git命令，在cmd和PowerShell里用不了。不推荐。
• Git from the command line and also from 3rd-party software：推荐选这个。它会把git.exe路径加进系统PATH，cmd、PowerShell、Git Bash以及IDEA、VS Code这些第三方软件都能直接调用git命令。绝大部分场景都该选这个。
• Use Git and optional Unix tools from the Command Prompt：这个会在PATH里加入完整的Git自带Unix工具集，虽然功能强大，但会覆盖Windows系统自带的find、sort等命令，容易引发系统级冲突。除非你明确知道要干什么，否则别选。

第三个关键选项是配置行结束符（line ending conversion）。Windows用的是CRLF（回车+换行），macOS和Linux用的是LF（只换行）。如果不同系统的代码混在一起提交，Git会频繁提示换行符被替换，看着烦，还可能造成文件差异。这个选项有三个选择：

• Checkout Windows-style, commit Unix-style line endings：推荐。检出代码到工作区时是CRLF，提交到仓库时转成LF，这样Windows本地开发正常，仓库里保持统一LF。
• Checkout as-is, commit Unix-style line endings：代码原本是什么换行符就检出什么，提交时统一转LF。如果你团队全是Windows，可以选这个。
• Checkout as-is, commit as-is：不转换。跨平台协作时会产生大量无意义的换行符变更，最不推荐。

第四个关键选项是选择终端模拟器（terminal emulator）。Git Bash有两种显示方式：

• Use MinTTY：默认推荐，终端体验更好，支持彩色输出和快捷键，外观和Linux终端类似，建议保持默认。
• Use Windows' default console window：用传统cmd窗口来展示Git Bash，外观比较旧，但对某些右键粘贴习惯的人更友好。我建议选MinTTY，颜值高且不容易遇到乱码。

后面还有几个选择，比如git pull的默认行为，默认选第一个，意思是git pull时自动合并（fast-forward or merge），这对绝大多数场景都没问题；追求线性提交历史的团队可以选手工rebase，个人使用保持默认就行。凭据管理器选默认的Git Credential Manager，它会在你第一次拉取私有仓库时弹出窗口保存账号密码，避免每次都要输入用户名密码，非常省事。

最后的额外选项里，Enable file system caching建议勾选，它让Git操作大仓库时性能更好。Enable symbolic links可以不勾，Windows下符号链接涉及开发者模式权限，处理起来很麻烦，普通使用不建议开。实验性选项保持默认不勾就行。

3.3 安装完成后的验证

安装过程持续一两分钟，点Finish后，我来验证一下是否安装成功且能用。

按Win+R输入cmd，回车打开命令提示符，输入：

git --version

如果能返回类似git version 2.55.0的版本号，说明Git已经成功进入系统PATH。然后再输入一条：

git --help

如果能看到Git的基本命令列表，说明Git的主程序、文档和内部工具都没问题，安装成功。顺手再试一下右键菜单：在任意文件夹里右键，如果出现“Git Bash Here”和“Git GUI Here”两个选项，说明组件也装对了。

4. 装完不能跑：初始化、SSH密钥与远程托管

很多教程到这里就结束了，说“安装完成，开始用吧”。但真实情况是：你只装了Git本体，还没告诉Git你是谁、也没打通和远程仓库的连接。所以这一步才是决定你后面能否顺畅使用的关键。

4.1 设置用户名与邮箱

Git每次提交时都会记录提交人的用户名和邮箱，如果不设置，提交时经常会在日志里出现一堆奇怪的默认值，甚至直接提交失败。打开Git Bash，输入下面两行，把名字和邮箱换成你自己的：

git config --global user.name "你的名字" git config --global user.email "your_email@example.com"

注意，用户名不一定要和某个平台的账号一致，但建议保持一致，这样提交记录能正确关联到你的Gitee或GitHub账号。邮箱建议用你注册平台账号时填的那个，同样是为了让提交记录和账号关联上。

设置完可以用git config --list查看所有生效配置。这里有个小知识点：git config有三种作用域，分别是system（系统级）、global（用户级）、local（仓库级）。global就是当前Windows用户全局生效，local是去某个仓库目录下执行时只对该仓库生效。常规本地开发，设置global就够了。如果你将来遇到“为什么在这个仓库里设置没生效”这种疑问，想想是不是local配置覆盖了global，用git config --local --list去查就能排查出来。

4.2 生成SSH密钥并发布到Gitee/GitHub

接下来是打通远程仓库的核心步骤：生成SSH密钥。SSH密钥是一对加密文件，公钥放到代码托管平台，私钥留在本地，这样一来你拉代码、推代码时就不用每次输密码，而且传输是加密的。

在Git Bash里输入：

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

这里的ed25519是目前推荐的密钥类型，比传统的RSA 2048/4096更短、更快、安全性也更高。如果某些老机器或老平台的服务器不支持ed25519，可以退回RSA方式生成：

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

回车后，系统会提示你选择密钥保存位置，默认是~/.ssh/id_ed25519，直接回车即可。接着会提示输入passphrase，这是一个额外密码，给私钥再加一层保护。如果你习惯不打密码，直接回车两次就行；如果设置了这个密码，每次SSH操作都要输入一次，所以建议大家在自己个人电脑上直接留空就行，办公电脑为了安全可以设置。

密钥生成完成后，查看公钥内容：

cat ~/.ssh/id_ed25519.pub

屏幕上会有一段以ssh-ed25519开头的长字符串，这就是你的公钥。复制整段内容。

然后登录你的Gitee或GitHub，在头像菜单中找到“设置”，左侧菜单里找到“SSH公钥”或“SSH and GPG keys”，把公钥粘贴进去，标题随意写一个，确认保存。这里要注意一点：公钥粘贴时不能有多余的空格和换行，尤其是从PowerShell里复制时容易带一些隐藏字符，粘进去后最好仔细看一眼前后有没有空行。

4.3 验证连通性和第一个clone

公钥配置好后，在Git Bash里验证连接是否成功。如果你用的是Gitee，执行：

ssh -T git@gitee.com

如果是GitHub，执行：

ssh -T git@github.com

第一次连接会询问你是否信任该主机，输入yes回车即可。如果连接成功，Gitee会返回类似“Hi 你的昵称! You've successfully authenticated, but GITEE.COM does not provide shell access.”的提示，看到这行字就说明SSH打通了。

接下来clone一个仓库试试水。在你的Gitee或GitHub上新建一个仓库，复制它的SSH地址（形如git@gitee.com:用户名/仓库名.git），然后执行：

git clone git@gitee.com:用户名/仓库名.git

如果仓库成功下载到本地目录，说明从安装、配置、SSH密钥到远程连接全链路已经彻底打通，你也可以正式开工了。

5. 从会用Git到用得高效：命令串联与进阶技巧

装好、配好、能clone之后，最重要的就是日常迭代里把Git命令用顺。这一节我用一个完整的场景把高频命令串起来，再讲几个很多人问的进阶技巧。

5.1 高频命令走一遍完整提交流程

假设你在本地刚clone下来一个仓库，开始开发新功能。整个日常循环是这样的：

# 1. 查看当前状态 git status # 2. 查看改了什么内容 git diff # 3. 把改动加入暂存区 git add . # 4. 提交一个版本 git commit -m "feat: 增加用户登录功能" # 5. 推送到远程 git push # 6. 拉取远程最新代码 git pull

这套命令看起来简单，但有几个细节值得注意。git add .会把当前目录下所有新增和修改的文件加入暂存区，但如果你有不想提交的文件，比如编译产物、本地配置、日志文件等，应该在项目根目录创建一个.gitignore文件，把这些路径忽略掉。这样git status就不会再提示这些文件，git add .也不会误提交。

git commit的提交信息建议遵循一定规范，最常用的是“type: description”格式，比如feat表示新功能，fix表示修bug，docs表示文档变更，refactor表示重构。这种规范在团队里尤其重要，因为所有人刷git log时，一眼就能看出每次提交的目的。

git pull实际上相当于git fetch加git merge的组合，就是把远程新提交拉下来，和本地当前分支合并。如果本地有未提交的改动，pull时可能会因冲突而报错，这时可以先把本地改动commit了，或者用git stash暂存起来，等pull完再git stash pop恢复。

5.2 修改提交信息与补齐遗漏：commit --amend

很多人在提交代码后，经常遇到两种情况：一是commit -m后面写的提交信息打错字了，或者写得太随意，想改；二是提交完才发现漏提交了某个文件，想让漏掉的文件并入上一次提交，而不是再产生一条“fix: 补提交”这种没营养的记录。

这两种情况都可以用git commit --amend解决。第一种情况，直接执行：

git commit --amend -m "正确的提交信息"

第二种情况，先把漏掉的文件加入暂存区，再执行：

git add 漏掉的文件 git commit --amend --no-edit

这里的--no-edit表示沿用上一次提交信息，不需要重新输入。amend的原理是把当前暂存区的改动合并进最近一次提交，并生成一个新的提交哈希值，本质上是用一条新提交替换旧提交。

这里必须提醒一个关键点：amend一定要在代码push到远程之前使用。如果这条提交已经push到远程，而本地又amend了，两边的历史就不一致了，你再push时会被拒绝，必须用git push --force-with-lease强制覆盖，这在多人共用分支时非常危险，可能抹掉别人的提交。所以我的经验是：amend只用于“还没推出去”的本地提交；已经推到远程且跟别人协作的分支，宁可多提交一条fix进去，也别强制覆写历史。

5.3 多分支并行开发神器：worktree

工作里最烦的场景之一就是：你在主分支开发A功能，突然线上出了一个紧急Bug，需要切换到另一个分支去修复。但本地工作区还藏着一堆改到一半的代码，既不能commit也不能丢。

传统办法是git stash暂存，切分支修Bug，修完再切回来stash pop。但如果你同时维护多个分支，每个分支都需要各自的工作目录时，stash来回切就非常痛苦了。Git提供的worktree命令能优雅地解决这个问题：它允许你在同一套本地仓库上，同时checkout多个分支到不同目录，每个目录是一个独立工作区，互不干扰。

常用操作如下：

# 为某个新分支创建一个新工作目录 git worktree add ../feature-login -b feature/login # 列出所有工作目录 git worktree list # 删除某个工作目录 git worktree remove ../feature-login

这样你可以在主目录继续开发A功能，在另一个目录修复线上Bug，两边随时切换、随时编译，完全不冲突。worktree共享同一个.git对象库，所以不会像复制一份仓库那样占用双倍磁盘空间，只会多一份工作区的代码副本，性价比很高。

有几个使用worktree时的坑值得一提：删除工作目录前，确保这个分支没有未提交的改动，否则git worktree remove会拒绝执行；如果想强制删除，要加--force。另外，worktree不能在同一仓库中“同时且重复”checkout同一个分支，一个分支同时只能出现在一个工作树里，这个限制是设计使然，习惯了就好。

5.4 小乌龟与IDEA集成，不敲命令也能用

如果你不喜欢敲命令，Windows下有两个方案可以让Git用起来非常顺手。

第一个方案是TortoiseGit，俗称“小乌龟”。它是一个Windows资源管理器右键菜单的图形化Git客户端，安装后你在文件夹里右键就能看到功能菜单：Commit、Pull、Push、Show log，都有图形界面，提交时可以直观地勾选哪些文件要提交，看历史记录时也能直观看分支树。小乌龟需要额外安装一个语言包才能变成中文界面，而且位数要和Git安装包一致，64位系统就装64位小乌龟，否则右键菜单不显示。对刚入门、还不太熟悉命令行的人来说，小乌龟是降低学习成本的不错选择。

第二个方案是在IDEA、VS Code这些IDE里直接使用Git。以IDEA为例，打开Settings -> Version Control -> Git，确认Path to Git executable指向了正确的git.exe路径，IDEA的右上角就能看到更新、提交、推送按钮，左下角有Git历史窗口。IDEA的Git集成做得很完善，提交记录、分支管理、冲突解决都有可视化界面。日常开发里，我个人的习惯是命令行和IDE混着用——提交、推送这样高频的操作用IDE点，rebase、worktree这样复杂动作用命令行，两者互相补位，效率很高。

6. 高频报错与排查心法

环境装好了，配置也搞好了，但真正开发的时候，一定会遇到各种报错。这里我把平时被问得最多的几个Git问题整理出来，每个都给出排查思路和解决手段。

6.1 fatal: not a git repository怎么破

这个报错应该是新手遇到最频繁的一条了，完整错误是fatal: not a git repository (or any of the parent directories): .git。

原因非常简单：Git在当前目录和所有父目录里都找不到.git文件夹。Git的所有版本记录都存在.git目录里，只有在一个已经git init过的目录或者git clone下来的仓库目录里，git命令才能正常工作。

排查路径如下：先执行pwd看一下当前在哪个目录，确认是否身处仓库目录内；再执行ls -a看看当前目录下有没有.git文件夹。如果确实还没有.git，就用git init初始化一份仓库，或者用git clone把远程仓库拉下来。如果这个目录之前能用Git，突然报这个错，重点检查是否有人把.git目录删掉了，尤其是清理垃圾文件时很容易误删；这种情况下即使文件还在，Git历史也没了，只能重新init或者从远程重新clone。

6.2 IDEA登录GitLab报login failed

使用IDEA连接GitLab时，有时会弹出一条英文报错，大意是“login failed. check api token or gitlab version. log in via git if the version...”这其实是IDEA的GitLab集成插件在尝试用API Token方式获取仓库和合并请求信息时，认证或版本不匹配导致的问题。

排查方向有几个：一是更新IDEA到较新版本，同时确认GitLab服务端版本不要太老，两者API版本不兼容是常见诱因；二是检查账号的Access Token是否有效，在GitLab设置里重新生成一个带read_api和read_repository权限的Token，然后在IDEA的Toolbox/插件设置里更新Token；三是绕开插件直连，改为最底层的Git命令方式——在IDEA里正常通过Git的HTTPS或SSH方式拉取推送代码，只要Git本身能连接GitLab，日常提交推送就没问题，报错的影响仅仅是IDE的图形化浏览功能受限而已。

这个报错本质上不影响git clone和git push，不必过度焦虑。把它当成一个IDE插件提示来看，优先保证Git通道没问题。

6.3 换行符与中文乱码的治理

Windows上最常跳出来的警告是warning: LF will be replaced by CRLF。这是Git在提示你换行符转换规则正在生效。前面安装时如果选了“Checkout Windows-style, commit Unix-style line endings”，Windows本地检出的文件就是CRLF，提交时会自动转LF，这个警告只是提示而已，不影响功能，不用专门去清理。

但如果想彻底让团队统一换行符、避免噪音，最稳妥的做法是在仓库根目录加一个.gitattributes文件，内容可以写：

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

这样每个文件类型的换行符行为都由文件统一定义，比单靠每个人电脑上的git配置更可靠。有.gitattributes之后，每个人clone下来执行的换行符转换规则都一样，不会再出现“我这边没改什么怎么diff一堆”的情况。

中文乱码分两种。一种是git status查看文件名时显示成“\344\270\255\346\226\207”，这是Git默认对非ASCII文件名做了转义，执行下面命令就能显示正常中文：

git config --global core.quotepath false

另一种是提交信息里的中文在终端显示乱码，这个跟终端编码有关。Git Bash里可以右键标题栏选Options -> Text，把Character set改成UTF-8；cmd窗口则可以用chcp 65001切到UTF-8编码。设置完重新打开终端，中文基本就正常了。如果你之前用默认Vim提交过中文信息，乱码往往发生在这个环节，建议尽早把默认编辑器改成支持UTF-8的编辑器，比如VS Code或Notepad++。

6.4 常见问题速查表

最后把一些高频问题整理成速查表，遇到可以直接查。这些基本都是我日常上手帮人排查时最常碰到的Git问题。

还有一个搜索热度很高的命令形如git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks，它看起来奇怪，其实是TortoiseGit这类GUI工具内部调用Git时自动追加的临时参数，用来关闭某些前缀显示、关闭路径转义、并跳过一些可选锁优化。如果你在任务管理器里看到类似命令行，或者帮助别人排查问题时看到它，不用慌，这是GUI工具的正常操作，不是Git内部出错。

我个人装Git踩过最大的坑，是早期装完就忘了配置user.name和user.email，结果提交记录里全是乱七八糟的默认值，后来想改历史特别麻烦。所以这篇教程里我把配置和安装放在同等重要的位置。装Git这件事本身不难，难的是装完之后把每个选项的意图理解清楚、把每一条命令的使用场景搞明白。建议你装完后别急着关电脑，先跑一遍clone、add、commit、push全流程，把这个“提交感”练出来，后面遇到问题才知道往哪个方向排查。等用顺手了，再慢慢研究rebase、worktree、submodule这些进阶功能，Git的威力会越用越明显。