閱讀英文

共用方式為


什麼是 Git?

Git 已成為版本控制的全球標準。 那麼,到底是什麼?

Git 是分散式版本控制系統,這表示專案的本機複本是完整的版本控制存放庫。 這些功能完整的本機存放庫可讓您輕鬆地離線或遠端工作。 開發人員在本機認可其工作,然後同步處理其存放庫複本與伺服器上的複本。 此種模式與集中式版本控制不同。集中式版本控制的用戶端必須與伺服器同步程式碼,之後才能建立新版本的程式碼。

Git 的彈性和受歡迎程度使其成為任何小組的絕佳選擇。 許多開發人員和大學畢業生已經知道如何使用 Git。 Git 的使用者社群已建立資源來訓練開發人員,而 Git 的受歡迎程度可讓您在需要時輕鬆取得協助。 幾乎每個開發環境都有 Git 支援,以及在每個主要作業系統上實作的 Git 命令行工具。

Git 基礎 \(英文\)

每次儲存工作時,Git 都會建立認可。 認可是某個時間點所有檔案的快照集。 如果檔案尚未從一個認可變更為下一個認可,Git 會使用先前儲存的檔案。 此設計與其他系統不同,這些系統會儲存檔案的初始版本,並保留一段時間的差異記錄。

Linear graph of development in Git

認可會建立其他認可的連結,形成開發歷程記錄的圖表。 可以將程式代碼還原為先前的認可、檢查檔案從一個認可變更為下一個認可的方式,以及檢閱變更的位置和時間等資訊。 認可會透過認可內容的唯一密碼編譯哈希,在 Git 中識別認可。 由於一切都經過哈希處理,因此在未偵測 Git 的情況下,不可能進行變更、遺失資訊或損毀的檔案。

分支

每個開發人員都會將變更儲存至自己的本機程式代碼存放庫。 因此,根據相同的認可,可能會有許多不同的變更。 Git 提供用來隔離變更的工具,稍後將它們合併回一起。 分支是進行中工作的輕量型指標,可管理此分隔。 在分支中建立的工作完成後,即可將其合併回小組的主要(或主幹)分支。

Commits on a branch

檔案和認可

Git 中的檔案有三種狀態之一:已修改、暫存或認可。 第一次修改檔案時,變更只存在於工作目錄中。 它們還不是認可或開發歷程記錄的一部分。 開發人員必須 暫存 要包含在認可中的已變更檔案。 暫存區域包含下一個認可中包含的所有變更。 一旦開發人員滿意暫存的檔案,檔案就會封裝為 認可 ,並顯示描述變更的訊息。 此認可會成為開發歷程記錄的一部分。

file_status_lifecycle-2

預備可讓開發人員挑選要儲存在認可中的檔案變更,以便將大型變更細分成一系列較小的認可。 藉由減少認可範圍,更容易檢閱認可歷程記錄來尋找特定的檔案變更。

Git 的優點

Git 的優點有很多。

同時開發

每個人都有自己的本機程式代碼複本,而且可以在自己的分支上同時運作。 Git 會離線運作,因為幾乎每個作業都是本機作業。

更快速的版本

分支允許彈性且同時進行開發。 主要分支包含您發行的穩定、高品質程序代碼。 功能分支包含進行中的工作,這些工作會在完成時合併到主要分支中。 藉由將發行分支與進行中的開發區隔開,更容易管理穩定程序代碼,並更快速地寄送更新。

內建整合

由於其受歡迎程度,Git 會整合到大部分的工具和產品中。 每個主要 IDE 都有內建的 Git 支援,許多工具都支援持續整合、持續部署、自動化測試、工作專案追蹤、計量和報告功能與 Git 整合。 這項整合可簡化日常工作流程。

強大的社群支援

Git 是開放原始碼,已成為版本控制的事實標準。 小組無法利用工具和資源。 相較於其他版本控制系統,Git 社群支援的數量可讓您在需要時輕鬆取得協助。

Git 可與任何小組合作

使用 Git 搭配原始程式碼管理工具可藉由鼓勵共同作業、強制執行原則、自動化程式,以及改善工作的可見度和可追蹤性,來提升小組的生產力。 小組可以解決個別工具的版本控制、工作項目追蹤,以及持續整合和部署。 或者,他們可以選擇一個解決方案,例如 GitHubAzure DevOps ,以一個位置支援所有這些工作。

提取要求

使用 提取要求 來討論小組的程式碼變更,再將它們合併至主要分支。 提取要求中的討論對於確保程式碼品質並提升整個小組的知識非常重要。 GitHub 和 Azure DevOps 等平臺提供豐富的提取要求體驗,讓開發人員可以瀏覽檔案變更、留下批注、檢查認可、檢視組建,以及投票核准程序代碼。

分支原則

Teams 可以設定 GitHub 和 Azure DevOps,以在整個小組中強制執行一致的工作流程和程式。 他們可以設定 分支原則 ,以確保提取要求符合完成前的需求。 分支原則可藉由防止直接推送、要求檢閱者,以及確保全新組建來保護重要的分支。

下一步

安裝和設定 Git