Git 是一套分散式版本控制軟體，用於管理文件或程式碼內容，確定團隊成員協作時取得是一致的內容，並可以追蹤變更過程。版本管理可以包含不同類型的文件，但一般情況不建議提交Binary 檔案。主要原因在於文本可以被追蹤變更紀錄，而Binary 檔案不行。另一方面，這些檔案比起純文字檔案大得多，除了讓Repository 容量變大，在切換分支或複製儲存庫會變得緩慢。
許多人會認為好好的寫文件並自動版號，為什麼需要額外一套系統來管理文件版本呢？理論上，版本是一直往前走，每一次的修改都應該讓產品更好更完善。但實際上在版本管理產品尚未問世之前，開發過程中可能會遇到各種來回修改與團隊協作的衝突，像是：
- 準備開始下一個開發週期的新功能，但不影響目前週期開發工作，該怎麼處理？
- 某次更新意外造成系統維運問題，團隊有辦法快速恢復正確的版本，降低服務停擺所造成的傷害嗎？
- 開發工作尚未完成，臨時被要求馬上解決某個Bug，您有辦法快速切換進行處理，並且保留尚未完成的新功能嗎？
- 團隊成員共同開發相關的功能，會修改相同程式碼，您能避免不會彼此影響嗎？
- 程式碼出現問題或不符需求，您能否想起3 個月前程式碼內容，確認當時需求並正確的修復程式？
Git 就是那台神奇的時光機器！除了可以檢視過去變更，也不會影響未來工作。在過往黑暗時代透過檔案與版號進行控制，需要相當多的人力維護程式碼，也經常發生因為人為疏失佈署錯誤版本，而導致維運停擺的情況發生，也因為如此，過往團隊要成為大型專案並不容易。在現代化應用程式開發，分散式版本管理是重要且必要的基礎設施。
版本控制軟體在發展初期多為集中式，透過一個遠端中心伺服器集中管理，每次修改文件時，皆需要從伺服器將檔案簽出(checkout)，修改完成後再將檔案簽入(checkin)。所有檔案紀錄由中心伺服器進行管理，以維持團隊使用一致的程式碼與確保版本正確性。早期的集中式版本管理的缺點在於：
- 文件儲存於遠端伺服器，一旦失去網路連線，將無法使用簽出、簽入、還原、檢視更改紀錄⋯等版本控制相關功能。
- 無法擁有完整隔離的開發環境，當團隊協作時容易造成衝突，開發人員花費大量時間解決衝突的程式碼。
- 承上，團隊協作可能發生互相等待情況：等待前一位開發人員完成修復工作後，才能進行後續其他開發工作。
- 因應測試需求之多環境(Dev、UAT、Prod)，集中式版本管理可能需要較多的儲存庫或人力才能達成，必須仰賴團隊制定標準流程進行。
- 若沒有其他備份，遠端伺服器若發生毀損且無法復原之災難，所有紀錄可能隨之消失。
何謂『分散式』版本控制軟體？它提供軟體開發人員在參與相同專案時，可以不需要在相同的網路環境下工作。在初期從遠端伺服器複製一份完整的程式碼與其歷史紀錄至本地電腦，即使無法連接網路，仍不影響開發工作，待後續透過其他機制與遠端伺服器進行同步作業。
然而，Git 並不是唯一的版本控制軟體，為什麼要使用Git ？
- 開放原始碼：Git 為開放原始碼，且已經成為版本控制實際標準。
- 免費且強大社群支援：企業與團隊的需求在於軟體穩定與豐富的技術支援，任何人皆不希望遇到無法支援或處理的問題而影響維運。
- 分支管理：分支可以建構獨立的開發環境，分支原則可以確保團隊執行一致的工作流程與防止錯誤的操作。經過審核的合併可以大幅提升軟體品質，確保安全的持續整合執行。
- 速度快且檔案體積小。
- 分散式管理：本機上皆有各自的副本，達到同時開發需求，大幅提升開發效率。
- 內建整合：多種GUI 工具可以使用，降低使用門檻。多數開發工具皆有內建的Git 支援，大幅簡化日常工作流程。
Git 檔案運作原理
在開始使用Git 之前， 我們先簡單說明Git 版本管理運作原理。Git 在檔案管理部分成三個部分：Unstaging、Staging 與Repository。Git 會追蹤Staging 區域內的檔案變更，並建立index 後，以一個版本的形式提交至Repository 內。若本地工作目錄內的檔案未加入Staging 區域 (即為Unstaging)，則不會進行追蹤，也不影響提交。
初始化Git 設定後，您需要在本地工作目錄加入 (Git Add) 檔案至Staging區域進行追蹤。一旦Staging 內檔案已變更，Git 會顯示變更狀態與其內容。開發人員確認無誤後，再進行提交 (Git Commit) 作業。
Git 會持續追蹤檔案變更。一般來說，開發人員會對於已提交的檔案進行修改。
Git 偵測檔案更動，會將變更部分的內容標註為可提交狀態。並在Staged 區域進行追蹤。在尚未提交之前，若有更多的檔案更動，變更部分仍會繼續被標註為可提交狀態，即列為同一個提交。
本文節錄自《動手學GitHub！現代人不能不知道的協同合作平台》，由深智數位授權轉載。
