你有没有经历过这种时刻：一个文件夹里躺着“项目_最终版.doc”“项目_最终版2.doc”“项目_打死也不改了.doc”，而写代码时的版本混乱程度比这夸张十倍。我见过不少刚入行的朋友，手里的项目文件夹几百兆，里面全是各式各样的“副本”“备份”“改改”。Git就是来终结这种痛苦的版本管理工具，它能把每次修改都记录下来、随时回退，还能让多人一起协作而不互相覆盖。2026年了，Git早就不再是“要不要学”的问题，而是“只要动代码就必须装”的基础设施。这篇文章我按照2026年初的实际环境，把Git的安装流程和基础使用步骤完整梳理一遍，全程保姆级，从下载安装到日常推送全覆盖，适合第一次接触Git的读者，也适合那些装过但一直在“下一步下一步”里蒙圈的人。文中的命令我都尽量写成你能直接照着敲的状态，遇到报错我们也会一起看怎么解决。
1. 安装前先在脑子里搭个框架：Git到底管什么事
很多教程上来就是“下载—点击—下一步—完成”，装完照样一脸懵。我建议先花两分钟搞懂Git的基本工作方式，这样后面每条命令你都能知道自己在干什么，而不是单纯照着敲。
1.1 用一个档案室的比喻理解Git的三块地盘
Git有一个特点：它并不是任何时候都立刻保存你的每个改动，而是给你搭好了三个不同的“房间”。
第一个是工作区，就是你电脑上肉眼可见的文件夹，你平时的新增、修改、删除都发生在这里，Git默认不干预；第二个是暂存区，相当于办公室桌面，你把想要记录的文件先放到桌上，告诉Git“这几个我有用”；第三个是版本库，相当于档案柜，只有放进了档案柜的改动，Git才会正式记录成一次“版本”。
对应到命令上就是：在工作区改文件，用git add把文件放到暂存区，再用git commit把暂存区的内容一次性归档为版本。这条“改—暂存—提交”的链路，是后面所有进阶操作的基石。想明白这一点，就不会出现“我明明改了，怎么git log里看不到”这种经典疑问了，因为答案往往就是：改完忘了add，或者add完忘了commit。
1.2 安装前需要做的三个小准备
安装Git本身不难，但在动手之前，我建议你先花一两分钟确认三件事，能省掉后面不少麻烦。
第一，确认你的系统位数。Windows下右键“此电脑”—“属性”就能看到。现在绝大多数机器是64位，如果还是32位系统，新版Git安装包可能会提示不支持，这也是很多老电脑装不上的原因之一。
第二，看看电脑上是不是已经装过Git。打开命令行窗口（Windows按Win+R输入cmd回车，macOS打开“终端”），输入git --version。如果弹出版本号，说明已经装过了，可以跳过安装环节直接看后面的配置部分；如果提示“git 不是内部或外部命令”，或者“-bash: git: command not found”，说明确实还没装好。
第三，想清楚自己以后主要在什么场景用。本文以命令行教学为主，因为你在网上看到的绝大多数资料、面试题和日常操作，最终都要回到命令行里执行。命令行是Git的标准用法，先跑通它，再考虑图形化工具。
1.3 为什么我不建议新手先折腾图形化工具
市面上有不少图形化Git工具，装完能减少敲命令的麻烦。但我的建议很明确：第一次学习阶段，尽量把命令行跑通。
原因有两个。第一，图形工具本质上就是在帮你执行那些命令，如果底层概念没理解，工具一旦报错，你依然不知道问题出在哪一步。比如让你把某个文件恢复到上一个版本，图形界面可能只是点几下，但背后执行的是git checkout或git restore，不懂原理的人出了问题很难自纠。
第二，命令行里那十来条核心命令是跨平台通用的，Windows、macOS、Linux上写法完全一样，属于“学会一次，到处能用”的技能。等命令行熟了，再根据喜好选图形工具，那时候你已经能看懂工具界面上的每个字段在说什么，学起来反而更快。
2. Windows、macOS、Linux：三种环境下的安装实战
安装Git没有高深技巧，真正的坑往往藏在“安装时你以为懂了，结果回车敲错”的细节里。我把三个平台分开写，你只需要找到自己系统对应的那一节。
2.1 Windows：官方安装包，注意四个关键点
Windows是绝大多数新手的起点，安装过程也确实无脑，但有几个界面选项值得说清楚。
第一步，打开Git官网，进到Downloads页面，选择Windows版本，下载64位的exe安装包。官网下载速度通常还行，如果特别慢，也可以找国内软件源或镜像站，但一定要核对安装包的签名和来源，避免第三方站篡改。
第二步，双击安装包，一路Next。整个过程保持默认选项即可，唯一建议重点关注的是“Adjusting your PATH environment”这一步。这里有三个单选选项，默认选中的是“Git from the command line and also from 3rd-party software”，这个千万别改成“only from Git Bash”。后者会让Git只存在于Git Bash环境里，你在CMD和PowerShell里敲git会提示找不到命令，这是很多新手装完“明明装了却说没装”的重要原因。
第三步，选择默认编辑器。如果你完全没概念，保持默认的Vim就行；如果电脑上已经装了某个编辑器，比如VS Code，也可以在下拉框里选它。这样以后提交代码需要写提交信息时，不会卡在Vim的黑色界面里不知道怎么退出。真卡住了也别慌，输入:wq回车就能退出保存。
第四步，全部安装完成后，重新打开一个CMD或PowerShell窗口（注意是新的窗口，旧窗口不会自动加载新加入PATH的git命令），输入git --version，看到git version x.x.x.windows.x这样的版本输出，就算成了。
注意：安装完一定要重新开终端窗口验证，这是新手最容易忽略的一步。
Windows还自带一个Git Bash，它是模拟Linux命令行的环境，很多老教程喜欢让你用它。我的看法是：如果以后只面对Windows环境，用系统自带的PowerShell就够了；如果计划碰服务器或云主机，那就尽早习惯类Unix命令，用Git Bash会更贴近服务器操作习惯。
2.2 macOS：两种方式，我推荐用Homebrew
macOS上的安装有两条主流路线，选一条就行。
方式一是推荐路线：如果你已经装了Homebrew，直接在终端执行brew install git，等它跑完就结束了。Homebrew安装的Git放在用户目录下，不需要sudo，也不会动系统文件，以后想升级就再执行一次brew upgrade git，非常干净。
方式二是去Git官网下载macOS安装包，双击安装。这条路适合还没配置Homebrew的用户。虽然也简单，但后续升级要靠手动下载新版安装包，稍微麻烦一点。
安装完同样执行git --version验证。如果macOS弹出“无法打开，因为无法验证开发者”之类的提示，需要到“系统设置 — 隐私与安全性”里允许从App Store和被认可的开发者。这是苹果的安全机制，不是Git本身的问题，放心放行即可。
2.3 Linux：直接用包管理器，别碰源码编译
Linux这边的安装最简单，不同发行版对应不同命令：
- Debian/Ubuntu系：
sudo apt update && sudo apt install git - CentOS/RHEL系：
sudo yum install git，新版系统用sudo dnf install git - Arch系：
sudo pacman -S git
装完执行git --version验证。
这里特别劝一句：新手不要尝试源码编译安装Git。编译Git需要安装一堆依赖、下载源码、再执行make，一条命令能解决的事没必要折腾半小时。源码编译只在需要特定版本或定制参数的极少数场景下才有意义，日常使用直接用包管理器的稳定版就够了。
| 系统 | 推荐安装方式 | 一句话说明 | 验证命令 |
|---|---|---|---|
| Windows | 官网下载exe安装包 | 保持默认，PATH选项别选错 | git --version |
| macOS | brew install git | 推荐Homebrew，升级方便 | git --version |
| Linux | apt/yum/dnf/pacman | 一条命令装完 | git --version |
3. 装完别急着用，先把这三件事配好
我见过太多人装完Git，匆匆忙忙就开始建仓库，结果第一次push就被拒，回头再补配置，绕了不少弯路。实际上，安装之后只需要花五分钟做三件小事，后面的体验会顺很多。
3.1 第一件事：让Git知道“你是谁”
Git每次提交都会记录作者信息，目的不是监控，而是让协作的人知道某行代码是谁改的、出了问题可以找谁。所以第一步是配置用户名和邮箱：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里的邮箱一般建议用你注册代码托管平台的那个邮箱，这样平台能把提交记录和你的账号对应起来，提交时头像和昵称都能正确显示。
配置完可以用git config --list查看所有生效的配置，确认没有拼写错误。
提示：
--global表示全局生效，也就是这台机器上所有仓库都用这个身份。如果某个项目需要另一个身份，比如公司项目和私人项目分开，可以在那个仓库目录里去掉了--global单独配置，该配置会覆盖全局，两边的提交身份互不干扰。
3.2 第二件事：生成SSH密钥，把免密登录打开
为什么要做这一步？如果只用HTTPS方式连远程仓库，每次push和pull都要输入账号信息，而且现在很多平台已经收紧了口令登录，普遍要求使用个人访问令牌而不是密码。SSH密钥则是一次配置、永久免密，也是我从第一天就推荐给新手的方案。
步骤很简单：
- 终端执行
ssh-keygen -t ed25519 -C "你的邮箱"，一路回车即可，不用额外设置口令。 - 生成的文件默认在用户目录下的
.ssh文件夹里，id_ed25519是私钥，id_ed25519.pub是公钥。私钥自己保管好，不要发给任何人，公钥可以公开。 - 查看公钥内容：macOS/Linux执行
cat ~/.ssh/id_ed25519.pub，Windows可以用记事本打开这个文件。 - 登录你的代码托管平台，在个人设置里找到“SSH Keys”或“公钥管理”入口，把公钥内容整段复制进去保存。
验证是否配通：执行ssh -T 平台提供的SSH验证地址。不同平台输出的欢迎语略有不同，但只要看到类似“successfully authenticated”的信息，就说明密钥生效了。这一步即便暂时连不上平台也能做，因为密钥是本地生成的。
3.3 第三件事：确认默认分支名，并统一本地与远程
这些年，新仓库的默认分支名从原来的master逐步迁移到了main，国内主流平台新仓库默认分支基本是main或master，不同平台有细微区别。这里不讨论命名优劣，只给结论：跟着平台默认走最省事。
你在本地git init时，新版Git会用自己的默认分支名。如果平台新建仓库默认是main，本地也最好统一成main，否则push时会多一层“分支名不匹配”的困惑。
统一方法很简单：在仓库里执行一次git branch -M main，这条命令会把当前分支重命名为main。后面push时，这一步做对了，远程和本地的分支名就始终一致。
4. 第一个仓库：完整走一遍“改—存—提交—记录”
配置完成，现在可以真正进入Git的世界了。这一章的套路你以后每天都会重复，强烈建议亲手敲一遍，而不是只看不练。
4.1 初始化仓库：git init
先新建一个练习文件夹，进入这个目录，然后执行：
git init执行成功后，文件夹里会生成一个隐藏的.git目录，它不神秘，就是Git存放所有版本记录的地方。注意：如果哪天你误删了.git，Git的历史记录就全没了，所以这个文件夹平时不用碰，也不要挪走。
此时用git status查看仓库状态，会显示当前在哪个分支、以及“nothing to commit”之类的提示，意思是仓库是干净的，可以开始干活了。
4.2 第一次提交：add与commit的完整链路
在文件夹里新建一个readme.md文件，随便写几行字。然后执行：
git add readme.md git commit -m "docs: 初始化项目说明文档"如果前面没做过git branch -M main，建议在commit之前补上。
第二次提交开始，你会发现链路永远是这套：修改文件后git add把改动放入暂存区，再git commit把它归档为版本。git add后面可以跟多个文件名，也可以用git add .把当前目录所有改动一次性加入暂存区。但git add .要谨慎用，尤其是仓库里已经有不想被管理的大文件或临时文件时，很容易误加。
提交信息是门小学问。常见格式是“类型: 描述”，类型有feat（新功能）、fix（修bug）、docs（文档）、refactor（重构）等。不是强制规范，但坚持这个习惯，三个月后翻log你能快速定位每次提交的目的，这个习惯越早建立越好。
4.3 查看状态与历史：status、log、diff
三个命令我会并列讲，因为它们分工明确：
git status：任何时候想知道“我改了什么、什么东西还没提交”，用它。这是使用频率最高的命令，没有之一。git log：列出提交历史，每条包含commit编号、作者、日期、提交信息。如果提交太多，加--oneline参数压缩成一行一行的列表，非常清爽。git diff：查看工作区里还没暂存的具体改动内容，逐行对比，是“我想看看这次到底改了什么”的标准答案。
这三个命令是日常查看类命令里用得最多的。建议没事就敲一敲，养成“提交前先diff、提交前先status”的习惯，能避免很多尴尬操作。很多新手觉得“我没必要看差异直接提交就行”，结果一到团队协作就频繁踩坑。
4.4 从一开始就建好.gitignore
.gitignore文件是Git的忽略规则配置文件。把不需要纳入版本管理的路径写进去，Git会自动跳过这些文件，不会在git status里反复提示。
常见需要忽略的内容：
- 依赖目录：
node_modules/、vendor/ - 编译产物：
dist/、build/、*.class - 本地配置：
.env、.local - 系统文件：
.DS_Store、Thumbs.db
规则写法很简单，一行一条，支持*通配符和目录斜杠结尾。
提醒：
.gitignore只对还没纳入跟踪的文件生效。如果某个文件之前已经git add过，后面再写进.gitignore也不会自动消失，需要先执行git rm --cached 文件名把它从跟踪里移除，再让忽略规则生效。这个细节在我带的新人里十有八九都会遇到。
5. 打通远程：push、pull，以及让人紧张的冲突
本地版本的Git其实已经能完成版本回溯和记录，但Git真正厉害的是团队协作。这一步把本地仓库和一个远程备份/协作仓库关联起来，从此你的代码有异地备份，别人也能一起开发，这是Git和普通压缩包备份的本质区别。
5.1 在托管平台建一个空仓库，然后把本地仓库和它绑定
具体流程分四步：
- 登录你的代码托管平台，点击新建仓库，仓库名起一个容易理解的，比如
my-first-repo。 - 在“初始化仓库”相关选项里，一定选不添加readme、不添加.gitignore、不添加许可证。如果远程仓库已经带了一个初始提交，而本地也有自己的第一笔提交，两边就是完全独立的历史，新手处理起来很容易懵。
- 平台会生成一个仓库地址，SSH格式通常长这样：
git@平台域名:用户名/my-first-repo.git。复制SSH地址，别复制HTTPS地址。 - 回到本地终端，执行：
git remote add origin git@平台域名:用户名/my-first-repo.gitgit remote add origin的意思是“给远程仓库起个名字叫origin”，origin只是约定俗成的名字，可以改，但没必要。
然后执行首次推送：
git push -u origin mainpush：把本地提交推送到远程；-u：设置上游引用，以后直接敲git push就能少打参数；origin main：指定推到哪个远程、哪个分支。
执行成功后，打开平台网页刷新，你会看到代码已经上去了。
5.2 从远程拉下来：clone与pull
换一台电脑或者同事来接手项目，不需要重敲所有命令，直接git clone 远程地址 文件夹名，一键复制整个仓库到本地，包括全部历史记录。这个命令会自动完成“初始化仓库+关联远程+拉取代码”三件事，手速比手动操作快得多。
如果项目已经在本地，只是想把远程新增的提交拿到本地，用git pull。注意git pull会直接合并改动，所以更稳妥的做法是先git fetch把远程变化取下来，再git diff看差异，最后git merge。新手阶段可以先直接pull，但心里要清楚它本质是fetch+merge的组合命令。
5.3 冲突并没有那么可怕：看懂冲突标记就够了
多人同时改同一个文件的同一处，就会触发冲突。Git的处理策略不是锁死文件，而是把两边的改动都保留下来，让你人工选择。
冲突发生后，打开冲突文件，会看到这样的标记：
<<<<<<< HEAD 这里是你的改动 ======= 这里是别人的改动 >>>>>>> 别人的提交编号你只需要把<<<<<<<、=======、>>>>>>>这些标记行删掉，把最终想保留的内容整理好，然后重新git add和git commit即可。冲突本身不可怕，真正可怕的是冲突文件遍地都是标记却不知道从何整理。所以团队协作中最好遵循“高频文件少人同时改、大改动提前沟通”的软约束，能从源头上减少大部分冲突。
5.4 后悔药：误提交、误删除之后怎么恢复
知道git reflog之前，我也以为提交记录不可逆，其实Git给了很多后悔的机会。
- 想改最近一次提交的信息：
git commit --amend -m "新的信息"，只改信息不动内容。 - 想把已提交的内容撤销、退回到暂存区可编辑状态：
git reset --soft HEAD~1，HEAD~1表示前一个版本。 - 更激进地连工作区一起回滚：
git reset --hard HEAD~1，这条命令会丢弃工作区所有未提交改动，慎用。 - 如果找不到那个“想撤回的提交”的编号了：
git reflog会记录你所有操作的版本变化，相当于Git的“操作日记”，用它能看到每个历史版本的编号，再配合reset就能找回“以为删掉”的内容。
这里必须强调：reset --hard会直接丢失工作区内容，执行前先确认你的改动确实不需要了，或者先用git stash把当前改动临时存放起来做个缓冲。
6. 新手高频报错速查表：照着排查，别慌
最后这部分，我把这些年里新手遇到最多的报错整理成一张速查表。报错原文不一定完全一样，但关键词和排查思路是通用的。
6.1 常见报错一图速查
| 报错关键词 | 真实含义 | 第一反应 |
|---|---|---|
| not a git repository | 当前目录不是仓库 | git init 或确认是否在仓库目录内 |
| failed to push some refs | 远程有本地没有的提交 | 先git pull再push |
| Permission denied (publickey) | SSH密钥没配好 | 检查本地密钥和平台公钥 |
| make sure you have the correct access rights | SSH地址不对或没权限 | 用git remote -v核对仓库地址 |
| refusing to merge unrelated histories | 两个仓库没有共同历史 | 确认需求后使用--allow-unrelated-histories |
6.2 逐条排查思路
第一条，fatal: not a git repository。原因多半是执行git命令时，当前文件夹从来没执行过git init，或者不小心进入了.git目录内部。排查方法很简单，先执行git status看响应，确认是否站在仓库根目录。
第二条，! [rejected] ... (fetch first)以及failed to push some refs。原因是远程仓库已经有提交，而本地是另一个无共同祖先的历史。最常见场景就是平台新建仓库时勾选了添加readme，本地又有一份自己的readme。解决办法是先执行git pull origin main --allow-unrelated-histories，处理可能的冲突，再重新push。
第三条，Permission denied (publickey)。意思是SSH密钥没有在平台账号里配置，或者本地不存在预期位置的密钥。排查步骤：先看本地有没有~/.ssh/id_ed25519.pub，没有就重新生成；有就把它复制到平台的SSH Keys设置里；再执行ssh -T平台验证地址测试。
第四条，Please make sure you have the correct access rights。多半是仓库地址写错了，常见于大小写错误或漏掉末尾的.git。执行git remote -v查看当前关联的地址，和平台复制出来的地址逐字核对。
第五条，refusing to merge unrelated histories。本地仓库和远程仓库分别有各自独立的第一笔提交，Git默认不合并“两个毫无血缘的家族”。如果你确认两边历史确实要合并，用git pull --allow-unrelated-histories origin main。这个参数只在确认没有更好的方式时再用，强制合并后历史会混杂，后期梳理成本不低。
6.3 给新手的最后一个建议：先记住五条命令
如果今天只能记住五条命令，我的答案是：git status、git diff、git add、git commit、git log。这五条覆盖了日常80%的查询与提交动作。先不追求背全命令，把“改完看状态、提交前看差异、提交后看历史”的习惯养成，再逐步展开分支、合并、变基这些进阶操作。
我带过的不少新人最容易犯的错是“上来就git push，push不过去才看报错”。反过来，先在本地把status和diff看明白，绝大多数问题在本地就能及时发现，根本轮不到跟远程仓库纠缠。安装Git只是几十秒的事，真正值钱的，是你把它用成“版本记录”的习惯，这比任何花哨命令都重要。
