為什麼需要 Git？版本管理到底是在管什麼？

想像你正在寫一篇深度調查報導。為了避免改壞、誤刪，桌面上的檔案很可能會越來越多：

這種做法雖然直覺，但很快就會失控。你可能會忘記哪一份才是最新版本，也可能在某一天突然發現：其實「最終版」刪掉的某一段，才是最有力的內容。這時候，要回頭找回正確版本就很麻煩。

Git 可以把它想成一台專業的時光機，也是一套很有秩序的檔案管理系統。它會幫你記錄每一次改動，讓你在任何時候都能回到過去的某個版本，查清楚當時改了什麼、為什麼這樣改。

對寫作、採訪、編輯來說，這不只是「備份工具」，更是一種管理工作流程的方法。

Git 的三個地盤：檔案怎麼從草稿變成正式版本？

在 Git 裡，檔案通常會經過三個地方。可以把它想成一份稿件從你桌上一路送進檔案櫃的流程。

1. 工作區（Working Directory）

你可以把工作區想成自己的辦公桌。

你平常打開 Word、記事本或編輯器，寫稿、改句子、刪段落，這些都發生在工作區。這時候的內容雖然已經改了，但 Git 還沒有正式幫你記錄下來。

也就是說，這裡是「你正在動手修改」的地方。

2. 暫存區（Staging Area）

暫存區可以想成辦公桌旁邊的一個「待審稿夾」。

當你覺得某些修改已經準備好、想納入下一次正式存檔時，就先把它放進這個夾子裡。這等於是在告訴 Git：

「等一下正式存檔時，請把這些內容一起收進去。」

對應的指令是：

git add 檔案名稱

3. 儲存庫（Repository）

儲存庫可以想成報社裡的正式檔案櫃。

當你確認這次修改值得留下紀錄，就會執行一次 commit。這時 Git 會把暫存區裡準備好的內容打包，形成一個正式版本，永久存進儲存庫。

對應的指令是：

git commit -m "修正受訪者職稱"

這一刻，就像你替目前的工作成果拍了一張快照，而且附上一張標籤，說明這次到底改了什麼。

用採訪稿來看一次完整流程

假設你正在修改一份 訪談.txt。

第一步，你直接打開檔案，在裡面改內容。這些修改都發生在工作區，Git 目前只是知道你動過檔案，但還沒有正式收錄。

第二步，你執行 git add，把這份稿子放進暫存區。這代表它已經被標記為「準備納入下一次版本」。

第三步，你執行 git commit，Git 就會把這次準備好的內容正式存進儲存庫，形成一個永久版本，並替它產生一個獨特的識別碼，也就是 Hash。

這也是 Git 很可靠的原因。只要某個版本曾經被 commit 過，就算你後來在工作區誤刪檔案、改壞內容，理論上都還能把舊版本找回來。

幾個最常用的實戰指令

1. git diff：看看到底改了什麼

你改了 採訪稿.txt，但改到一半突然不太確定自己動過哪些地方，這時候可以用：

git diff

螢幕上通常會出現紅色和綠色的內容：

如果用新聞系的情境來比喻，這很像主編拿著校對稿，清楚標出「原本寫什麼」和「現在改成什麼」。

這個指令最大的價值，就是讓你在正式存檔前先確認：這次改動是不是你真正想保留的。

2. git commit：把這次修改正式入庫

當你確認修改完成，可以先 git add，再用 git commit 留下正式紀錄：

git add 採訪稿.txt
git commit -m "修正受訪者頭銜"

這樣一來，這次改動就不只是存在你桌上的草稿，而是正式進入 Git 的版本歷史。

3. git log：查看過去存過哪些版本

如果你想知道今天到底存了幾次版本，可以輸入：

git log

你會看到像這樣的一串紀錄：

每一筆紀錄都代表一次 commit，也就是一次正式存檔。前面那串像亂碼的字，就是每個版本獨一無二的識別碼，叫做 Hash。

你可以把 git log 想成自己的工作日誌。它會清楚告訴你：你什麼時候做了哪些修改。

