Git 已成為版本控制的全球標準。 那麼它到底是什麼呢？
Git是一個分散式版本控制系統，也就是說專案的本機克隆是一個完整的版本控制儲存庫。 這些功能完整的本機存放庫可讓您輕鬆地離線或遠端工作。 開發人員在本機提交工作，然後將其存放庫副本與伺服器上的副本同步。 此範例不同於集中式版本控制，在集中式版本控制中，用戶端必須先將程式碼與伺服器同步，然後才能建立新版本的程式碼。
Git 的靈活性和受歡迎程度使其成為任何團隊的絕佳選擇。 許多開發人員和大學畢業生已經知道如何使用 Git。 Git 的使用者社群已經創建了資源來培訓開發人員，而 Git 的受歡迎程度使得在需要時可以輕鬆獲得協助。 幾乎每個開發環境都有 Git 支援，並在每個主要作業系統上實作 Git 命令列工具。
Git 基本概念
每次儲存工作時，Git 都會建立一個 Commit。 版本控制系統中的提交是某個時間點所有檔案的快照。 如果一個檔案在兩次提交之間沒有變更，Git 會使用先前儲存的檔案。 此設計不同於其他系統，這些系統會儲存檔案的初始版本，並保留一段時間內的差異記錄。
提交會建立指向其他提交的連結，形成開發歷程的圖形。 可以將程式碼還原為先前的提交，檢查檔案如何從一個提交變更為下一個提交，並查看更改的位置和時間等資訊。 提交在 Git 中由提交內容的唯一加密哈希來識別。 因為一切都是雜湊的，所以在沒有 Git 偵測到的情況下，不可能進行變更、遺失資訊或損壞檔案。
分支
每個開發人員都會將變更儲存到自己的本機程式碼儲存庫。 因此，基於同一提交，可能會有許多不同的變更。 Git 提供了用於隔離變更並稍後將它們合併回一起的工具。 分支是指向尚未完成的工作的輕量型指示器，用來管理這種分離。 在分支中建立的工作完成後，可以將其合併回團隊的主要（或主幹）分支。
檔案和提交
Git 中的檔案處於三種狀態之一：已修改、暫存或已認可。 第一次修改檔案時，變更只會存在於工作目錄中。 它們尚未是認可或開發歷程記錄的一部分。 開發人員必須 暫存 變更的檔案，才能將其包含在提交中。 暫存區包含在下一次提交中的所有變更。 一旦開發人員對暫存檔案感到滿意，檔案就會封裝為 提交 ，並附上描述變更內容的訊息。 此提交會成為開發歷程記錄的一部分。
暫存可讓開發人員選擇要在提交中儲存哪些檔案變更，以便將大型變更分解為一系列較小的提交。 透過縮小提交範圍，可以更輕鬆地檢閱提交紀錄以尋找特定的檔案變更。
Git 的優點
Git 的好處很多。
同時開發
每個人都有自己的本地代碼副本，並且可以在自己的分支上同時工作。 Git 可以離線工作，因為幾乎每個操作都是本地的。
更快的發布
分支允許靈活和同步開發。 主分支包含穩定、高品質的程式碼，您可以從中釋放這些程式碼。 功能分支包含進行中的工作，這些工作會在完成時合併到主要分支中。 透過將發行分支與進行中的開發分開，可以更輕鬆地管理穩定程式碼並更快地交付更新。
內建整合
由於其受歡迎程度，Git 整合到大多數工具和產品中。 每個主要的 IDE 都有內建的 Git 支援，許多工具都支援持續整合、持續部署、自動化測試、工作專案追蹤、計量和報告功能與 Git 的整合。 這種整合簡化了日常工作流程。
強大的社區支持
Git 是開源的，並且已成為版本控制的事實上的標準。 可供團隊利用的工具和資源不勝枚舉。 與其他版本控制系統相比，Git 的社群支援量使得在需要時可以輕鬆獲得協助。
Git 可與任何團隊合作
將 Git 與原始程式碼管理工具搭配使用，可鼓勵協作、執行原則、自動化流程，以及提高工作的可見性和可追溯性，從而提高團隊的生產力。 小組可以選擇個別工具來進行版本控制、工作專案追蹤，以及持續整合和部署。 或者，他們可以選擇 GitHub 或 Azure DevOps 等解決方案，在一個位置支援所有這些工作。
提取要求
使用 提取請求 與團隊討論程式碼變更，然後再將其合併到主分支中。 提取請求中的討論對於確保程式碼品質和增加整個團隊的知識非常寶貴。 GitHub 和 Azure DevOps 等平臺提供豐富的提取要求體驗，開發人員可以在其中瀏覽檔案變更、留下批注、檢查認可、檢視組建，以及投票核准程式碼。
分支政策
小組可以設定 GitHub 和 Azure DevOps，以在整個小組中強制執行一致的工作流程和程式。 他們可以設定 分支原則 ，以確保提取請求在完成之前符合需求。 分支策略透過防止直接推送、要求檢閱者並確保乾淨的建置來保護重要的分支。