空白白白白最近团队里好几个新人都在问同一个问题——Git怎么装，装完怎么建属于自己的本地仓库。这个工具本身不复杂，但因为它的概念和SVN那种老式版本控制不一样，很多人第一步就卡住了。今天我就从安装开始，一步步把Git的安装以及本地仓库的创建讲清楚，顺便把那些装完突然报错、命令不识别、目录找不对之类的坑全部踩一遍。这篇内容覆盖Windows、macOS和Linux三种平台的安装方式，适合刚入门的开发者，也适合以前只会复制粘贴命令、从来没搞明白原理的朋友。读完你会发现，Git其实没那么神秘，本地仓库更是整个版本管理的根基，先把这一步走稳，后面玩分支、推远程都会顺很多。
1. 项目整体思路与核心需求解析
1.1 Git到底是什么，它解决了什么问题
把Git理解成“文件快照管理器”可能比“版本控制工具”这个说法更直观。想象你写一篇论文，每隔一段时间就手动复制一份备份，命名为“论文最终版”“论文最终版2”“论文最终版3——再也不改版”，最后电脑里堆了几十个文件，真正要找某个历史版本的时候根本分不清。Git就是帮你自动管理这些“快照”的系统，每次提交都会记录当前所有文件的状态，你想回到哪一步就回到哪一步。
Git和早年流行的SVN有一个本质区别：Git是分布式的。也就是说，每个开发者电脑上都有一个完整的版本库，不依赖中心服务器。这就引出了“本地仓库”这个核心概念——在你运行git init的那个目录里，Git会自动创建一个隐藏的.git文件夹，这个文件夹就是你的本地仓库，里面存放着所有历史提交、分支指针、配置信息。没有网络、没有远程服务时，你照样可以提交代码、查看历史、回滚版本，全都在本地完成。
1.2 为什么本地仓库是第一步
很多人一上来就学git clone、git push，天天跟GitHub、GitLab打交道，但本地仓库的概念反而被忽略了。这其实有点本末倒置。你想啊，push是把本地仓库的内容推送到远程，pull是把远程的内容拉回本地，如果本地仓库的原理都不清楚，那这些操作对你来说就全是黑盒，出了问题不知道怎么排查。
本地仓库是所有Git操作的起点。你在本地做的每一次commit，都会写入.git目录里；你创建的每一个分支，本质上是本地仓库里的一个指针；你执行的每一次回滚，动的还是本地仓库的内容。远程仓库只不过是一个“备份”或“协作中转站”。所以我在带新人时，都坚持让他们先把本地仓库建起来，把add、commit、log这些命令玩熟练，再谈远程协作。
1.3 这篇博文适合谁
如果你是刚接触编程的学生、刚入职的初级开发，或者用了很久Git但一直靠“抄命令”混日子的老同事，这篇文章就是给你写的。我会把安装环节的每一个选项都解释清楚，会把git init之后发生了什么逐层拆开，也会把你第一次commit时可能遇到的每一个报错摆出来说。这篇文章不需要任何前置知识，只要你能打开终端敲命令，就能跟着走完整个流程。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备：在不同平台安装Git
2.1 Windows下安装Git的完整步骤
Windows是多数国内开发者的主力系统，而Git在Windows上的官方客户端就是“Git for Windows”，装好之后会自带一个叫“Git Bash”的终端环境，这个终端能模拟Linux命令，非常好用。
第一步是下载安装包。官网地址是https://git-scm.com/downloads，但国内直连官网有时候很慢，甚至打不开。遇到这种情况，我一般建议前往国内镜像站下载，比如淘宝的npm镜像站https://registry.npmmirror.com/binary.html?path=git-for-windows/，或者腾讯软件源，里面都有完整的安装包，下载速度非常快，版本也比较新。
下载完成后双击安装包，一路往下点，但有几个关键选项一定要认真看，因为它们直接影响你后面能不能在CMD或PowerShell里直接使用git命令。
第一个关键选项是“Adjusting your PATH environment”，这里提供三个选择：
- “Use Git from Git Bash only”表示只在Git Bash里能用git命令，在CMD和PowerShell里用不了；
- “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”会把一些Unix工具也加进PATH，有概率与系统自带的命令冲突，不建议选。
第二个关键选项是“Choosing the default editor used by Git”，默认是Vim。如果你不熟悉Vim，建议直接选VS Code或者你常用的编辑器，不然后面写commit信息时进到Vim界面会一脸懵。
第三个选项是“Line ending conversions”，也就是换行符处理。Windows系统用的是CRLF，Linux和macOS用的是LF，Git在这里做了一层转换，默认选项“Checkout Windows-style, commit Unix-style line endings”是最稳妥的，一般不用改。
其余选项基本保持默认就行。安装完成后，打开Git Bash，输入git --version，能看到版本号就说明装好了。
2.2 macOS和Linux下的安装方式
macOS用户最简单的方法是安装Xcode Command Line Tools，在终端里执行xcode-select --install，系统会自动安装包括Git在内的开发工具。如果你想要最新版本的Git，可以先用Homebrew安装brew install git，这样版本更新也方便。
Linux下安装Git也很快，Debian/Ubuntu系用sudo apt install git，CentOS/RHEL系用sudo yum install git或sudo dnf install git。有些服务器系统自带的Git版本太老，有些功能不支持，建议在合适的时候用编译源码的方式装一个较新的版本，但日常使用的话，包管理器自带的版本基本够用。
2.3 如何验证安装是否成功
装完之后，打开终端或Git Bash，执行这几条命令确认环境没问题：
bash复制git --version
which git
git --version能输出类似git version 2.39.2.windows.1的信息，which git能显示git可执行文件的具体路径。在Windows上，如果正确选择了PATH选项，CMD、PowerShell、Git Bash三个终端里都应该能正常执行git命令。如果只有Git Bash里能识别git、CMD里报错，说明PATH配置有问题，后面第5章的常见问题里我会专门讲怎么修复。
3. 用户信息配置与本地仓库的创建
3.1 全局配置：用户名和邮箱
安装好Git之后，第一件事不是建仓库，而是先告诉Git“你是谁”。这步配置非常重要，因为每次提交commit时，Git都会记录作者信息，如果没配置，你执行git commit的时候会直接被拒绝，并提示Please tell me who you are。
需要配置两项：用户名和邮箱。命令如下：
bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"
--global参数表示这些配置对当前用户的所有仓库生效，写在用户主目录下的.gitconfig文件里。你也可以去掉--global，只在某个仓库内覆盖这部分信息，这在公司电脑上同时维护个人项目和工作项目时非常有用。
配置完之后，可以用git config --global --list查看当前配置，确认用户名和邮箱都写对了。这个步骤千万别跳过，我见过太多新人第一次commit就卡在作者信息上，报错信息倒是很贴心地告诉你该怎么改，但如果你还不知道配置文件存在哪里，就会多花很多时间。
3.2 初始化第一个本地仓库
配置好用户信息，就可以创建本地仓库了。整个过程非常简单，先创建一个项目目录，进入目录，然后执行git init：
bash复制mkdir my-first-repo
cd my-first-repo
git init
执行完git init之后，Git会输出一行提示：Initialized empty Git repository in /path/to/my-first-repo/.git/。这时候你用ls -a查看目录内容，会发现多了一个隐藏的.git文件夹，这个文件夹就是整个仓库的核心，里面保存着Git的所有内部数据，包括对象数据库、引用、配置等。你可以进去翻一翻，但一般情况下不需要手动改动里面的东西。
从这一刻起，这个普通的文件夹就变成了一个合法的Git仓库，本地仓库已经创建成功。需要注意的一点是：git init之后，当前目录下的文件并不会自动被Git跟踪，你还需要通过git add把文件加入暂存区，再通过git commit生成第一个版本，Git才开始真正为你管理文件快照。
3.3 让Git Bash更好用的小配置
既然已经装了Git，我建议你顺手把Git Bash的体验优化一下，后面操作起来会舒服很多。
第一个建议是给常用命令设置别名。比如git status敲起来有点长，可以配置成：
bash复制git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
配置完之后，git st就等于git status，效率高很多的是实打实能感觉到的。
第二个建议是让Git Bash的提示符显示当前分支。默认提示符是一堆路径信息，看不出来你在哪个分支上。可以通过编辑~/.bashrc文件，加上一段简单的PS1配置，把当前分支打印出来。这样你在仓库里操作时，一眼就能确认自己没走错分支，对后面学习分支操作非常有帮助。
4. 核心概念与常用命令实操
4.1 工作区、暂存区、版本库
理解了三个核心区域，Git的基础就算是打通了一半。这三个区域是：工作区、暂存区、版本库。
工作区就是你当前正在编辑的目录，那些平时看到的、能打开的文件都算工作区的内容。暂存区可以理解成一个“待提交清单”，你执行git add之后，文件状态会被标记为“已暂存”，但它还没有真正被记录到版本历史里。版本库则是.git目录内部的对象存储，你执行git commit之后，暂存区里的内容被永久写入版本库，形成一个不可变的快照。
打个比方：你做一道菜，工作区是案板上切好的食材，暂存区是装好盘准备下锅的半成品，版本库则是已经做好的成品，拍照存档，以后随时可以回看。很多初学者搞不清add和commit为什么要分成两步，我这样解释应该很好理解：add是挑选本次要提交的内容，commit是正式生成一个版本快照。
4.2 第一次提交：add和commit实操
现在我们在刚才创建的仓库里新建一个README文件，并进行第一次提交：
bash复制echo "# My First Git Repo" > README.md
git status
git status会告诉你当前仓库的状态。此时README.md是未跟踪状态，文件显示在Untracked files列表下面，意味着Git还不知道这个文件的存在。接下来把它加入暂存区：
bash复制git add README.md
git status
再次执行git status，README.md变成了绿色显示，状态变成了Changes to be committed，表示文件已经被加入了暂存区，等待提交。接下来正式生成第一个版本：
bash复制git commit -m "docs: init project"
-m参数直接指定提交说明。如果省略-m，Git会打开默认编辑器让你输入提交信息，这就是很多新人会卡住的地方——打开Vim之后不知道怎么保存退出。解决办法是输入i进入编辑模式，写完内容后按Esc退出编辑，再输入:wq保存并退出。如果不小心进入了Vim不想编辑，直接输入:q!不保存退出即可。
提交成功后，用git log查看历史记录，就能看到你刚才那次提交的信息。第一次提交完成后，这个仓库就算真正“活了”，后面每一行代码的变更都会被Git完整记录下来。
4.3 文件状态与git status的变化
Git里的文件状态转换是整个操作流程的主线。每次修改文件后，它的生命周期大致是这样的：未跟踪 -> 已暂存 -> 已提交，然后修改后又会变成已修改。我用一张表格把这几种状态和对应操作整理出来：
| 状态 | 含义 | 对应操作 |
|---|---|---|
| Untracked | 文件未被Git跟踪 | git add 将其纳入暂存区 |
| Modified | 已跟踪文件被修改，但未暂存 | git add 将其纳入暂存区 |
| Staged | 文件已加入暂存区 | git commit 将其提交到版本库 |
| Committed | 文件已提交，版本库有快照 | 再次修改后状态变为Modified |
实际操作中，每做完一步操作，就执行一次git status，你就能看到文件状态在表格中来回切换。我个人的习惯是：修改代码前看一次状态，确认自己出发点干不干净；改完代码后看一次状态，确认哪些文件被改动过；提交前再看一次，确认只包含了本次想要提交的内容。所谓“提交前看一眼状态”这个习惯，能帮你挡掉大部分误提交的灾难。
4.4 改错了文件怎么撤销
Git最强大的功能之一就是可以随时反悔。根据文件所处的状态，撤销方式也不一样，我梳理三种最常见的场景。
第一种场景：文件已经修改，但还没执行git add。这时候用git restore <file>可以把它恢复到最近一次提交的状态。这个命令在Git 2.23版本以后才出现，如果你们用老版本，可以用等价的git checkout -- <file>。
第二种场景：文件已经执行git add，但还没commit。用git restore --staged <file>把文件从暂存区撤回，但文件内容仍然是修改后的。如果你还想放弃修改，再执行一次git restore <file>即可。
第三种场景：已经提交了，但是提交信息写错了，或者发现漏掉了一个文件。如果这次提交还没有推送到远程仓库，可以用git commit --amend来修改提交信息，它会用一个新的提交覆盖上一个提交。这个命令非常有用，但要注意，如果提交已经推送到了远程且被其他人拉取过，那就不要用amend了，否则会破坏团队的历史记录。
5. 常见问题与排查技巧实录
5.1 “git不是内部或外部命令”
这个问题在Windows上非常常见，几乎每周都能看到有人问。报错信息一般是：“git”不是内部或外部命令，也不是可运行的程序或批处理文件。说白了，就是系统在PATH环境变量里找不到git.exe的路径。
解决办法有两种。第一种是重新运行Git安装包，选择Modify模式，在PATH那一步改成“Git from the command line and also from 3rd-party software”。第二种是手动配置环境变量：右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量，在系统变量里找到Path，把C:\Program Files\Git\cmd这个目录添加到列表中。注意，具体路径取决于你安装Git时选择的路径，如果装到了其他盘符或目录，就填对应的路径。
配置完环境变量，需要重新打开终端才能生效。CMD、PowerShell都是如此，因为终端启动时会读取一次PATH，不重开是识别不到新配置的。
5.2 PowerShell下“无法将git项识别为cmdlet”
这个报错是git无法被识别，错误信息形如“无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。它和“不是内部或外部命令”的根源是一样的，都属于PATH没配置好，但两种报错出现的终端不同。
处理方式依然是检查PATH里有没有git的cmd路径。排查的时候可以在终端里直接执行where.exe git，如果输出了路径说明能找到，如果报错说明PATH配置有问题。还有一个很隐蔽的原因：你安装Git时没选PATH选项，但在PowerShell里直接敲git，PowerShell会抛出上面这个错误，而Git Bash里却一切正常，给新人造成一种“电脑出问题了”的错觉。其实完全正常，只是终端环境不同，PATH配置不同。
5.3 “fatal: not a git repository (or any of the parent directories): .git”
这个报错的意思是：当前目录不是Git仓库，或者它的父目录里也没有任何Git仓库。犯这个错的操作，大多是在一个普通文件夹里直接执行了git status或git log，还没有执行过git init，或者目录本身就走错了。
解决办法就两条：要么在正确的仓库目录里执行操作，要么在需要的目录里先执行git init。还有一个小细节：git init在当前目录生效后，子目录里执行git命令是能找到父仓库的，因为Git会从当前目录向上逐级查找.git文件夹，所以只要你在仓库的子文件夹里，普通命令也能正常工作。但如果你把.git文件夹删掉了，就算文件还在，也不再是Git仓库，历史记录全部丢失，这点务必注意。
5.4 提交信息写错了怎么办
经常有人commit -m之后马上发现提交信息有错字，或者想补充一下内容。如果还没有推送远程，解决办法非常干净：
bash复制git commit --amend -m "新的提交信息"
--amend会修改最近一次提交的信息，并且不会产生新的提交记录，相当于把上次提交原地更新了。如果只是想补充漏加的文件，可以先git add你漏掉的那个文件，然后再执行git commit --amend --no-edit，--no-edit表示保留原有提交信息不修改，这样提交内容就被补全了。
需要注意，--amend只适合修改尚未推送的本地提交。一旦推送到了远程且其他同事已经拉取，再amend就会让本地和远程的历史出现分叉，后面合并时就会非常痛苦。
5.5 换行符和中文文件名问题
Windows上首次提交时，可能会看到类似“warning: LF will be replaced by CRLF”的提示。这个不是错误，是Git在帮你做换行符转换，因为Windows和Linux的换行符标准不同。大多数情况下默认配置就能正常工作，不用特意处理。
中文文件名在git status里显示为转义字符是一个常见小困扰。默认情况下Git会把非ASCII字符转义成八进制编码，比如中文“测试”会显示成"\346\265\213\350\257\225"，很影响阅读。解决办法是设置：
bash复制git config --global core.quotepath false
设置之后，中文文件名就能正常显示了。这个配置对日常中文开发者来说非常实用，建议直接设上。
6. 实操心得与后续扩展建议
6.1 我个人用下来的一些体会
带过这么多新人之后，我最大的体会是：本地仓库这块基础打不牢，后面怎么学都会累。建议刚开始接触Git的人，先不要急着clone别人的项目，也别急着学pull、push、merge那一大堆远程操作。就在自己的电脑上建一个文件夹，每天往里放点代码，执行几次add和commit，用git log看看历史，用git restore撤销几次改坏的文件。这个循环你不厌其烦地多走几遍，Git的核心模型就刻在脑子里了。
还有一个小习惯特别值得养成：每次提交的粒度要小、意图要清晰。不要攒了一个星期的改动一把梭提交，也不要一条提交里混着“修复bug、改样式、加功能”三件事。提交信息尽量用简明的动词开头，比如“fix: 修复登录超时问题”“feat: 新增用户列表导出”，这样以后回溯历史时一目了然。这条习惯成本极低，但收益会随着项目规模增长越来越大。
6.2 本地仓库打通后，下一步可以学什么
本地仓库玩明白之后，方向就很多了。最自然的一步是搭建远程仓库，注册一个GitHub或GitLab账号，把本地仓库推送到远程，这样既有了异地备份，也打开了多人协作的大门。推送之前需要配置SSH密钥，简单说就是本地生成一对公钥和私钥，公钥放到远程仓库平台，就能实现免密操作。
再往后是分支管理。学会了分支，你才能真正体会到Git带来的效率提升：开个分支开发新功能，不影响主分支的稳定性，功能完成后合并回去。还有git merge和git rebase的区别、冲突如何解决，这些都是Git进阶路上的必修课。
我现在回头看，其实Git并不难，难的是那些看似抽象的概念没有被解释清楚。希望这篇关于Git安装以及本地仓库创建的记录，能让你少走几步弯路。整个过程中如果还有没跑通的地方，回到第5章对着问题排查就好，我在里面列的都是实际工作中最常踩的坑，一条一条对照着来，基本都能解决。