災難發生時，Git 為什麼像救命時光機？

假設到了晚上，你把原本語氣比較平衡的一篇報導，改成了一個非常辛辣、攻擊性很強的版本，還順手 commit 了。

結果主任看完後立刻說：

「這版不行，風險太高，請馬上改回下午那個版本。」

如果沒有 Git，你可能只能靠記憶慢慢改回來，既耗時間，也容易越改越亂。

但如果你有 Git，就可以直接指定某個版本，把檔案內容恢復成當時的樣子。例如：

git checkout a1b2c3d -- 採訪稿.txt

這行指令的意思是：

「請把 採訪稿.txt 這個檔案，恢復成 a1b2c3d 那次版本的內容。」

執行後，檔案就會回到你指定的那個狀態。剛才新增的辛辣字眼會消失，下午四點那份較安全的版本會回來。

現在較新的寫法通常也會用 git restore，但先理解這種「把檔案切回舊版本」的概念最重要。

不過，現實中的編輯現場常常不是「改回去就結束了」。也有可能主任今天說要改回保守版，明天又改口：「其實昨天那個辛辣版裡，有幾句寫得很有力，可不可以再救回來？」 這時候，與其在同一份檔案裡反覆刪改，不如一開始就把兩種寫法分開保存成兩個分支。

你可以把它想成兩條平行的採訪線：

這兩個分支可以同時存在、各自修改，彼此不會互相干擾。你今天可以先把主線切回較安全的版本交給主任，同時保留另一條較犀利的版本繼續打磨。之後如果主任改變主意，你不用憑記憶重寫，也不用從舊稿堆裡慢慢找，只要切換到對應的分支，就能立刻回到那一條寫作路線。

這也是 Git 很強大的地方：它不只讓你「回到過去」，還能讓你把不同版本的想法同時保留下來，像在經營兩個平行時空。對新聞工作來說，這特別實用，因為一篇稿子常常會在「穩健」、「尖銳」、「精簡」、「完整」之間來回拉扯，而 Git 可以幫你把這些可能性都整理得井井有條。

為什麼這對新聞工作特別有用？

1. 不怕手滑，也不怕改壞

只要你有 commit，過去版本就留得住。寫長篇報導、專題、逐字稿整理時，這點非常重要。

2. 改動都有跡可循

你不只知道現在稿子長什麼樣，也知道它是怎麼一步一步變成現在這樣。這對查核、修訂、多人協作都很有幫助。

3. 可以放心嘗試不同版本

你可以先寫一個較保守的版本，也可以另外試一個角度更尖銳的版本，最後再決定哪一條路線比較適合發表。

Git 內部其實在管理什麼？

當檔案被存進 Git 之後，它不是單純地「把整個資料夾複製一份」而已。Git 內部其實會把資料拆成幾種不同的物件來管理。理解這些概念，有助於你更知道 Git 為什麼這麼快、這麼可靠。

Git 的五大核心零件

可以把 Git 想成一個分類非常精密的圖書館系統。它主要靠下面五種東西來運作。

1. Blob：檔案內容本身

Blob 可以理解成「檔案的內容」。

在 Git 眼裡，它其實不太在乎這個檔案叫什麼名字，而是比較在乎裡面到底寫了什麼。只要內容不一樣，就會被視為不同的物件。

你可以把 Blob 想成一張印滿文字的稿紙。哪怕只改了一個字，Git 看來那都是另一張新的稿紙。

2. Tree：資料夾與結構

Tree 負責記錄目錄結構，也就是：

如果 Blob 像一張稿紙，那 Tree 就像一個資料夾。它不直接寫內容，而是負責整理與指向內容。

3. Commit：某一刻的正式快照

Commit 是 Git 最核心的概念之一。

當你執行 commit 時，Git 其實是在替你目前整理好的檔案狀態拍一張快照。這張快照記錄的是「那一刻整個專案長什麼樣子」。

你也會替這次快照寫一句說明，例如：

