給設計師的 Git for Dummies

前幾天在 Threads 隨口寫了一句：凡採用 AI 工作流程的 UI/UX 設計師（或非工程人員），都該先從 Git 學起，否則會很難跟人協作。

底下很快出現兩種聲音。一種是「開一堂給設計師的 Git 101 啊」，另一種是「套 skill 就好，學什麼學」。還有人問得更直接：設計師出的圖檔，本來就不能 git commit 吧？每個版本都是獨立檔案，也沒有「很多人共同畫一份 pages」這種事。

這篇主要想分享給開始用 AI 碰程式、但又還沒把 Git 當成自己工具的人。不是要你變成工程師，也不是叫你把 Figma 檔丟進 GitHub。只是我自己越來越覺得：當你真的能開 branch、交 coded prototype，有幾個詞不懂，跟工程師講話會卡住，叫 AI 救場也會救錯地方。

Claude Code 幫你生出一頁 HTML，那還只是你自己的草稿。要讓別人打開、留言、一起改，靠的不是 Claude 的預覽視窗，是 GitHub 存檔、Vercel 發網址。

⸻

▍為什麼是現在，不是三年前？

設計系統放在 Git 裡，一點都不新鮮。Tokens、component、icon font，工程那邊本來就在管版本。只是 AI 出現以前，那通常不是設計師的責任。

多數人還是在 Figma 交付。Git 就算存在，也是別人的工具。你改完畫面、標好 spec、丟連結，工作就結束了。

現在不一樣的是門檻。AI 把「動手寫一點前端」變成設計師做得到的事：開一個 branch，做一個 coded prototype，自己改 padding、自己修對齊、自己把 component 補進真實介面。這很好。但老實說，也很快就會碰到工程師每天在處理的東西——conflict、branch、PR 太大、想改回上一版卻改爛。

❖ Git 從前是工程的基礎設施。AI 把設計師也推進這套基礎設施裡，只是多數人還沒拿到地圖。

所以重點不是「設計師要不要學寫 code」。是：你已經在碰 code 了，協作語言卻還停在 Figma 的 Version History。

⸻

▍先講清楚：不是叫你把圖檔丟進 Git

這大概是最容易誤會的地方，所以我想放最前面。

Git 預設是為純文字設計的。一段 CSS 改一行，它只記住那一行的差。一張 PNG 改一個 pixel，它會把整張圖再存一次。Figma 的 .fig、PSD、影片、大圖匯出，都是這種 binary。能塞進去，但 repo 會胖到爆，之後誰 clone 都會恨你。

適合進 Git 的，通常是 component 原始碼、tokens、CSS / JSON、SVG、文件、coded prototype。不該進的，是匯出圖、.fig、影片、node_modules，還有一堆「最終最終_v3_最終.png」。

設計師本來就很少「很多人同時畫同一份 pages」。Git 要管的，也不是那件事。它管的是同一份文字檔被不同人、在不同時間改過，怎麼不互相覆蓋，怎麼回到某個確定存在過的狀態。

Figma 繼續管畫面。Git 管進到產品裡的那一層。兩套工具，兩種工作。

⸻

▍用 Figma 的語言講一次 Git

你不需要先懂指令。我自己是把這幾個詞，對回已經會的東西。

Repo（repository） 就是整份專案。有點像一個 Figma file，只是它活在資料夾裡，不只活在瀏覽器。

Commit 是一次有名字的存檔。Figma 的 Version History 會自己幫你存；Git 要你主動按，而且最好寫一句人話，說明為什麼存。update 跟 fix button 對之後的自己一點用都沒有。「把送出按鈕改成主色，避免在表單裡看起來像次要動作」，才像一則 commit。

Branch 比較像 Duplicate this page 來試。複製一份出來改，改壞了不影響大家認的那份。主幹通常叫 main。你的實驗、你的一顆按鈕、你的一頁 prototype，都該活在自己的 branch 上，而不是直接在 Production 檔裡揮毫。

Pull Request（PR） 是申請把你的那份合回主幹，讓人 review。工程師看的不是你的感覺，是 diff：這次到底改了哪些行。PR 不是交作業，是把改動變得可以被討論。

Conflict 則有點像兩個人同時改同一組 auto-layout。Git 不知道該聽誰的，誰覆蓋誰都不對。這時候要人來選，不是再喊一聲「幫我修一下」就結束。

另外兩個很容易混：Push 是把你電腦上的存檔上傳，Pull 是把別人已經上傳的改動下載回來。你在本地改得再漂亮，沒 push，別人看不到。你沒 pull，就可能在一份過期的檔上繼續改，最後撞上 conflict。

