Programming字數 4781閱讀時長12 分鐘

GitHub 新手入門指南:從倉庫、Commit、Fork 到一天一提交

一篇面向零基礎用戶的 GitHub 入門指南,解釋倉庫、Commit、Branch、Pull Request、Fork、Star、Watch、Issue 等常見概念,並給出適合新手的一天一提交練習方法。

很多人第一次打開 GitHub,會被一堆英文按鈕勸退:RepositoryCommitBranchPull RequestForkStarWatchIssueActions……看起來像程序員專屬工具。

但 GitHub 可以先用一句很簡單的話理解:

GitHub = 一個用來存放程式碼、記錄修改、協作開發、展示專案的網站。

如果你正在學習 AI 工具、Claude Code、Codex、Cursor、Vercel、Next.js、Python 項目,GitHub 基本繞不開。很多開源項目託管在 GitHub 上,很多網站部署也會連接 GitHub 倉庫。

這篇文章不追求一次講完所有 Git 命令,而是先幫助新手理解 GitHub 頁面上最常見的概念和按鈕。先看懂頁面,再慢慢學命令,會輕鬆很多。

一、Git 和 GitHub 是一回事嗎?

不是。

名稱可以怎麼理解作用
Git本地版本管理工具記錄文件每一次修改,方便回退和協作
GitHub在線代碼託管平台把 Git 項目放到網上,方便展示、備份、協作

簡單說:

Git 是工具,GitHub 是平台。

你可以在自己電腦上使用 Git 管理代碼,也可以把代碼推送到 GitHub 上保存和展示。Git 更像底層工具,GitHub 更像一個圍繞 Git 建立起來的網站和協作平台。

二、Repository:倉庫是什麼?

Repository 通常簡稱為 repo,中文可以叫“倉庫”。

一個倉庫就是一個項目的文件夾。例如:

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,把當前狀態記錄下來。例如:

第一次 commit:初始化專案
第二次 commit:加入首頁版面
第三次 commit:修復搜尋功能
第四次 commit:更新 README 文件

Commit 的意義不是“隨便點一下保存”,而是給項目留下清晰的修改歷史。以後你想知道某個功能什麼時候加的、某個 bug 是怎麼出現的,就可以回看 commit 記錄。

一個好的 commit message 應該簡潔說明你做了什麼,例如:

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

中文項目也可以寫中文:

新增首頁佈局
修復搜尋篩選問題
更新 README 安裝說明
重構 API 請求邏輯

新手剛開始不用追求特別專業的 commit 規範,但至少要避免寫成 aaatest隨便改改 這種完全看不出含義的信息。

五、Git commit 身份由什麼決定?

很多新手會誤以為:

我在 VS Code 登入了 GitHub,所以 commit 作者就是這個 GitHub 賬號。

這不完全對。

Git commit 的作者身份主要由本地 Git 配置決定,也就是:

git config user.name
git config user.email

如果你想查看當前項目的 Git 身份,可以在終端輸入:

git config user.name
git config user.email

如果你想設置全局身份,可以輸入:

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

需要注意:

VS Code / GitHub 登入:主要用於 push、pull、存取遠端倉庫。
Git commit 作者:主要由 git config 的 user.name 和 user.email 決定。

所以換 GitHub 賬號後,最好檢查一下本地 Git 配置,避免 commit 仍然顯示舊郵箱或舊名字。

六、Main 與 Branch:主線和分支到底是什麼?

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

很多人看到 mainbranchmergepull request,會下意識以為它們是幾個不同文件夾,或者以為 branch 就是把整個項目完整複製了一份。

更準確的理解是:

main = 專案的主線版本,通常代表目前最穩定、最正式的程式碼。
branch = 從某個時間點分出去的一條修改路線,用來安全地做實驗或開發新功能。

GitHub 官方文檔裏提到,新倉庫會包含一個默認分支。別人打開倉庫、查看代碼、克隆項目時,默認看到的通常就是這個默認分支。現在很多新項目默認分支名叫 main,有些舊項目仍然可能叫 master

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

可以把一個項目想象成一篇正在寫的文章。

main 就像正式發佈版:

正式文章.docx

你現在想大改一章,但又怕改壞原文,所以不會直接在正式文章上亂改,而是複製一份草稿:

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

你在草稿裏隨便改。改得好,再合併回正式版;改得不好,直接丟掉草稿,正式版不受影響。

在 Git 裏,這條“草稿路線”就叫 branch。

不過要注意:Git 的 branch 並不是笨重地複製整個文件夾。Git 官方文檔對 git branch 的說明是,分支會創建一個新的 branch head,指向當前 HEAD 或指定的起點。新手可以先把它理解成:

branch 不是把整個專案完整複製一份,而是從某個 commit 開始,記錄一條新的修改路線。

2. 為什麼需要 branch?

因為真實項目經常會同時發生幾件事:

主線程式碼需要保持穩定;
你想開發一個新功能;
別人正在修復一個 bug;
還有人正在重寫 README;
線上突然出了問題,需要緊急修復。

如果所有人都直接改 main,項目很容易亂掉。一個人改壞了,所有人都會受影響。

