说个可能暴露年龄的事——我第一次用Git，把本地仓库搞炸了。

不是比喻，是真的炸了。那时候大二，刚学完C语言，听说程序员都用GitHub，于是兴冲冲地注册了账号，照着一篇教程敲了 git init、git add .、git commit，一切顺利。然后我想把代码推到GitHub上，教程说用 git push，我一敲，报错。

我不知道该怎么办，搜了一个命令 git push -f。

force push。

直接把远程仓库覆盖了。

那个仓库是我fork别人的，还好没什么后果。但我盯着终端看了好一会儿，隐约觉得自己刚才做了一件很危险的事，却说不清危险在哪。

后来我花了大概一个学期，才真正搞懂Git和GitHub是怎么回事。走了很多弯路。现在回头看，如果当时有人跟我说清楚几件事，我至少能少浪费两个月。

第一件事：Git和GitHub不是一个东西

这是最常见的混淆，也是最影响理解的。

Git 是一个版本控制工具。它装在你的电脑上，跟网络没有任何关系。你断网也能用Git。它的作用是帮你记录代码的每一次变更——谁改了什么、什么时候改的、改之前是什么样。像是给你的代码装了一个无限次的撤销键。

GitHub 是一个网站，一个平台。它的作用是把你本地的Git仓库放到云端，这样别人也能看到、也能参与。同时它在Git的基础上加了很多社交和协作功能——Issue、Pull Request、Actions、Pages等等。

类比一下：Git是相机，GitHub是相册平台。你用相机拍照（用Git管理代码），然后把照片传到平台上让别人看（push到GitHub）。你可以用相机但不用平台（本地Git不push），你也可以在平台上看别人的照片但自己不拍（浏览GitHub不写代码）。

先理解Git，再学GitHub。 这个顺序不能反。很多人上来就在GitHub网页上点来点去，但不理解底层的Git在做什么，后面遇到冲突、分支、合并这些概念的时候就全懵了。

第二件事：你只需要先学会六个命令

Git的命令有几十个，但日常开发用到的就那么几个。我建议你先把这六个彻底搞懂，其他的用到再查：

git init # 在当前目录创建一个新的Git仓库 git add # 把文件的变更加入"暂存区" git commit # 把暂存区的内容保存为一个版本 git push # 把本地的版本推送到远程（GitHub） git pull # 把远程的最新版本拉到本地 git clone # 把GitHub上的仓库复制到本地

这六个命令覆盖了一个人独立开发时90%的场景。剩下的——分支、合并、rebase、stash——等你用到了再学，不急。

但光知道命令不够。你得理解一个核心概念：三个区域。

工作区 → 暂存区 → 本地仓库 → 远程仓库 add commit push

你改了一个文件，这个改动在”工作区”。git add 把它放到”暂存区”，表示”这个改动我确认了，准备提交”。git commit 把暂存区的所有改动打包成一个”版本”，存到本地仓库。git push 把本地仓库的版本推到GitHub。

为什么要分这么多步？为什么不能改完直接一键上传？

因为你可能同时改了五个文件，但只有三个改动是相关的，你想把它们作为一个版本提交，另外两个改动放到下一个版本。暂存区就是让你做这个筛选的。

理解了这个流程，Git八成的困惑都消失了。

第三件事：动手建你的第一个仓库

别看教程看太久。看完上面那些，就可以动手了。

一步一步来：

1. 注册GitHub账号。 这个不用教。

2. 安装Git。 Windows去 git-scm.com 下载安装包。Mac自带，终端敲 git --version 看看有没有。Linux用包管理器装就行，sudo apt install git 之类的。

3. 做最基本的配置。

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

这个名字和邮箱会出现在你的每一次commit记录里，让别人知道这段代码是谁写的。

4. 在GitHub上创建一个新仓库。 点右上角的 “+“，选 “New repository”。名字随便起，比如 my-first-repo。勾上 “Add a README file”。点创建。

5. 把它克隆到本地。

git clone https://github.com/你的用户名/my-first-repo.git cd my-first-repo

现在你本地就有了这个仓库的完整副本。

6. 改点东西，提交，推送。

# 随便创建一个文件 echo "Hello GitHub" > hello.txt # 查看状态——会告诉你有一个新文件 git status # 加入暂存区 git add hello.txt # 提交 git commit -m "添加了hello.txt" # 推送到GitHub git push

