GitHub 新手入门指南：从仓库、Commit、Fork 到一天一提交

很多人第一次打开 GitHub，会被一堆英文按钮劝退：Repository、Commit、Branch、Pull Request、Fork、Star、Watch、Issue、Actions……看起来像程序员专属工具。

但 GitHub 可以先用一句很简单的话理解：

txt GitHub = 一个用来存放代码、记录修改、协作开发、展示项目的网站。

如果你正在学习 AI 工具、Claude Code、Codex、Cursor、Vercel、Next.js、Python 项目，GitHub 基本绕不开。很多开源项目托管在 GitHub 上，很多网站部署也会连接 GitHub 仓库。

这篇文章不追求一次讲完所有 Git 命令，而是先帮助新手理解 GitHub 页面上最常见的概念和按钮。先看懂页面，再慢慢学命令，会轻松很多。

一、Git 和 GitHub 是一回事吗？

不是。

简单说：

txt Git 是工具，GitHub 是平台。

你可以在自己电脑上使用 Git 管理代码，也可以把代码推送到 GitHub 上保存和展示。Git 更像底层工具，GitHub 更像一个围绕 Git 建立起来的网站和协作平台。

二、Repository：仓库是什么？

Repository 通常简称为 repo，中文可以叫“仓库”。

一个仓库就是一个项目的文件夹。例如：

txt my-website/ ├── README.md ├── package.json ├── src/ └── public/

在 GitHub 上，一个仓库通常包含：

• 项目代码
• 项目说明文档
• 修改记录
• Issue 讨论
• Pull Request 协作记录
• Actions 自动化流程

如果你想展示自己的网站、Python 工具、AI Agent 项目，就可以创建一个 GitHub 仓库。对于个人学习者来说，仓库不仅是备份代码的地方，也可以看作长期作品集。

三、README：项目说明书

README.md 是 GitHub 项目里最重要的说明文件之一。

当别人打开你的仓库时，GitHub 通常会自动展示 README 内容。它应该尽量讲清楚：

1. 这个项目是做什么的。 2. 如何安装和运行。 3. 有哪些主要功能。 4. 用到了哪些技术。 5. 是否有项目截图或演示链接。 6. 作者、许可证和其他说明。

对于个人项目来说，README 写得清楚，比单纯堆代码更容易让别人快速理解你的能力。尤其是简历项目、作品集项目、开源学习项目，README 就像项目的门面。

四、Commit：提交是什么意思？

Commit 可以理解为一次“保存版本”。

你每完成一小步修改，就可以做一次 commit，把当前状态记录下来。例如：

txt 第一次 commit：初始化项目 第二次 commit：添加首页布局 第三次 commit：修复搜索功能 第四次 commit：更新 README 文档

Commit 的意义不是“随便点一下保存”，而是给项目留下清晰的修改历史。以后你想知道某个功能什么时候加的、某个 bug 是怎么出现的，就可以回看 commit 记录。

一个好的 commit message 应该简洁说明你做了什么，例如：

txt Add homepage layout Fix broken search filter Update README installation guide Refactor API request logic

中文项目也可以写中文：

txt 新增首页布局 修复搜索筛选问题 更新 README 安装说明 重构 API 请求逻辑

新手刚开始不用追求特别专业的 commit 规范，但至少要避免写成 aaa、test、随便改改 这种完全看不出含义的信息。

五、Git commit 身份由什么决定？

很多新手会误以为：

txt 我在 VS Code 登录了 GitHub，所以 commit 作者就是这个 GitHub 账号。

这不完全对。

Git commit 的作者身份主要由本地 Git 配置决定，也就是：

bash git config user.name git config user.email

如果你想查看当前项目的 Git 身份，可以在终端输入：

bash git config user.name git config user.email

如果你想设置全局身份，可以输入：

bash git config --global user.name "Your Name" git config --global user.email "your-email@example.com"

需要注意：

txt VS Code / GitHub 登录：主要用于 push、pull、访问远程仓库。 Git commit 作者：主要由 git config 的 user.name 和 user.email 决定。

所以换 GitHub 账号后，最好检查一下本地 Git 配置，避免 commit 仍然显示旧邮箱或旧名字。

六、Main 与 Branch：主线和分支到底是什么？

这是 GitHub 新手最容易卡住的地方。

很多人看到 main、branch、merge、pull request，会下意识以为它们是几个不同文件夹，或者以为 branch 就是把整个项目完整复制了一份。

更准确的理解是：

txt main = 项目的主线版本，通常代表当前最稳定、最正式的代码。 branch = 从某个时间点分出去的一条修改路线，用来安全地做实验或开发新功能。

