前言

這篇文章的內容，原本是想放在 commit 的常見問題。
結果當時寫完發現內容太多，如果全部塞到同一篇文章，應該會讓人看不下去。

不過這篇文章記錄的兩個問題，可能會是已經學會版控一段時間之後，或是實務上真的遇到時，才會去思考的問題。
很適合拿來當【一起學 Git 吧！】系列文章，中場休息的小品文閱讀。

我們就一起來看看吧！

每個 commit 的資料都只有專案「部分」的檔案，每個版本不是應該都要版控「所有」檔案嗎？

這問題可能一時之間不好理解，容許我重新描述一下問題的意思。

開始在執行版控之後，commit 的內容可能會是這樣：
第一版：新增專案說明檔案，記錄一個檔案： readme.md
第二版：新增三個空的檔案：index.html、app.js、style.css
第三版：處理好基本的切版，紀錄兩個檔案：index.html、style.css
第四版：處理畫面互動，紀錄兩個檔案：index.html、app.js

有沒有注意到一件事情，明明整個專案應該要有 四個 檔案，但竟然沒有一個 commit 一次存放 四個 檔案！？

這個疑問是在很久之前，我點開某個 commit 看到資料時想到的問題，那時候對這個狀況百思不得其解，總是有一種「commit」應該涵蓋所有內容的 感覺。

這大概是讓我我第一次想知道，Git 到底是「差異備份」還是「全部備份」的契機。
(如果你從來沒有這種疑惑，那你可以跳過這題了 XD)

後來仔細想想，會有這樣的感覺的原因可能是這樣：
過去我們在使用「資料夾備份」的行為，會把整包資料夾的內容完整複製一份，當作是一個版本在保存，所以只要點開任何「版本資料夾」，都可以看得到「所有檔案」在裡面。

或許是潛意識已經習慣這樣的畫面，使得我們在使用 Git 時，會無意間把每一個 commit 跟資料夾聯想在一起，認為 commit 應該也是要看到「所有檔案」才行。

不過我們要知道一件事情，Git 中每個 commit 所記錄的內容，只會紀錄我們 有異動 的檔案，而那些經過 Git 比較之後「相同」的檔案，Git 會直接對他置之不理。

所以 Git 的「版本」本質，本來就不是要一次紀錄「所有」工作目錄的內容，而是紀錄與「上一個版本」相比過後的「資料差異」。

這也是 「Git 是差異備份」 這句話的由來。

不過，Git 真的是差異備份嗎？
筆者認為這個問題應該要看「關注點」放在哪裡。

如果關注在 單一 Commit 上，因為我們只會看到「差異」的資料，似乎真的能得到 「Git 是差異備份」 的結論。

但如果把目光拉遠一點來看，一次看向 所有 commit 上，雖然每個版本都只記錄一小部分的差異，不過所有資料確實也都存放在 Git 中，好像也不能說 Git 只對「差異」的檔案進行備份。

就如同網購一樣，想買的商品太多 (但錢不夠) 所以分了好幾次下單，訂單紀錄雖然分成幾筆，但最後這些東西也都存放在自己家裡，並不會因為「分開買」的行為，害自己只拿到「部分」商品。

我們若已經把所有檔案都 commit 過了，無論是只做一次 commit 還是分好幾次 commit 都沒關係。
這時候如果不小心手殘把整份工作目錄的資料都刪了，只要 .git 資料夾還在，Git 就有能力把資料「全部」還原回來。

這麼推論下來，我們是不是也可以說 Git 也幫我們做了「全部備份」？

每一個 commit ，其實都站在過往 commit 的肩膀上。  

就好像疊疊樂積木一樣，因為有了過往的他們，才有辦法成就現在的自己。
除了第一個 commit，誰叫他要當第一個

「備份」的用途，是希望資料有閃失時有辦法被「還原」。
「版本」的用途，則是讓我去追溯不同時期的「檔案變化」。

這兩件事情， Git 都做得到。

只要 Git 有能力在我需要時，把各個版本還原到工作目錄中，或是在一個閃失誤刪資料時，幫我復原曾經記錄過的資料，那麼 Git 是「差異備份」還是「全部備份」的大哉問，或許也沒那麼重要了。

我一次編輯了好多檔案，應該 commit 全部的檔案 ，還是把每個檔案分開 commit？

一樣是那句話：「看需求」。

以前一個人使用 Git ，洋洋灑灑編輯完一堆檔案，想 commit 就 commit ，沒事也不會回頭去看 commit 的資料，真的就像拿手機把黑板的筆記拍下來一樣，只是在做一個心安感。

嚴格說起來，那時候只是想把程式上傳到 GitHub 而使用 Git，所以不是很在意每個版本的內容，只需要確定在其他電腦有辦法把程式從 GitHub 拉回來用即可。

不過在團隊開發的過程，大家是「一起」完成「同一份」專案，自己所 commit 的資料，或多或少是需要被團隊查閱的！
在這樣的版控需求下，每一個 commit 存放多少檔案數量就很重要了。

一個 commit 如果涵蓋數十個檔案，同事查閱 commit 時真的會會很難 code review。
就像你現在正在讀的文章一樣，主題如果資訊量太多、文字太繁雜，閱讀起來就會很難消化。 那個....預告一下，之後有一篇文章會這樣...

回到問題本身，如果只是想備份程式，那麼一次 commit 的檔案數量有多少，並不是太重要的事情。

但如果考慮到 code review 的可讀性，把「檔案數量」精簡化，同時針對內容清楚的寫好 commit 的標題描述，會是使用 Git 版控的好習慣。

這是我一位女神同事提點我的觀念，特此紀錄在文章之中。