然后去GitHub上刷新你的仓库页面。看到 hello.txt 了吗？

恭喜，你完成了Git工作流的完整闭环。 后面所有的操作——不管多复杂——都是这个基本流程的变体。

第四件事：分支，迟早要学，不如现在

如果你只是一个人写代码自己玩，上面六个命令够了。但一旦涉及协作（或者你自己想同时尝试两种方案），就需要理解分支。

分支是什么？

你正在写一个项目，一切正常。突然你有一个新想法，想加一个功能，但不确定能不能成。你不想在现有的代码上直接改——万一改炸了呢？

分支就是让你复制一条平行的时间线，在上面随便折腾，折腾好了合并回来，折腾坏了直接扔掉，不影响原来的代码。

# 创建一个新分支并切换过去 git checkout -b new-feature # 在这个分支上随便改 echo "new stuff" > feature.txt git add feature.txt git commit -m "尝试新功能" # 切回主分支——你会发现feature.txt不见了 # 因为它只存在于new-feature分支 git checkout main # 如果新功能OK，合并到主分支 git merge new-feature

GitHub上几乎所有的协作都是通过分支进行的。你想给一个开源项目贡献代码，流程是：fork仓库 → 创建分支 → 在分支上改代码 → 提Pull Request → 项目维护者review → 合并。

这个流程叫GitHub Flow，是所有GitHub协作的基础。

第五件事：用GitHub Pages搭一个免费网站

学工具最好的方式是用它做一个有实际产出的东西。

GitHub Pages可以让你免费把一个仓库变成一个网站。不需要服务器，不需要域名（虽然可以绑定自定义域名），不需要花一分钱。

最简单的做法：

1. 创建一个新仓库，名字叫 你的用户名.github.io

2. 在里面放一个 index.html 文件

3. 过几分钟访问 https://你的用户名.github.io

你就有了一个自己的网站。

可以放你的个人介绍，可以放你的项目展示，可以放你的学习笔记。内容随意，关键是你完成了一件事——你用Git和GitHub做出了一个真实的、别人能访问的东西。

这比任何教程都有效。因为你突然有了动力去学更多——怎么让页面更好看？怎么加一个博客？怎么自动部署？每一个问题都会引你去学新的东西。

第六件事：学会看别人的仓库

GitHub上最有价值的东西不是你自己的代码，是别人的代码。

去看优秀的开源项目是怎么组织的：

• 目录结构是什么样的

• README怎么写的

• Issue和PR是怎么管理的

• CI/CD（自动化测试和部署）是怎么配的

• 代码规范是什么样的

我推荐几个适合初学者看的仓库，不是让你看代码（可能看不懂），是让你看项目是怎么运作的：

- github/docs GitHub自己的文档仓库，结构清晰 - firstcontributions/first-contributions 专门帮新手完成第一次PR的项目 跟着它的教程走一遍 你就学会了完整的PR流程 - EbookFoundation/free-programming-books 免费编程书籍合集 看它的README怎么组织大量信息

特别推荐 first-contributions 这个项目。它存在的唯一目的就是让你迈出开源贡献的第一步——fork它、改一行文件、提一个PR。整个过程有详细的图文教程，十分钟就能走完。

完成之后你的GitHub主页上就有了第一个PR记录。 心理上的意义比技术上的大得多——你不再是一个旁观者了，你参与过了。

第七件事：那些你迟早会遇到的坑

提前知道它们，能让你在遇到时少慌一些。

merge conflict（合并冲突）。 两个人改了同一个文件的同一行，Git不知道该听谁的，于是它把两个版本都留下来让你手动选。你会在文件里看到这样的东西：

<<<<<<< HEAD 你的版本 ======= 别人的版本 >>>>>>> branch-name

别慌。把这些标记和你不想要的那个版本删掉，留下正确的内容，然后重新 add 和 commit 就行。冲突不是错误，是Git在跟你商量。

detached HEAD。 某天你不小心checkout到了一个具体的commit而不是分支上。终端会提示你 “You are in ‘detached HEAD’ state”。这不是什么严重的问题，git checkout main 回到主分支就好。但如果你在detached HEAD状态下做了commit而没有创建分支，那些commit会很难找回来。

推送被拒绝。 git push 报错说远程有你本地没有的更新。先 git pull 把远程的变更拉下来，解决可能的冲突，再push。不要用 git push -f。

（对，就是我大二那次干的蠢事）

