【Git】Git 是什麼？版本控制？
農場文標題：不是工程師也能受益的版本控制觀念
最後更新時間：2024–08–31
前言
我很喜歡吐槽農場文標題，曾在這邊噴過，雖可理解下標題的人就是想吸引眼球，但不管是農場文或農場文標題其實都是一種外部成本，真心認為這種東西會拉低群眾智商對整個社會是負面影響，所以只要有機會就噴一下標題殺現象。不知道大家有沒有注意到本篇文章的副標？遊走在邊緣XD，但我認為版本控制觀念不只對工程師有幫助，瞭解這件事對各行各業應該或多或少都有點助益（這句話充滿不確定性字眼講得很保守，應該有幫助啦哈哈），如果有人想寫版本控制文章，以下已先想好農場文標題，如果你也想成為標題殺的 premium 用戶，歡迎拿去用：
- 寫給所有人的版本控制
- 10 個希望自己 30 歲前就懂的版本控制技巧
- 版控大歷史
- 資深工程師不會告訴你的 6 大版控秘辛
- 跟著大師學版控 — 精通版本控制：理論篇
- ……（歡迎留言分享更多你想到的農場文標題）
噴完垃圾話後可以切入正題了，如果新手不太熟 Git 這邊先一句白話介紹：就是一個由 Linus Torvalds（即 Linux 之父）開發的軟體版本控制工具，可記錄何時更新了什麼程式碼、多了啥功能等等。之所以想寫 Git & 版本控制是因為最近看到一篇文章：Git 的故事：這一次沒這麼好玩，顧名思義就是在講 Git 的歷史，很有趣推薦大家讀一讀，之所以看到這篇是因為朋友分享、也有同事跟我說看過這篇，後來才知道是 PTT 軟工版爆文。讀完後想想，咦，自己之前也寫過幾篇 Git 相關文章但好像沒有個脈絡，似乎可以更有組織地寫幾篇，於是就開始寫了。
BTW，其實我還滿喜歡瞭解軟體歷史，例如瀏覽器大戰或是像之前還在 ALPHA Camp 學習時就看過的一段影片：Revolution OS (作業系統革命)，這是一部有中文字幕的紀錄片，在講些 Linux 發展歷史、開放原始碼、自由軟體等，當時這個影片是放在延伸閱讀但我很有興趣就把它看完了，所以這次看到 Git 歷史毫不猶豫就點進去看，收穫滿滿。
說文解字
要談 Git 之前先來看看 git 這個字，如果要指 Git 這套版控工具我就會字首大寫，而若是在講某個 Git 指令的話就會小寫成 git，因為在終端機輸入指令是小寫例如 git push。現在來瞭解一下 git 這個字，先來看看 Yahoo 奇摩字典：
【英】【俚】飯桶，蠢貨
對，你沒看錯，就是北七的意思，再來看看劍橋字典：
a person, especially a man, who is stupid or unpleasant
對，無懸念，就是北七。
但，為什麼 Linus 要這樣命名 Git？
好奇的我去看了 Git 官網 但好像沒寫到？沒關係接著 google 查到這篇：Why is Git called Git?，然後又看到這篇：Linus Torvalds on how he came up with the name ‘git’. Yes, this is from git’s readme file.，咦，兩篇引用內容幾乎一樣，第二篇又說在 Git 的 readme 有寫，於是去找 Git 的 GitHub repo，還真的有，在 readme 最下面：
The name “git” was given by Linus Torvalds when he wrote the very first version. He described the tool as “the stupid content tracker” and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of “get” may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- “global information tracker”: you’re in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- “goddamn idiotic truckload of sh*t”: when it breaks
最後一點真的有夠哭，到底是怎麼想到「一拖拉庫的屎」這種白爛又傳神的形容XD。
話說，有點進去 repo 看的話會發現有個叫 gitster 的帳號發了 2 萬多個 commit，他就是Git 的故事：這一次沒這麼好玩提到的那位日本人濱野純（Junio C Hamano），也就是 Git 的現任維護人。
版本控制是什麼？
所以版本控制想控制的是什麼？控制版本（廢話）。版控其實無所不見，例如以前大學報告投影片檔案名稱，這個例子應該大家心有戚戚焉，例如：
- XX 期末報告 01
- XX 期末報告 001
- XX 期末報告 0001
- XX 期末報告 0001 最終版
- XX 期末報告 0001 最終修改版
- XX 期末報告 0001 最終修改版不會再改了
- （以下省略 10 幾個）
當然，命名肯定有不同流派，例如日期就是常用方法，但一樣會出現很多日期或是同個日期但不同時間點的檔案。寫到這邊還特地去翻以前大學時的報告檔但發現自己為了節省雲端硬碟空間已經把一堆非最終版本的簡報檔都砍掉了（果然很像我會做的事），有點可惜不然就可以截個圖然後說改編自真人真事。
所以當時為何要留這麼多名稱很像的檔案？就是為了版控，但又為何要版控？不外乎是怕某個版本內的東西未來會需要用到、留下紀錄萬一以後要檢討還可以看看當初內容的演變過程、又或者怕哪天簡報被教授打槍結果回到某個時間點的報告還比較好等等。
當時線上多人協作的概念還沒有很普及，一個典型的簡報製作流程就是大家分工把各自負責部分做一做然後交給一位同學彙整、順過整個投影片 & 風格，之後若有變動就看是歸屬誰負責的部分再做一做給彙整的同學，或是變動不大就直接由彙整者修改，然後每次更新便有個新檔案發給大家確認，而這種方式從現今角度回顧自然相當不足，例如無法快速得知每次檔案間的變動為何，更遑論知道每個變動是由誰、在何時出自於什麼原因做出此修改，而 Git 這種版控工具就能把這些東西好好地記錄清楚，對於我這種流程控 & 小小強迫症者，接觸到 Git 之後真的通體舒暢，我還滿喜歡用 GitHub、Azure DevOps、GitBucket 這類東西，每次看到分支、PR、commit 寫的清清楚楚實在有夠爽，不過分支管理、PR 流程、commit 怎麼寫又是另外一件事了。
為什麼寫程式需要版本控制？
假設你是 1 人開發，自己做自己的產品。記憶力終究是有限的，應該很難記住自己何時在哪些檔案做了什麼變更，但為什麼需要知道這些事？想想看，如果開發到某個時間點想休息一下給自己放個假，假期回來後再打開 repo，若不留下任何紀錄的話能記得休假前做到哪裡嗎？再者，如果哪天做好了一包功能發現網站壞掉了，假使沒有任何版本紀錄是不是相對不好找問題？也很難直接讓產品回到某個時間點的正常狀態。
版控最能發揮功能的情境之一便是多人協作，如果我跟一堆人協作但程式碼在何時被誰修改了什麼都不清楚，你不說我還以為自己在什麼神秘駭客組織上班。啊所以做版控有什麼好處？簡單列幾點（不只做版控，而是使用版控系統的好處）：
- 既然可以記錄誰、何時、做了啥，那延伸出來的就是 pull request 和 code review，團隊成員可以檢查 & 審核彼此的程式碼，才不會同事直接變駭客
- 當多個開發者同時開發一個專案時，版控系統可以讓大家在不互相覆蓋彼此工作內容的情況下進行協作。每個開發者可以在自己的分支上工作，最後再合併到主要分支
- 管理軟體的不同發佈版本，可標記某個穩定版本並隨時回到此版本進行修復或比對變更；萬一出問題也可迅速回溯到之前版本
- 版控系統會把每個版本的程式碼都保存起來，就是一個備份的概念
寫程式是軟體開發的一環，那除了寫程式有版控外，軟體開發的其他部份呢？
軟體開發中的其他版控
一定有很多，但我目前體會最多的有兩個，一個是技術文件，另一個則是產品需求規格（spec）。
1️⃣ 技術文件
文章要寫得好本身就不容易，而技術文件也是文章的一種，要寫好當然同樣不簡單，我也持續在撰寫公司技術文件中磨練自己，至於為何技術文件很重要以後有機會再寫一篇分享個人看法。技術文件也會有版控，通常這種文件應該會放在某個可協作的知識/文件管理軟體，例如 Confluence、Loop、Notion 等，甚至還聽過有人寫在 Teams 的（聽到這件事不知該用什麼表情面對對方，可能是這樣：😅），一樣道理，如果有人改了文件都不留下紀錄那團隊不就瘋掉，大家都能亂改一番，當然我們也不要直接用消極面去看，若用積極面去思考，做好技術文件版控有什麼好處？個人認為其實就是將團隊演進的過程記錄下來，未來要回頭找資料也能知道當時為何要這樣改，舉個例子，假設 N 年前團隊做了些研究想知道測試框架要用哪個，最後決定採用 A 框架，但在那之後 3 年市場上可能有更新更好的框架或是 A 框架已停止維護，於是團隊更新了文件記錄當時討論例如當初採用 A 框架的主要考量為何 & 這個考量是否當時還存在、還有哪些替代方案等等，並且最後換成了 B 框架，時間拉回到現在，假設公司真的有夠衰又遇到 B 框架停止維護或者覺得用一用發現已無法滿足團隊需求，此時是否就能根據之前技術文件的紀錄，瞭解到當時做決策的依據與考量，並且進一步幫助到現在的決策？再把格局拉高一點，一間企業要做好知識管理是相當困難的事，做知識管理的其中一個重要目的就是為了創造競爭優勢，但要管理知識總要有內容可以管理吧，而這些形成企業知識的材料就是要靠平常的累積與紀錄，這些材料不只是文件本身還包含其修改的過程。
技術文件如果有認真維護的話，應該會看到一個東西叫 Changelog，顧名思義就是 change 的 log，紀錄某文件過去有哪些變更，你也可以找找自己團隊的技術文件有沒有這個東西。
BTW，Confluence 跟 Loop 我都用過，有時去觀察性質相近的軟體其設計概念不同之處滿有趣的，其中一個跟版控有關的就是兩者編輯功能的設計不同，Confluence 如果要更新某頁面要去按一個很像筆的 icon ⇒ 進入編輯模式 ⇒ 編輯完成後按儲存，而 Loop 則跟 Notion 很像，直接開始編輯即可系統會隨時儲存，若正在寫文件即可發現文件歷史紀錄是每 1–2 分鐘就更新一次XD，所以其實 Loop 不像 Confluence 那樣有明確版控，而且 Confluence 還能讓你任挑兩個版本進行差異比較，因此就版控這件事而言 Confluence 在撰文當下基本上屌打 Loop，不過 Loop 是 2023 年 11 月發佈的，到現在還不到 1 年是個非常年輕的產品，而且有富爸爸撐腰，未來 Loop 發展應該是可以期待一下。
2️⃣ spec
不確定大家團隊中來自 PM 的 spec 文件是否跟技術文件放在同個軟體的同個空間（workspace），目前我遇過的基本上放在同個軟體，有時會不同空間。spec 若有何變動基本上不只版控，PM 還會在上面留下註記，例如原本某條 spec 可能就畫上刪除線然後補上更新後內容。spec 有紀錄與版控應該是相當好理解的事，不然做出來的東西跟實際需求不同大家就吵不完了。
版控在其他領域的應用
其實非常多，多到列不下，這邊隨便舉 3 個例子。
如果公司制度完善應該會有一堆規章制度的文件吧，有時可以看到這些文件前面幾頁會有更新紀錄，就是 changelog，甚至這個文件若本身很複雜可能還會有另一個文件專門負責記錄此文件的更新過程。當然，有些公司在公佈規章制度時可能不會把 changelog 也給大家看，滿正常的，不然內容太雜，但負責撰寫此文件的相關部門有 99.9% 的機率會有版控紀錄。為什麼公司規章制度要有版控？一樣啦，沒有的話一定吵翻天（尤其是大公司），規定什麼時候改的？誰改的？為什麼要改？這樣改真的對公司比較好？一問三不知的話公司大概亂成一團，反正規則隨便訂隨便改，光想就恐怖。
第 2 個例子，筆記軟體應該越來越多人在用了吧？我自己是因為察覺到工作上的痛點所以在 2020 年開始捨棄筆記本改用筆記軟體，目前用 4 年了非常滿意，關於為何改用筆記軟體、幾年來使用心得一樣非本篇主軸，未來有機會再分享。總之，如果你有在用筆記軟體，找找看，那個軟體 99.9% 有版控會記錄某篇筆記在某些時間點的內容。以 Notion 為例，在本文撰寫當下，若於筆記右上角的三個點點按下去會出現一堆東西，往下滑能看到一個叫「Version history」，點進去就能看到該筆記的版本紀錄，而且還有 Restore 功能。想想看，萬一哪天不小心貼上錯的東西覆蓋掉原有筆記內容，沒版控的情況下不就毀天滅地了！？當然不會，Ctrl/cmd + Z 就能復原上一步了，哩系勒，大驚小怪。不過老實說我是比較少用到筆記軟體的版控功能，但有這個功能確實令人比較安心一點，就像上述程式碼版控所提，其實版控系統不只做到版控某種程度上也幫你備份，所以哪天手殘刪錯東西卻又過了好幾個禮拜才發現，那 Restore 按鈕就能發揮功能了。
第 3 個例子其實本來是沒有要寫的，但是後來決定寫一下，緣由是 2024/7/24–25 凱米颱風掃過台灣，而放了自我有記憶以來很少出現的連續兩天颱風假（仔細回想，我好像真的沒連續放過兩天，當然，還是希望不要有災情），這兩天我的關鍵字是「整理」，整理了實體也整理數位，前者自然是整理住的地方、後者則是整理數位資料，像是手機 APP、瀏覽器書籤、以及雲端硬碟，雲端硬碟除了要整理也要備份，雖然像 Google 這種大廠應該都有做異地備援，但我還是習慣定期備份到行動硬碟。阿這跟版控有啥關係？因為我連雲端硬碟備份這件事也做了小小版控，其實就只是把近兩期的備份留下這樣XD，檔名前面會有日期，大概半年備份一次，萬一哪天資料掛掉最久還能回復到上上次的備份，或是上次備份時不小心已刪掉某個資料夾但後來發現還需要那就可以找到上上次的去救回來。因成本考量目前只保留兩期。
結尾
雖然本文標題提到 Git 但好像沒講到什麼 Git 指令？沒錯，誠如開頭提過的，在寫這篇之前我就已經打算更有組織地寫幾篇 Git，意思就是已經想好接下來幾篇要寫啥了，指令的部份會放在後面，不過在那之前，其實本部落格以前就寫過兩篇跟 Git 有關的文章，列出如下，歡迎參考。假如是剛接觸 Git 的初學者可以看第 1 篇 Git Flow 的部份就好，若是對 Git 有點概念準備要多人協作的夥伴那兩篇都可以看一看，而如果是 Git 高手則請跳過那兩篇歡迎直接與我分享更多 Git 技巧，感謝大大。
其他 Git 文章