再來三個，之後看 GitHub 會一直撞到。

Tag 是幫某個 commit 取一個不會跑掉的名字，像 v1.2.0。Figma 的 Version History 會一直往下長；tag 比較像你親手 pin 住「這就是當時上線的那一版」。之後要對回那一版，靠的是這個名字，不是「大概上週四那個」。

Release 是把 tag 包成給人看的版本。GitHub 會在那個 tag 上面加說明、截圖、下載檔。Tag 是給 Git 認的錨點；release 是給同事、stakeholder 看的 changelog。不是每次 commit 都要 release。通常是真的要交給別人用了，才打一個。

Fork 是把別人的 repo 複製成你帳號下的一份。有點像 Duplicate 社群裡的 Figma file 到自己 drafts：原檔還在，你在自己那份改。改完若想貢獻回去，再從你的 fork 開 PR 到原作者的 repo。Fork 不是 branch。Branch 還在同一份專案裡；fork 是你擁有的另一份副本。

❖ 你不用會打這些指令。但你要認得這些詞出現時，房間裡正在發生什麼事。

⸻

▍幾件我覺得值得養成的習慣

我不是要你背 Git 教科書。只是這幾件事，之後幾乎每天都會用到。

第一，不要在 main 上直接動手。主幹是大家認的那份。開一條 branch，一個意圖，一個 PR。

第二，commit 訊息用 Conventional Commits。前面一個短的 type，後面才是人話。常見大概這幾個就夠用：

• feat: 新功能、新畫面、新狀態
• fix: 修 bug，或修一個看起來不對的細節
• docs: 只改說明
• style: 只改看起來的東西，行為沒變
• chore: 雜務，例如整理檔案、更新依賴

所以不要寫 update，比較像：

feat: 幫主按鈕加上 hover 狀態

fix: 修正表單送出後按鈕變成次要色

style: 把卡片間距從 12 調成 16

為什麼要加前綴？因為之後 changelog、release notes、工程師掃歷史，都靠這個分類。你現在多打四個字母，之後自己找「上次那個按鈕到底哪次改壞的」會快很多。

第三，送出前自己看 diff。圖檔、.fig、影片、node_modules、金鑰，都不要進 repo。AI 很愛 git add .，最後一眼得是你的。

第四，要回上一版，用 Git 的歷史，不要靠 prompt 回憶。真的要對外說「這是一版」，再打 tag；需要給人看說明時，才做 release。

⸻

▍「叫 AI 用 Git」不夠

有人說：不會 Git 也行，但要知道叫 AI 用 Git。這句對了一半。

叫 AI commit、push、開 PR，確實比自己背指令快。Skill 也能把流程包起來。可是 Skill 不是萬能，我們還是要懂得判斷。而且只是學一點點，就毋須每次都為了 git status 浪費 token。

更實際的問題是：AI 很會做動作，不一定知道動作對不對。

我看過最常見的災難，大概是這幾種。

第一，把「改回上一版」交給 prompt 去回憶。模型沒有你昨天檔案的記憶，它只是在猜上一版可能長什麼樣子。Git 的上一版不是回憶，是一份真的存在過的快照。要回去，用 Git；不要讓模型扮演時光機。

第二，PR 一次做太大。AI 很會把「改一個對齊」變成「順便重構旁邊三個 component」。送出前那種猶豫很真實：是不是該重做？工程師問的時候，我答得出來嗎？解法通常不是更會寫 prompt，而是把改動切小。一個 PR 做一件事。你自己都講不清楚的 diff，別人也不可能 review。

第三，看都不看就 commit。AI 幫你 git add . 的時候，可能連不該進版控的圖、環境檔、實驗代碼一起塞進去。git status 不是工程儀式，是你的最後一眼。

第四，一直待在 main 上改。直接在主幹上試 AI 的靈感，等於在 Production Figma 檔裡做探索稿。開 branch 只要十秒，之後省下來的，可能是整晚把檔救回來的時間。

我現在大概是這樣跑：先確認自己站在最新的主幹上，為這次改動開一條新 branch，改完自己看 diff，用 conventional commit 寫給三個月後的自己，再 push、開 PR。有 conflict 就停下來，問人，或讓 AI 解釋兩邊差在哪，再決定留哪一邊。不要讓它直接「全部接受」。

指令可以問 AI。你要保留的是判斷，不是記憶快捷鍵。

⸻

▍GitHub 是倉庫，Vercel 是店面

這兩個最常被混在一起，尤其是 Claude Code、Cursor、Codespaces 都開始能直接幫你生網頁之後。

