在學版本控制之前，我覺得先理解以下幾個問題，會對學習更有幫助：
- 什麼是版本控制？
- 為什麼要用版本控制？
- 為什麼要讓軟體來幫我們做版控？
什麼是版本控制？
你一定做過報告吧？那你的報告檔案是不是會像這樣：報告 01 -> 報告 02 -> 報告最終版 -> 報告真的最終版。
這個其實就是「版本控制」。一個檔案你可能有很多個版本，但你又希望每個版本都能保存下來，接著為了知道每個版本之間的差異，你透過「命名」的方式來表示它們之間的關係。
為什麼要用版本控制？
如同上面所說，一個檔案可能有很多個版本，但你可能會怕之後不小心做壞了，所以為了避免這種搞壞了要全部重做的事情發生，我們會希望有一個「備用方案」的檔案。
所以「保存」其實就是我們做版控最主要的目的。
然而，當規模小的時候，你可以用「報告 01、報告 02，報告 03，…」這樣子的方式來做版控，但是當規模很大的時候，這就不是一個很好的做法（後面會解釋為什麼）。
這個時候你就會需要「讓程式來幫你做版本控制」。
為什麼要讓軟體來幫我們做版控？
想想看這個情境：假設有一份專案，目前有一個「穩定版」的版本。現在我們想要開發新功能，所以就繼續從穩定版的那個版本來做：
1 | -> 穩定版 |
但是如果現在 PM 突然跟你說有 Bug 需要修復，你該怎麼做？
是不是只能先把新功能拿掉，把 Bug 修復完畢，接著再重新開發新功能：
1 | -> 穩定版 |
（因為你不能把還沒開發完的新功能給一起發佈出去，所以你一定要先拿掉新功能，修好 Bug，接著才把修復好的檔案發佈。）
這種做法叫做「一條線的開發方式」。這種方式有個很大的問題：你沒有辦法同時處理多個事情。
但是，現在如果透過版控軟體（例如 Git）就可以建立一個出「分支（兩條線）」的概念：
1 | A 線：穩定版 -> 新功能 -> 新功能 -> ... |
你要開發新功能，就在 A 線這條分支上開發；你要修復 Bug，就在 B 線這條分支上修復，不需要像剛才一樣，先把新功能拿掉，接著再來修 Bug 這麼麻煩。
接著，當新功能開發完成後，我們不需要 A 線這條分支了，所以我們會把 A、B 合併起來（假設把 A 併到 B），就會變成這樣：
1 | B 線：穩定版 -> bug fix -> bug fix -> ... -> 新功能 -> ... -> 新功能 -> 正式發佈 |
所以透過版控軟體，大家就可以在 A 線或 B 線上各做各的事情，不用擔心彼此之間會互相干擾。
最後當其中一條線的任務完成時，只要透過「合併」的方式來變回一條線，就完成團隊之間的協作了。