GitHub 官方文档里提到，新仓库会包含一个默认分支。别人打开仓库、查看代码、克隆项目时，默认看到的通常就是这个默认分支。现在很多新项目默认分支名叫 main，有些旧项目仍然可能叫 master。

1. 先用一个普通比喻理解

可以把一个项目想象成一篇正在写的文章。

main 就像正式发布版：

txt 正式文章.docx

你现在想大改一章，但又怕改坏原文，所以不会直接在正式文章上乱改，而是复制一份草稿：

txt 正式文章.docx 修改第二章草稿.docx

你在草稿里随便改。改得好，再合并回正式版；改得不好，直接丢掉草稿，正式版不受影响。

在 Git 里，这条“草稿路线”就叫 branch。

不过要注意：Git 的 branch 并不是笨重地复制整个文件夹。Git 官方文档对 git branch 的说明是，分支会创建一个新的 branch head，指向当前 HEAD 或指定的起点。新手可以先把它理解成：

txt branch 不是完整复制一份项目，而是从某个 commit 开始，记录一条新的修改路线。

2. 为什么需要 branch？

因为真实项目经常会同时发生几件事：

txt 主线代码需要保持稳定； 你想开发一个新功能； 别人正在修复一个 bug； 还有人正在重写 README； 线上突然出了问题，需要紧急修复。

如果所有人都直接改 main，项目很容易乱掉。一个人改坏了，所有人都会受影响。

所以更安全的做法是：

txt main 保持稳定 新功能开 feature 分支 bug 修复开 fix 分支 文档修改开 docs 分支 确认没问题后，再合并回 main

例如：

txt main ├── feature/search-page ├── fix/mobile-layout └── docs/update-readme

这就像一条主路旁边分出几条施工便道。施工便道上可以改造、试错、返工；等修好了，再接回主路。

3. main 是什么？

main 通常是仓库的默认分支，也就是项目的主分支。

你可以把 main 理解成：

txt 这个项目当前对外展示的主要版本。

常见情况包括：

• 别人打开你的 GitHub 仓库，默认看到的通常是 main。
• 别人 clone 你的仓库，本地默认拿到的通常是 main。
• 网站部署平台，比如 Vercel，常常会监听 main 分支的更新。
• 团队项目里，main 往往被要求保持可运行、可部署、相对稳定。

所以新手最好养成一个习惯：

txt 不要在 main 上随便做大改动。

小项目、个人学习项目可以直接改 main，问题不大；但如果是正式项目，最好开新分支修改。

4. branch 是什么？

branch 中文叫“分支”。

你可以把它理解为：

txt 从 main 的某个版本分出去，单独做一组修改。

例如你的网站现在在 main 上是稳定的：

txt main: 首页正常、文章页正常、搜索正常

你想新增一个评论功能，但不确定会不会改坏页面。于是你开一个新分支：

txt feature/comment-system

然后你在这个分支上开发评论功能。此时：

txt main 仍然保持原样； feature/comment-system 里可以大胆修改。

等你测试确认没问题，再把这个分支合并回 main。

5. branch 不是 fork

新手还容易混淆 branch 和 fork。

例如：

txt 你自己的仓库里开 feature/search-page，这叫 branch。 你把别人的项目复制到自己账号下，这叫 fork。

所以：

txt branch 是仓库内部的分支； fork 是仓库之间的复制。

6. 一个最简单的分支工作流

对于新手，先记住这个流程就够了：

txt 1. main 上是稳定版本 2. 从 main 创建一个新 branch 3. 在 branch 上修改文件 4. commit 保存修改 5. push 到 GitHub 6. 创建 Pull Request 7. 检查没问题后 merge 回 main 8. 删除已经完成的 branch

对应到真实场景：

txt main → 新建 feature/update-homepage → 修改首页 → commit: Update homepage layout → push → Pull Request → merge into main

合并以后，main 就包含了这个新功能。

7. 常见分支命名

分支名最好能说明你正在做什么。

常见写法：

txt feature/login-page feature/search-function fix/mobile-navbar docs/update-readme refactor/api-client

大致规则是：

新手不需要过度纠结命名规范，但最好不要用 test1、newnew、final-version 这种看不出含义的名字。

8. 用一句话总结 main 和 branch

可以这样记：

txt main 是主线，branch 是支线。 main 负责稳定展示，branch 负责安全修改。 branch 改好了，通过 Pull Request 合并回 main。

如果你是个人项目，刚开始可以直接在 main 上提交；但当你的项目变复杂，或者你担心改坏网站，就应该开始使用 branch。

七、Pull Request：PR 是什么？

Pull Request 简称 PR，可以理解为：