所以 commit 不只是「存檔」，更像是一次有標註、有時間點的正式紀錄。

4. Hash：每個物件的身分證字號

Git 會根據內容，替每個物件算出一組獨特的識別碼，這就是 Hash。

看起來通常像一串英數混合的字，例如：

a1b2c3d4...

你可以把它理解為數位指紋。只要內容稍微不同，Hash 就會完全改變。這也是 Git 很可信的原因之一：它能很準確地辨認每個版本是否一致，有沒有被改動。

5. Branch：平行時空中的不同寫法

Branch 是 Git 最有魅力的功能之一。

假設你正在處理一篇政治新聞，主線版本目前是穩健、保守的寫法；但你也想試試看更尖銳、更有評論性的版本。這時候，你可以開一個新的 branch，等於從目前進度切出一條平行路線。

在新的 branch 上，你可以放心修改，不用擔心影響原本主線。等你比較完兩種版本，覺得新的更好，再把它合併回來就可以。

這對需要反覆修稿、嘗試不同角度的寫作者來說，非常實用。

最後總結：Git 到底在幫你做什麼？

可以把整個流程想成這樣：

  1. 你寫出一份稿件，Git 先記住它的內容，這是 Blob。
  2. Git 再記住它放在哪個資料夾裡，這是 Tree。
  3. 你決定正式存一版，Git 就替當下狀態拍下一張快照，這是 Commit。
  4. 這張快照和裡面的物件，都有各自獨特的 Hash，方便追蹤與辨識。
  5. 如果你想嘗試不同方向的改寫，就可以另外開一條 Branch，在平行路線上安心實驗。

所以，Git 不只是工程師的工具。對新聞系學生來說，它其實也是一種很成熟的寫作與協作方法：

當寫作不只是一次交作業，而是反覆查證、修改、協作、定稿的過程時，Git 的價值就會變得非常明顯。

GitHub Pages:讓你的作品變成網站

GitHub Pages 是 GitHub 提供的免費服務,可以把你儲存庫裡的檔案直接變成一個網站,讓任何人都能用瀏覽器看到。

它是用來做什麼的?

簡單說,就是「把你的作品放到網路上」。

對新聞系學生來說,特別適合用來:

不需要租主機、不需要架設伺服器,只要你會用 Git,就能讓作品上線。

網址長什麼樣子?

發布後,你的網站網址通常是:

https://你的帳號.github.io/儲存庫名稱/

例如,如果你的 GitHub 帳號是 wang123,儲存庫叫 my-portfolio,網址就會是:

https://wang123.github.io/my-portfolio/

怎麼啟用?

  1. 到你的儲存庫頁面
  2. 點選上方的 Settings
  3. 左側選單找到 Pages
  4. 在「Branch」下拉選單選擇你要發布的分支(通常是 main 或 gh-pages)
  5. 按下 Save

重要提醒:檔案不會立刻上線

當你把檔案 push 到 GitHub 之後,GitHub Pages 需要一點時間重新建置你的網站。

通常需要 1 到 5 分鐘,有時候更久。

所以如果你改完檔案、push 上去後,馬上重新整理網頁卻發現沒變,先別緊張,等幾分鐘再看。

你也可以到 Settings → Pages 頁面,看看目前的建置狀態。如果看到綠色勾勾,就代表已經上線了。

gh-pages 分支是什麼?

gh-pages 是一個常見的分支名稱,專門用來放要發布的網站內容。

你可以這樣理解:

這樣做的好處是,你可以在 main 上慢慢改、測試,確定沒問題再推到 gh-pages 讓網站更新。

當然,如果你的專案比較簡單,也可以直接用 main 分支發布,不一定要另外開 gh-pages。

適合放什麼內容?

GitHub Pages 只能放靜態網頁,也就是:

它不支援需要後端伺服器的功能,例如 PHP、資料庫、會員登入系統等。

但對展示作品、發布報導、呈現數據視覺化來說,已經非常夠用。

新媒體內容技術與設計

New Media Techniques and Design

重設登入階段SVG Background animated by Loading.io