GitHub 管的是原始檔和歷史。誰改了什麼、哪一條 branch、哪一個 PR、哪個 tag，都住在這裡。它比較像圖書館加共用硬碟：檔案可以很久，但打開 GitHub 網址，你看到的通常是 code，不是給客人看的網站。

GitHub Codespaces（以及 Claude Code、Cursor Cloud 那類雲端工作區）管的是一台暫時的電腦。它會把 repo 拉進來讓你改、讓 AI 改、讓你在裡面按預覽。這是工作桌，不是上線。Codespace 一停、一過期、一關掉，那張桌子就收起來了。沒 push 回 GitHub 的東西，別人拿不到；就算還在，那也不是一個你可以丟進 Slack 的公開網址。

Vercel 管的是部署。它去讀 GitHub 上的 repo，把 HTML / 前端專案建成一個真正能打開的網址。main 通常對應正式站；每一條 PR 會再生一個 Preview URL。這個網址才是給 PM、工程、客戶看的。他們不用裝 Claude，也不用進你的 Codespace。

所以不是「GitHub 比較高級、Vercel 比較漂亮」。一個負責記得，一個負責給人看。

❖ 存檔在 GitHub。預覽和上線在 Vercel。Codespace 只是你此刻坐的那張桌子。

Claude Code 生出一頁 HTML，預設常常只活在 Claude 自己的預覽裡。那很好用，可是協作會停在這裡：連結會過期、對方沒有 Claude 帳號就進不去、也沒有 diff 可以討論。

要讓它在 Claude 外面被看到、被一起改，路徑其實很短：

1. 把 HTML 存進一個 Git repo，不要只留在對話裡。
2. Push 到 GitHub。這一步才算真正存檔，別人才 clone / 開 PR 得了。
3. 用同一個 GitHub repo 接 Vercel。之後每次 push、每個 PR，Vercel 會給一個 Preview URL。
4. 把那個 Preview URL 丟進 Slack 或 PR 留言。對方打開的是網站，不是你的 Claude 視窗。

一個 index.html 也夠。不必先變成完整 Next.js 產品。Vercel 可以只是把靜態頁面掛上網。GitHub 負責「這份檔案現在長這樣、誰改過」；Vercel 負責「點開就能看」。Claude 的 hosting 兩邊都不是。

⸻

▍什麼時候你其實還在用 Figma 就好

不是所有設計工作都該進 Git。硬把流程塞進去，只會讓人討厭工具。

還在探索、還在對齊視覺、還在跟非工程的人討論方向，Figma 仍然比較快。Git 開始有價值，通常是這幾件事發生了：你改的是已經在產品裡的 component，不是一張新的探索稿；你交的是可以跑的 prototype，不是一組畫面；你跟工程師在改同一份真實介面；你需要一個能回得去的版本，而不是「我記得昨天好像比較好看」。

❖ 還在畫的時候用 Figma。開始進產品、開始跟人的 code 重疊，才需要 Git。

⸻

❖ 【小結】

我不是主張每個設計師去考 Git 證照，也不是說圖檔都該版本控制。我只是覺得，AI 把「設計師能碰程式」這件事提前了，而協作的摩擦不會因為你用自然語言下指令就消失。

Conflict 還是 conflict。PR 太大還是太大。上一版如果只存在於你的 prompt 裡，它就不算上一版。Claude 裡看得到，也不等於團隊看得到。

先搞懂 repo、commit、branch、PR、conflict，再加上 tag、release、fork。Commit 用 conventional 的前綴。檔案放 GitHub，預覽走 Vercel。Rebase、cherry-pick，之後再說。

⸻

❖ 【Asset】設計師的 Git 最小清單

• [ ] 改東西前，先確認自己不在別人的 main 上直接動手
• [ ] 一條 branch、一個意圖、一個 PR
• [ ] Commit 用 conventional 前綴：feat: / fix: / docs: / style: / chore:，後面寫人話，不寫 update
• [ ] 送出前看過 diff，知道這次改了什麼、沒改什麼
• [ ] 圖檔、.fig、影片不要進 repo
• [ ] 要回到上一版，用 Git 的歷史，不要靠 prompt 回憶
• [ ] 真的要對外給一版，才打 tag；需要給人看說明，才做 release
• [ ] 改別人的開源專案用 fork；同一份專案裡的實驗用 branch
• [ ] 叫 AI 跑 Git 可以，但 status 和 diff 你要自己看一眼
• [ ] Conflict 時先看懂兩邊，再決定；不要讓模型「全部接受」
• [ ] Claude / Codespace 裡的預覽只是工作桌；要給人看，push 到 GitHub，再用 Vercel Preview URL

來源：Threads 討論，2026 年 8 月。