txt 我改好了一部分内容，请你检查一下。如果没问题，就合并进主项目。

PR 常见于团队协作和开源项目。

例如你 fork 了别人的项目，修复了一个 bug，然后提交 PR 给原作者。原作者可以查看你的修改，讨论、要求调整，最后决定是否合并。

PR 不是单纯“上传代码”，而是一个审查、讨论、合并代码的协作流程。GitHub 官方文档也把 Pull Request 描述为一种建议修改、接收反馈、处理冲突和推进合并的机制。

八、Fork：复刻 / 派生是什么意思？

Fork 可以理解为：

txt 把别人的 GitHub 仓库复制一份到自己的账号下。

Fork 之后，你可以在自己的副本里自由修改，不会影响原项目。

典型流程是：

txt 看到一个开源项目 → 点击 Fork → 在自己的 fork 仓库里修改 → 提交 commit → 发起 Pull Request → 请求原项目合并你的修改

对于新手来说，Fork 有两个常见用途：

1. 学习别人的项目结构。 2. 基于别人的开源项目做二次开发。

但要注意，Fork 不等于拥有版权。使用别人的项目之前，最好查看项目的 License，确认自己能否复制、修改、商用或再发布。

九、Star：收藏 / 点赞是什么意思？

Star 可以理解为 GitHub 上的收藏或点赞。

你看到一个有价值的项目，可以点击 Star，方便以后找回来。

Star 数量也常被用来粗略判断项目受欢迎程度，但它不是唯一标准。一个项目 Star 很多，不代表一定适合你；一个项目 Star 不多，也不代表没有价值。

对于学习 AI、Agent、前端、Python 的人来说，可以把 Star 当成自己的开源项目收藏夹。

十、Watch：关注项目动态

Watch 表示关注一个仓库的通知。

如果你 Watch 了一个项目，GitHub 可能会把这个项目的 Issue、PR、Release 等动态通知你。

一般新手不需要随便 Watch 太多项目，否则通知会很多。

可以简单理解：

十一、Issue：问题、建议和讨论

Issue 可以理解为项目里的“问题单”或“讨论帖”。

常见用途包括：

• 报告 bug
• 提出新功能建议
• 记录待办事项
• 进行项目讨论
• 提问使用问题

例如：

txt Bug: Search does not work on mobile Feature request: Add dark mode Question: How to configure API key?

对于自己的项目，也可以用 Issue 管理待办任务。比如你做个人网站，可以给自己开几个 Issue：修复移动端样式、补充 SEO 描述、添加文章搜索、整理 README。这样项目会更像一个真实工程，而不是一堆零散文件。

十二、Actions：自动化流程

GitHub Actions 是 GitHub 自带的自动化工具。

它可以在你 push 代码后自动执行一些任务，例如：

• 自动测试
• 自动构建
• 自动部署
• 检查代码格式
• 发布版本

例如很多 Vercel、Next.js、Python 项目都会结合 GitHub Actions 或其他部署平台完成自动化流程。

新手刚开始不用急着学 Actions，但看到这个按钮时，知道它和自动化有关就可以了。等你学会基础的 commit、push、branch、PR 后，再学 Actions 会更自然。

十三、Code 按钮：下载和复制仓库地址

在 GitHub 仓库页面，绿色的 Code 按钮很重要。

点击它通常可以看到：

• HTTPS 地址
• SSH 地址
• GitHub CLI 地址
• Download ZIP

常见命令：

bash git clone https://github.com/username/project-name.git

意思是把远程 GitHub 仓库下载到本地电脑。

如果你只是想看看代码，不想用 Git，也可以点击：

txt Download ZIP

把整个项目下载成压缩包。

十四、Push、Pull、Clone 分别是什么意思？

这几个词非常常见。

一个简单流程是：

txt clone 项目到本地 → 修改文件 → commit 记录修改 → push 上传到 GitHub

如果别人也改了远程仓库，你需要：

txt pull 拉取最新内容 → 再继续修改 → commit → push

十五、一天一提交是什么意思？

很多人说的“一天一提交”，通常是指每天在 GitHub 上做一次有效贡献，让自己的贡献图保持连续。

GitHub 个人主页上有一个绿色贡献图，它会显示你在不同日期的贡献情况。贡献可以包括 commit、pull request、issue、discussion 等活动，但 GitHub 对哪些活动会显示在贡献图上有具体规则，并不是所有操作都会被计入。

新手要注意：

txt 一天一提交不是为了刷绿格子，而是为了养成持续迭代项目的习惯。

比较健康的做法是每天做一个小而真实的改动，例如：

