在上一篇文章裡，我們認識了 Git，那台幫專案做版本控制的「時光機」。
透過 commit 跟分支，我們能在 Vibe Coding 的過程中放心嘗試各種想法，就算改壞了也能隨時回到完好的版本。不過 Git 有個小限制：它的資料只儲存在自己的電腦裡。
如果想把專案分享給朋友看看、甚至直接拿別人公開的工具來用，光靠了解 Git 是還不夠的。這時候，我們就會需要一個「雲端」的角色，把 Git 所管理的專案推到網路上。
而這個角色，就是 GitHub。
GitHub 不只是 Git 的雲端版本，它同時也是全世界最大的開源社群。當我們在打造 Vibe Coding 專案時，GitHub 能讓專案有雲端備份、能跨裝置同步、能跟人協作；而當我們想參考別人的工具或 Skill 時，GitHub 就是寶藏。
接下來，就讓我們一起來認識 GitHub 的核心概念吧：）
▍認識 GitHub 上的專案資料夾
在 GitHub 上，每一個專案都會放在一個叫做 Repository（簡稱 Repo）的地方。
你可以把它想成一個雲端的專案資料夾，裡面除了裝著專案的所有檔案，還記錄著這份專案從第一個 commit 到現在的完整版本歷史。換句話說，它跟你電腦上那個被 Git 管理的資料夾是「對應的」，只是一個在本地，一個在雲端。
以 Anthropic 的 skills 為例，一個 Repo 頁面上常見的元素有這幾個：
檔案列表（中間主區）：專案裡所有的檔案與資料夾，GitHub 會在網頁上直接呈現，不用下載也能線上瀏覽。
README.md（檔案列表下方）：專案的說明書，告訴造訪者這個專案是什麼、怎麼用。
Star（右上角）：類似於社群上的「按讚」，數字越高通常代表越多人覺得它值得參考。
Issues（上方 tab）：回報 Bug 或提出建議的地方，有點像專案專屬的討論區。
Pull requests（上方 tab）：其他人想把改動合併進來的請求，也就是等一下會聊到的 PR。
理解了 Repo 是什麼後，接下我們就能進一步去認識電腦上的 Git，要怎麼跟 GitHub 上的 Repo 互通有無。
▍本地與雲端之間的同步方式
當專案同時存在於本地與雲端時，它們之間就需要一套溝通方式，讓兩邊隨時保持同步。
GitHub 上最常用到的三個動作，就是 Clone、Push 跟 Pull。
Push（推送）：把本地的改動推上雲端
當我們在電腦上完成修改，並用 Commit 存好進度後，這些變更是只儲存在電腦裡而已。如果想讓 GitHub 也有這份檔案，就需要透過 Push（推送）把專案從本地「推」上雲端的 Repo。
對 Vibe Coder 來說，Push 最大的好處有兩個：一是買個保險做雲端備份，不用怕電腦出狀況讓心血泡湯；二是方便分享，不管是要分享給朋友看，還是開源讓大家下載，都可以透過 Push 來去讓大家瀏覽專案成果。
可以這樣對 Claude Code 說：
第一次推送（需要先在 GitHub 建立空的 Repo 並複製網址）：
這是我在 GitHub 上建立的 Repo 網址 [貼上網址]，請幫我把目前的本地專案推上去
後續更新（當已經綁定過時）：
幫我把目前的進度推到 GitHub 上
Pull（拉取）：把雲端的最新狀態拉回本地
反過來說，如果你換了一台裝置想繼續開發、或是在 GitHub 上編輯了某個檔案，那此時電腦上的版本就不是最新的了。
這時候就需要 Pull，把 GitHub 上最新的改動「拉」回本地，讓兩邊重新對齊。像是平常在桌機上開發、週末想換筆電繼續做一點，只要先在筆電上 pull 一下，就能接著桌機的進度往下做。
可以這樣對 Claude Code 說：
拉一下 GitHub 上最新的版本
此時，Claude Code 就會把雲端最新的 commit 抓下來合併到本地，讓本地電腦也同步到最新狀態。
Clone（複製）：把雲端的專案抓下來
前面兩個動作是針對「自己已經在做的專案」做同步，而 Clone 則是用在當你在 GitHub 上看到一個想用或想參考的專案，那麽就可以透過 Clone，把這個專案裡的所有檔案，連同完整的版本歷史一起複製過來。
複製完之後，電腦上就會有一份能直接用 Git 管理的本地專案副本，可以開啟、編輯，也可以接著往下開發與調整等。
這也是 Clone 跟一般「下載」最大的差別。下載只會拿到當下的檔案內容，是一份脫離 Git 管理的靜態副本；而 Clone 會把整個版本軌跡也一起帶下來，讓我們能在本地用 Git 隨時查看過往的 commit、切換分支、甚至回到某個歷史版本。
可以附上 Repo 的網址，並這樣對 Claude Code 說：
把這個 GitHub 上的專案 clone 到我的電腦
此時，Claude Code 就會把整份專案抓到電腦上，讓我們能直接打開來使用或繼續開發。
養成本地與雲端同步的節奏
簡單回顧一下這三個操作：
Push：把本地的改動推到雲端（電腦 → GitHub）
Pull：把雲端的最新版本拉回本地（GitHub → 電腦）
Clone：把整個專案完整複製下來，包含所有版本歷史
在這三個動作裡，最值得帶進日常開發的，是 Commit 與 Push 這組雙層備份的節奏。
實際開發時，可以這樣安排：每完成一個小修改就先 Commit 起來，把進度存在本地；當功能告一段落、或完成大項目的開發時，再 Push 到 GitHub 上做雲端備份。
過程中可以這樣跟 Claude Code 說：
commit 目前的進度
功能完成後再說：
把目前的進度 push 到 GitHub 上
這樣的安排，能讓我們在保持心流的同時，每一段進度也都有著雙層備份。再也不用擔心電腦突然出狀況，過去幾個小時的努力就跟著消失。
▍用 Fork 在 GitHub 上建立專案副本
到這裡，我們已經知道可以透過 Push 與 Pull 來讓本地跟雲端同步，並用 Clone 把公開的專案複製下來。但 GitHub 上還有一個更有趣的操作，那就是 Fork（分叉）。
Clone 跟 Fork，差在哪裡呢
兩個動作都是「複製別人的專案」，但複製的「位置」跟「關係」完全不同。舉個情境來說明：你在 GitHub 上看到一個很實用的 Skill，想拿來用用看。
如果用 Clone，這個 Skill 會被複製到「你的電腦」上。你可以打開、可以修改、可以使用，但這份副本只存在於本地，跟原作者的 Repo 沒有任何關係。哪天如果剛好電腦壞掉了，這份副本也就跟著消失。
而如果用 Fork，這個 Skill 會被複製到「你的 GitHub 帳號」下，變成一個你完全擁有的雲端 Repo。你可以把它 clone 到任何一台電腦來修改，改完再 push 回去。重點是，這份雲端副本永遠都在，且跟原版會保持著「上下游」的連結關係。
Fork 與原版之間的「上下游」關係
Fork 的特別之處，在於會跟原版會保持著「上下游」的連結。你的 fork 是「下游」，原作者的 Repo 是「上游」。
這個連結有什麼用呢？最大的好處是：你可以在自己的 fork 裡自由調整，而當原版有了新功能或 Bug 修正時，可以選擇把這些更新「同步」回你的 fork，讓你的版本既保留客製化內容，又能跟著原版一起進化。
不過，看到這裡可能會想說：在同步原版的更新時，自己所做的調整會不會被覆蓋掉呢？
在大多數情況下，是不會的。
當我們把原版的最新版本同步到自己的 fork 時，Git 會自動進行「合併（Merge）」，把原版的新改動跟你自己的修改整合在一起，而不是用原版去覆蓋你的內容。
只有一種情況需要你手動介入：當你跟原作者改到了「同一個檔案的同一段內容」時，那麼 Git 就會跟你說「這裡有衝突，請選擇要保留哪個版本」，這就是在上一篇文章裡談過的衝突（Conflict）。
就以以下的情境，來說明 Git 會如何應對：
當改了 A 檔案、原作者改了 B 檔案時 → 完全不衝突，兩邊改動都會自動保留
當跟原作者都改了同一個檔案，但改的是不同段落時 → Git 通常也能自動合併
當跟原作者改了同一個檔案的同一段時 → Git 會提醒衝突，讓我們決定保留哪個版本
Vibe Coder 可以如何用 Fork
對 Vibe Coder 來說，Fork 最常出現在這幾個情境：
客製化別人的 Skill：看到一個很實用的 Skill，但想根據自己的工作習慣調整。這時候 fork 一份回來，就能自由修改成自己的版本，而不會動到原作者的東西。
延伸開源的專案：在 GitHub 上看到一個有趣的小工具或範本，想拿來改成自己的版本時，那麼就可以透過 Fork 來在自己的帳號下持續開發，未來也能跟原版同步更新。
保留學習用的副本：想研究別人的專案是怎麼寫的，但又怕改著改著就回不去。Fork 一份在自己帳號下，就能放心地拆解、實驗、嘗試各種改法。
操作上，Fork 也很簡單。在 GitHub 的 Repo 頁面右上角會有一個「Fork」按鈕，點下去之後，你的帳號底下就會多出一個一模一樣的 Repo，下方會標注「forked from xxx」，來告訴我們這是從哪裡分叉出來的。
▍透過 Pull Request 來為 GitHub 做出開源貢獻
介紹完 Fork，Github 上還有一個值得認識的功能是 Pull Request（簡稱 PR）。
雖然這名稱看起來有點不直覺又繞口，但它的概念其實很單純，其功能在於當我們在 fork 裡做了調整時，若有嘗試出更好的方法或修掉某個 Bug，此時就可以透過 PR 請原作者把你所做的優化調整「拉（pull）」進他的 Repo 裡。
一個 PR 通常會包含幾個關鍵資訊：
標題與說明：改了什麼、為什麼這樣改
改動的內容：GitHub 會把改了哪些檔案、新增或調整了哪些段落都列出來，來讓原作者能方便查看
討論區：原作者跟其他人可以在這裡留言，提問或給建議
值得注意的是，PR 通常不是「丟出去就結束」。它更像是一場對話，原作者可能會說「這邊可以再調整一下」，你就回去修改、再更新 PR。直到最後都調整好時，才會正式合併進原版。
當被合併的那一刻，就能成為 Contributor 的一員
當原作者審閱完 PR、覺得改得不錯按下「Merge」之後，那麼此時我們的改動就正式進到了原版的 Repo 裡，同時我們的名字也會出現在 Contributors 名單上。
而這正是在逛 GitHub 時，在 Repo 頁面上會看到的 Contributors 名單，這些 Contributors 正是靠著「主動貢獻」來成為其中一員的。
因此，其實每個人都能透過 Fork → 修改 → PR 的流程，來成為某個專案的 Contributor。
這過程也呼應了 Github 的開源精神，原始碼是公開的，任何人都可以看、可以用、可以改。Fork 加上 Pull Request 的機制，讓「眾人協作」能夠有秩序地進行下去，原作者保有最終決定權，貢獻者也不需要取得特別的權限才能參與。
這也正是 GitHub 之所以能成為全世界最大開源社群的核心原因之一。
▍走進開源的世界
回顧一下，GitHub 的核心操作其實就是這幾個動作的排列組合：
想用別人的工具 → Clone 下來就好
想改、想客製 → 先 Fork 到自己的帳號，再 Clone 那份 fork 下來改
想把改進回饋給原作者 → Fork → 修改 → 發 Pull Request
把這幾個動作組合起來，我們就能做到三件事：把專案備份到雲端、跨裝置同步進度、跟世界各地的人一起協作。
不過如果只「看」的話是還不夠的，想要真正弄懂概念的話，需要的是動手練習：）
因此我做了一個 Git & GitHub Guide，這是一個公開的網站，把 Git 跟 GitHub 的核心概念整理成可以隨時翻閱的指南，讓大家除了讀文章之外，也能有一個能反覆對照、查找的學習地圖。
比較有趣的是，這個網站背後的 GitHub Repo 也是公開的，因此你可以把它拿來練習這篇文章學到的所有動作：
練習 Clone：把整個專案抓到自己的電腦上，看看它是怎麼組成的
練習 Fork：複製一份到自己的帳號下，改成你想要的樣子
練習 Pull Request：如果你發現網站有錯字、或想補充什麼概念，可以 fork 之後修改，再發 PR 給我。說不定你就是這個專案的第一位 Contributor
這樣一來，你不只是在練習動作，還可能就此成為這個專案的一份子。動手做過一次，這些概念就會從文字變成你手感的一部分。
如果上一篇我們把 Git 比喻成「時光機」，那 GitHub 就像是讓這台時光機連上了世界，讓我們的進度有了備份，也讓我們能跟世界各地的開源作品學習，把想法走得更遠。
接下來，就讓我們帶著這些概念與知識，放心地去打造任何想做的專案吧：）