所以更安全的做法是:

main 保持穩定
新功能開 feature 分支
bug 修復開 fix 分支
文件修改開 docs 分支
確認沒問題後,再合併回 main

例如:

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

這就像一條主路旁邊分出幾條施工便道。施工便道上可以改造、試錯、返工;等修好了,再接回主路。

3. main 是什麼?

main 通常是倉庫的默認分支,也就是項目的主分支。

你可以把 main 理解成:

這個專案目前對外展示的主要版本。

常見情況包括:

  • 別人打開你的 GitHub 倉庫,默認看到的通常是 main
  • 別人 clone 你的倉庫,本地默認拿到的通常是 main
  • 網站部署平台,比如 Vercel,常常會監聽 main 分支的更新。
  • 團隊項目裏,main 往往被要求保持可運行、可部署、相對穩定。

所以新手最好養成一個習慣:

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

小項目、個人學習項目可以直接改 main,問題不大;但如果是正式項目,最好開新分支修改。

4. branch 是什麼?

branch 中文叫“分支”。

你可以把它理解為:

從 main 的某個版本分出去,單獨做一組修改。

例如你的網站現在在 main 上是穩定的:

main: 首頁正常、文章頁正常、搜尋正常

你想新增一個評論功能,但不確定會不會改壞頁面。於是你開一個新分支:

feature/comment-system

然後你在這個分支上開發評論功能。此時:

main 仍然保持原樣;
feature/comment-system 裏可以大膽修改。

等你測試確認沒問題,再把這個分支合併回 main

5. branch 不是 fork

新手還容易混淆 branchfork

概念發生在哪裏可以怎麼理解
Branch同一個倉庫內部同一個項目裏分出一條修改路線
Fork不同 GitHub 賬號 / 倉庫之間把別人的倉庫複製一份到自己賬號下

例如:

你自己的倉庫裏開 feature/search-page,這叫 branch。
你把別人的專案複製到自己賬號下,這叫 fork。

所以:

branch 是倉庫內部的分支;
fork 是倉庫之間的複製。

6. 一個最簡單的分支工作流

對於新手,先記住這個流程就夠了:

1. main 上是穩定版本
2. 從 main 建立一個新 branch
3. 在 branch 上修改文件
4. commit 保存修改
5. push 到 GitHub
6. 建立 Pull Request
7. 檢查沒問題後 merge 回 main
8. 刪除已經完成的 branch

對應到真實場景:

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

合併以後,main 就包含了這個新功能。

7. 常見分支命名

分支名最好能說明你正在做什麼。

常見寫法:

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

大致規則是:

前綴用途示例
feature/新功能feature/search-page
fix/修 bugfix/login-error
docs/文檔修改docs/update-readme
refactor/重構代碼refactor/api-client

新手不需要過度糾結命名規範,但最好不要用 test1newnewfinal-version 這種看不出含義的名字。

8. 用一句話總結 main 和 branch

可以這樣記:

main 是主線,branch 是支線。
main 負責穩定展示,branch 負責安全修改。
branch 改好後,通過 Pull Request 合併回 main。

如果你是個人項目,剛開始可以直接在 main 上提交;但當你的項目變複雜,或者你擔心改壞網站,就應該開始使用 branch。

七、Pull Request:PR 是什麼?

Pull Request 簡稱 PR,可以理解為:

我已經改好一部分內容,請你檢查一下。如果沒有問題,就合併回主專案。

PR 常見於團隊協作和開源項目。

例如你 fork 了別人的項目,修復了一個 bug,然後提交 PR 給原作者。原作者可以查看你的修改,討論、要求調整,最後決定是否合併。

PR 不是單純“上傳代碼”,而是一個審查、討論、合併代碼的協作流程。GitHub 官方文檔也把 Pull Request 描述為一種建議修改、接收反饋、處理衝突和推進合併的機制。

八、Fork:復刻 / 派生是什麼意思?

Fork 可以理解為:

把別人的 GitHub 倉庫複製一份到自己的帳號下。

Fork 之後,你可以在自己的副本里自由修改,不會影響原項目。

典型流程是:

看到一個開源專案
→ 點擊 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 太多項目,否則通知會很多。

可以簡單理解:

按鈕含義
Star我覺得這個項目不錯,先收藏
Watch我想持續關注這個項目的更新和討論
Fork我想複製一份到自己賬號下修改

十一、Issue:問題、建議和討論

Issue 可以理解為項目裏的“問題單”或“討論帖”。

常見用途包括:

  • 報告 bug
  • 提出新功能建議
  • 記錄待辦事項
  • 進行項目討論
  • 提問使用問題

例如:

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,但看到這個按鈕時,知道它和自動化有關就可以了。等你學會基礎的 commitpushbranchPR 後,再學 Actions 會更自然。

十三、Code 按鈕:下載和複製倉庫地址

在 GitHub 倉庫頁面,綠色的 Code 按鈕很重要。

點擊它通常可以看到:

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

常見命令:

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

意思是把遠程 GitHub 倉庫下載到本地電腦。