• 修改 README 的一段说明
• 修复一个小 bug
• 增加一个小功能
• 整理项目目录
• 补充一条学习笔记
• 优化一个页面样式
• 添加一个测试用例

不建议为了提交而提交无意义内容，例如每天只改一个空格。这样对个人成长和作品展示帮助不大。

十六、适合新手的一天一提交练习法

如果你不知道每天提交什么，可以按照这个节奏来。

1. 第 1 天：创建仓库

创建一个新仓库，例如：

txt github-learning-notes

添加一个 README，写清楚这个仓库用来记录 GitHub 学习笔记。

2. 第 2 天：补充 GitHub 常见词汇

在 README 里增加：

txt Repository = 仓库 Commit = 提交 Branch = 分支 Pull Request = 合并请求 Fork = 复刻 / 派生

3. 第 3 天：添加命令行笔记

新增一个文件：

txt command-line-basics.md

记录 ls、cd、mkdir、pwd 等命令。

4. 第 4 天：添加 Git 命令笔记

新增：

txt git-basics.md

记录：

bash git status git add . git commit -m "Update notes" git push

5. 第 5 天：整理目录结构

把笔记整理成：

txt github-learning-notes/ ├── README.md ├── notes/ │ ├── command-line-basics.md │ └── git-basics.md └── resources.md

6. 第 6 天：添加参考资料

新增 resources.md，记录 GitHub Docs、Git 官方文档、优秀开源项目链接。

7. 第 7 天：写一周总结

在 README 里补充：

txt 这一周我学会了什么？ 还有哪些地方不懂？ 下一步想做什么？

这样做比机械刷提交更有价值，因为你最后会得到一个真正能展示学习过程的项目。

十七、新手常用 Git 命令

如果你使用 VS Code，也可以通过图形界面完成很多操作。但理解下面这些命令很有帮助。

查看当前状态：

bash git status

把修改加入暂存区：

bash git add .

提交修改：

bash git commit -m "Update README"

推送到 GitHub：

bash git push

从 GitHub 拉取最新内容：

bash git pull

查看提交历史：

bash git log --oneline

新手可以先把这几个命令练熟，不需要一开始就背复杂命令。真正写项目时，你会自然遇到更多场景，比如切换分支、解决冲突、回退版本。

十八、新手最容易误解的地方

1. GitHub 登录不等于 commit 身份

登录 GitHub 主要解决的是远程仓库访问权限。commit 显示什么名字和邮箱，要看 Git 配置。

2. Fork 不等于下载

Fork 是复制到你的 GitHub 账号下；Clone 才是下载到你的电脑。

3. Commit 不等于 Push

Commit 是本地保存版本；Push 是上传到 GitHub。

4. Star 不等于 Fork

Star 是收藏；Fork 是复制项目副本。

5. Pull Request 不一定会被接受

PR 是请求原项目合并你的修改，但项目维护者可以接受、拒绝，也可以要求你继续修改。

6. GitHub 贡献图不等于真实能力

贡献图可以展示持续性，但不能完全代表工程能力。真正有价值的是项目质量、文档清晰度、代码可运行性和持续迭代记录。

十九、建议学习顺序

如果你是零基础，我建议这样学：

1. 先学会看懂仓库页面：README、Code、Issues、Pull Requests、Actions。 2. 再理解 Repository、Commit、Branch、Fork、Star、Watch。 3. 然后学会 git clone、git status、git add、git commit、git push。 4. 接着做一个自己的学习笔记仓库，坚持一周真实提交。 5. 最后再学习 Pull Request、开源贡献、GitHub Actions。

不要一开始就追求复杂协作。先把自己的项目上传、修改、提交、展示跑通，比背概念更重要。

二十、总结

GitHub 对新手来说，最重要的不是一开始就掌握所有命令，而是先理解几个核心动作：

txt 创建仓库 → 修改文件 → 提交 commit → 推送 push → 展示项目

如果你还想参与别人的项目，就再理解：

txt Fork → 修改 → Commit → Pull Request

GitHub 本质上是一个记录作品、展示能力、参与开源、管理项目的平台。对于学习 AI 工具和网站开发的人来说，它不仅是代码仓库，也是你的长期作品集。

每天做一点真实改动，持续记录、持续提交、持续总结，比短时间堆很多复杂概念更重要。

参考来源

• GitHub Docs：Hello World
• GitHub Docs：Changing the default branch
• GitHub Docs：Managing the default branch name for your repositories
• Git Documentation：git-branch
• GitHub Docs：Pull requests documentation
• GitHub Docs：Fork a repository
• GitHub Docs：Profile contributions reference
• GitHub Docs：Understanding GitHub Actions