-f 是force push，它会用你本地的版本强制覆盖远程的版本。在个人项目里可能无所谓，在协作项目里这等于把别人的工作全删了。

.gitignore 文件。 有些文件不应该被提交到仓库里——临时文件、编译产物、密钥、数据库文件、node_modules 文件夹。在仓库根目录创建一个 .gitignore 文件，把不想追踪的文件或文件夹写进去：

# Python __pycache__/ *.pyc .env # Node node_modules/ dist/ # IDE .vscode/ .idea/

GitHub上有一个仓库叫 github/gitignore，收集了各种语言和框架的 .gitignore 模板，直接拿来用就行。

一条学习路径

如果让我给一个完全的初学者设计一条路径，大概是这样：

第1天：理解Git和GitHub的区别， 安装Git，配置用户名邮箱 第2天：创建第一个仓库， 走通 add → commit → push 流程 第3天：学会 git status、git log、git diff 能看懂自己做了什么变更 第4天：学会分支， 创建分支、切换分支、合并分支 第5天：去 first-contributions 完成第一次Pull Request 第6天：用GitHub Pages搭一个个人页面 第7天：找一个你感兴趣的开源项目， 读它的README，翻翻它的Issue

一周时间，每天一两个小时。走完之后你不会成为Git专家，但你会具备一个基本的工作能力——能管理自己的代码，能参与别人的项目，能在GitHub上有一个看起来”活着”的主页。

剩下的——rebase、cherry-pick、submodule、GitHub Actions——用到的时候再学。我到现在都没完全搞懂rebase在所有场景下的行为。没关系。Git是一个你可以用十年的工具，不需要第一周就全学会。

---

后来我回想大二那次force push的事，觉得挺有意思的。

那时候我什么都不懂，对着终端敲命令，像是一个不识字的人在按按钮——知道按下去会发生”某件事”，但不理解”为什么”。所以报错的时候我慌了，搜了一个最暴力的解法，一把force push，问题确实”消失”了。

但问题没有被解决。它只是被覆盖了。

后来我慢慢明白，学任何工具都有这么一个阶段——你先是在模仿，照着教程一步步做，它说输什么你输什么，跑通了你觉得自己会了。然后某一天出了一个教程没覆盖的情况，你才发现自己什么都不会。

真正的”会”，是你理解了每个命令背后在做什么。git add 不是一个咒语，它是在把工作区的变更复制到暂存区的索引文件里。git commit 不是”保存”，它是在本地仓库的对象数据库里创建了一个不可变的快照，指向一棵由blob和tree组成的Merkle树。

你不需要在第一天就理解到这个深度。但当你用了一段时间之后，花一个下午去了解一下Git的内部模型——.git 目录里到底存了什么、commit对象长什么样、分支为什么本质上只是一个指针——这些知识会让你从”会用Git”变成”懂Git”。

会用的人遇到问题会慌，懂的人遇到问题会说”我知道发生了什么”。

这中间的差距，不是更多的教程能填的。是你自己去翻、去试、去犯错、去理解之后，某一天突然跨过去的。

---

其实不只是Git。我后来发现编程世界里的很多东西都是这样——第一次接触的时候觉得莫名其妙，用了一阵子之后觉得”也就那样”，再过很久回头看才意识到它的设计有多精妙。

Git就是这种东西。Linus Torvalds在2005年用两周时间写出来的这个工具，底层模型简洁到优雅——所有东西都是对象，所有对象都用内容的哈希值来寻址，分支只是指向某个commit的指针。整个设计像一道干净的数学证明。

你不需要在第一天就欣赏这种优雅。先把它当一个工具用起来。但如果有一天你突然觉得”这个东西设计得真漂亮”，那说明你已经走了很远了。

走到那一步之前，最重要的事情只有一件——

今天就开始。 创建你的第一个仓库，提交你的第一行代码，推送你的第一次commit。不需要代码多好，不需要项目多完整。一个只有README的仓库也是一个仓库。

很多人在”准备学Git”这件事上花的时间，比真正学Git花的还多。收藏了二十篇教程，关注了十个Git教学账号，买了一本《Pro Git》放在书架上积灰——但就是没有打开终端敲下第一个 git init。

别准备了。现在就打开终端。

第一步永远是最难的那一步，也是唯一重要的那一步。剩下的，走着走着就会了。Git第一步永远是最难的那一步，也是唯一重要的那一步。剩下的，走着走着就会了。