如果你只是想看看代碼,不想用 Git,也可以點擊:

Download ZIP

把整個項目下載成壓縮包。

十四、Push、Pull、Clone 分別是什麼意思?

這幾個詞非常常見。

命令 / 概念中文理解作用
clone克隆 / 下載把 GitHub 倉庫下載到本地
push推送把本地 commit 上傳到 GitHub
pull拉取把 GitHub 上的新內容同步到本地
commit提交在本地記錄一次修改

一個簡單流程是:

clone 專案到本地
→ 修改文件
→ commit 記錄修改
→ push 上傳到 GitHub

如果別人也改了遠程倉庫,你需要:

pull 拉取最新內容
→ 再繼續修改
→ commit
→ push

十五、一天一提交是什麼意思?

很多人說的“一天一提交”,通常是指每天在 GitHub 上做一次有效貢獻,讓自己的貢獻圖保持連續。

GitHub 個人主頁上有一個綠色貢獻圖,它會顯示你在不同日期的貢獻情況。貢獻可以包括 commit、pull request、issue、discussion 等活動,但 GitHub 對哪些活動會顯示在貢獻圖上有具體規則,並不是所有操作都會被計入。

新手要注意:

一天一提交不是為了刷綠格子,而是為了養成持續迭代專案的習慣。

比較健康的做法是每天做一個小而真實的改動,例如:

  • 修改 README 的一段說明
  • 修復一個小 bug
  • 增加一個小功能
  • 整理項目目錄
  • 補充一條學習筆記
  • 優化一個頁面樣式
  • 添加一個測試用例

不建議為了提交而提交無意義內容,例如每天只改一個空格。這樣對個人成長和作品展示幫助不大。

十六、適合新手的一天一提交練習法

如果你不知道每天提交什麼,可以按照這個節奏來。

1. 第 1 天:創建倉庫

創建一個新倉庫,例如:

github-learning-notes

添加一個 README,寫清楚這個倉庫用來記錄 GitHub 學習筆記。

2. 第 2 天:補充 GitHub 常見詞彙

在 README 裏增加:

Repository = 倉庫
Commit = 提交
Branch = 分支
Pull Request = 合併請求
Fork = 復刻 / 派生

3. 第 3 天:添加命令行筆記

新增一個文件:

command-line-basics.md

記錄 lscdmkdirpwd 等命令。

4. 第 4 天:添加 Git 命令筆記

新增:

git-basics.md

記錄:

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

5. 第 5 天:整理目錄結構

把筆記整理成:

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 裏補充:

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

這樣做比機械刷提交更有價值,因為你最後會得到一個真正能展示學習過程的項目。

十七、新手常用 Git 命令

如果你使用 VS Code,也可以通過圖形介面完成很多操作。但理解下面這些命令很有幫助。

查看當前狀態:

git status

把修改加入暫存區:

git add .

提交修改:

git commit -m "Update README"

推送到 GitHub:

git push

從 GitHub 拉取最新內容:

git pull

查看提交歷史:

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 clonegit statusgit addgit commitgit push。 4. 接着做一個自己的學習筆記倉庫,堅持一週真實提交。 5. 最後再學習 Pull Request、開源貢獻、GitHub Actions。

不要一開始就追求複雜協作。先把自己的項目上傳、修改、提交、展示跑通,比背概念更重要。

二十、總結

GitHub 對新手來說,最重要的不是一開始就掌握所有命令,而是先理解幾個核心動作:

建立倉庫
→ 修改文件
→ 提交 commit
→ 推送 push
→ 展示專案

如果你還想參與別人的項目,就再理解:

Fork
→ 修改
→ Commit
→ Pull Request

GitHub 本質上是一個記錄作品、展示能力、參與開源、管理項目的平台。對於學習 AI 工具和網站開發的人來說,它不僅是代碼倉庫,也是你的長期作品集。

每天做一點真實改動,持續記錄、持續提交、持續總結,比短時間堆很多複雜概念更重要。

常見問題

這篇文章適合什麼水平的開發者?

可參考正文中的「適用對象」說明;本站編程欄目的文章覆蓋從入門到 AI 編程工作流等不同層次,每篇會有不同的預設背景。

文章中的工具或命令在不同系統上會有差異嗎?

會。macOS、Linux 和 Windows 的終端環境、路徑格式和命令語法存在差異,文章中若未說明具體系統,建議結合官方文檔對應調整。

推薦配合哪些 AI 工具學習編程?

Claude Code 和 Codex 是目前能力較強的編程 AI 工具,可以用來解釋代碼、補全邏輯、調試錯誤和生成腳本。相關工具介紹可參考本站 CC Switch 工具文章Vibe Coding 面試題集

學編程最重要的習慣是什麼?

動手做比看教程更重要。建議儘早找一個真實項目(哪怕很小)來練手,遇到問題時查文檔和代碼,而不只是看完理論再說。

參考來源

如果你已經熟悉 Git 基礎操作,可以進一步瞭解如何將 AI 工具接入工作流:Vibe Coding / Agentic Flow 面試題集

Share

分享這篇文章