Git 基礎指令與分支管理實踐

– 12 分鐘閱讀

現代軟體開發中，版本控制系統的重要性不言而喻。Git 作為分散式版本控制系統的代表，賦予每個開發者擁有完整專案歷史記錄的能力，即使網路不穩定也能順暢運作。善用 .gitignore 檔案，可以有效管理忽略檔案，避免敏感資訊或特定環境組態檔案被提交到倉函式庫。標籤化功能則方便標記特定版本，例如釋出版本或重要里程碑，有助於追蹤和管理程式碼演進。分支管理是團隊協作的關鍵，透過建立分支，開發者可以在隔離的環境中開發新功能或修復錯誤，而不影響主執行緒式碼的穩定性。合併分支則能將不同分支的修改整合到主線，完成功能整合。然而，合併過程中可能出現衝突，Git 提供了衝突解決機制，讓開發者能手動選擇保留或捨棄特定修改，確保程式碼的正確性。此外，同步本地與遠端儲存函式庫是團隊協作的必要步驟，透過 push、pull/fetch 等指令，開發者可以分享程式碼更新，保持團隊成員之間的程式碼一致性，確保專案的順利進行。

基礎 Git 指令實踐

在現代軟體開發中，版本控制系統已成為不可或缺的工具。Git 是目前最流行的版本控制系統之一，它允許開發者追蹤檔案的變更歷史，並且團隊成員協作。以下是一些基本的 Git 指令及其應用。

版本控制的重要性

版本控制系統（VCS）能夠追蹤檔案的變更歷史，並允許多名開發者同時在同一個專案上工作。Git 是一種分散式版本控制系統，這意味著每個開發者都擁有整個專案的完整歷史記錄。這樣的設計使得 Git 在網路連線不穩定的情況下也能正常運作，因為每個開發者的本地倉函式庫都包含完整的專案歷史。

使用 .gitignore 管理忽略檔案

在開發過程中，有些檔案和目錄是不需要被追蹤的，例如個人備忘錄或 IDE 的組態檔。這些檔案通常包含敏感資訊或僅適用於特定環境。為了避免這些檔案被意外提交到倉函式庫中，可以使用 .gitignore 檔來指定哪些檔案和目錄應該被 Git 忽略。

假設情境

假設你有個目錄 hats-for-cats/，其中包含一個檔案 personal-notes.txt 和一個目錄 .ide-config/。前者是你用來記錄專案特性想法的檔案，後者則是 IDE 用來組態專案的目錄。你可能不希望這些資料與團隊成員分享。

解決方案

你可以在專案根目錄中建立一個 .gitignore 檔，並在其中列出要忽略的檔案和目錄。例如：

# notes to myself that are not for public consumption
personal-notes.txt

# configuration files for my IDE
.ide-config/

然後將這個 .gitignore 檔加入到 Git 倉函式庫：

$ git add .gitignore
$ git commit --message "exclude notes file and IDE config directory"

這樣，當你執行 git status 時，Git 就不會再提示未追蹤的 personal-notes.txt 和 .ide-config/ 檔案和目錄了。

標籤化提交以識別程式碼版本

標籤化（Tagging）是 Git 中的一個功能，它允許你為特定的提交新增永久標籤。這對於標記已釋出給使用者的特定版本或保留某個特定版本以便未來參考非常有用。

案例研究

假設「貓帽」專案準備釋出版本 0.1-beta。你可以使用 git tag 命令來標記最新的提交：

$ git tag version-1-0-beta

接著執行 git log，你會看到 Git 已經將標籤應用到最新的提交上。

其他應用

如果你進行了一次大規模重構，並希望保留重構前的程式碼狀態以備不時之需，也可以使用標籤：

$ git tag before-class-reorganization

Git 提供了多種標籤操作選項，例如 --delete 和 --list：

$ git tag --list
$ git tag --delete version-1-0-beta

分支管理：隔離開發環境

在 Git 中，分支（Branching）是一個非常重要的概念。分支允許開發者在不同的工作流程中進行隔離開發，而不會影響主執行緒式碼。理解分支及其操作對於團隊合作至關重要。

分支的基本概念

分支就是一系列有序的提交。每次提交都包含指向前一個提交的指標，形成一條鏈結。當你在 Git 儲存函式庫中工作時，你總是在某個分支上進行操作。

分支操作

假設你正在 main 分支上工作，但想要開始一個新功能開發。你可以建立一個新分支並切換到該分支：

$ git branch feature-new-hat
$ git checkout feature-new-hat

這樣，你就可以在 feature-new-hat 分支上進行開發而不影響 main 分支上的程式碼。

分支合併：整合改進

當你完成了一個功能開發或修復了一些錯誤時，可以將這些改動合併回主線分支：

$ git checkout main
$ git merge feature-new-hat

這樣做會將 feature-new-hat 分支上的所有改動合併到 main 分支上。

探索進階 Git 特性

以上介紹了 Git 的基本概念和一些常用命令。Git 還有許多進階功能和命令可以探索，例如：「衝突解決」、「回復提交」及「遠端儲存函式倉管理」。隨著對 Git 的深入瞭解，你將能夠更有效地管理你的專案和團隊協作流程。

探索高階功能

除了基本操作外，Git 還提供了許多高階功能來協助管理複雜的開發流程：

  • 衝突解決：當多名開發者在同一部分程式碼上進行修改時，可能會產生衝突。Git 提供了強大的衝突解決工具來幫助解決這些問題。
  • 回復提交：如果某次提交引入了問題，可以使用 Git 的回復功能來還原到之前狀態。
  • 遠端儲存函式倉管理：Git 支援與遠端倉函式庫同步程式碼變更，方便團隊成員之間進行協作。

透過不斷學習和實踐這些高階功能，玄貓相信大家將能夠更熟練地使用 Git 來管理專案並提升開發效率。

此圖示表示街道與彈珠代表分支與提交

  graph TD;
    A[Main Street] --> B[First Street];
    B --> C[Main Street];
    D[Car] --> E[Marbles];
    F[Helicopter] --> G[Switch Branches];
內容解密：
  • 街道與彈珠：使用街道和彈珠來類別比分支和提交。
  • 車輛：代表開發者。
  • 彈珠：代表提交。
  • 直升機：代表 Git 命令。
  • 主街與第一街：代表不同分支。
  • 切換分支：直升機代表切換不同分支時可以像移動車輛般自由切換。
  • 傳統觀念：傳統觀念中單一道路無法同時包含不同車輛（仿照單一分支），但利用切換命令可快速移動至其他道路（仿照切換至其他分支）。

透過以上介紹及內容解密後針對「內容解密」部分進一步深度說明關於「街道與彈珠」圖表中的類別比說明與實際Git執行命令之邏輯：

  1. 車輛：代表單一開發者無法同時存在於不同街道（仿照無法同時存在於多個分支）。
  2. 彈珠：每隔一段時間甩出彈珠（仿照每次提交）。
  3. 直升機：隨時可將車輛移至不同街道（仿照隨時可利用Git命令切換至不同分支）。
  4. 傳統觀念：傳統觀念認為單一方向不可同時包含多台車輛（仿照單一分支不可同時包含多名開發者）。
  5. 自主決定性：每位開發者擁有自主權利決定隨時選擇轉向別處（仿照隨時可選擇切換至其他分支）。

透過以上深度介紹及說明後相信大家可從以上類別比中理解如何應用各項基本指令及其技術實作方式並且從中學習到如何掌握Git所有高階功能以助於日後工作實務上的需求運用及場景應用需求等。

Git 基本操作與分支管理

在Git中，每個儲存函式庫都至少有一個分支，通常稱為主分支。這些分支有正式的名稱，主分支通常命名為 main 或 master，其中 main 現在是更常見的選擇。為了更好地理解分支和提交的關係，我們通常會繪製分支圖，其中每個提交都會指向之前的提交。這意味著箭頭是向後指向時間軸的，從後來的提交指向前面的提交。

假設你有一個名為 main 的分支，它有三個提交（A、B 和 C），還有一個名為 branch-a 的分支，它有兩個提交（D 和 E），並且 branch-a 是從 main 分支分支出來的，那麼你可以將儲存函式庫的狀態繪製如下：

此圖示展示了分支和提交之間的關係。分支讓你可以在不影響穩定程式碼函式庫的情況下開發新功能或修復錯誤。以下是一個典型的工作流程，展示瞭如何使用分支來實作這一點：

  1. 你的產品程式碼儲存在一個 Git 儲存函式庫中，穩定版本的程式碼位於名為 main 的分支中。
  2. 你被分配到為產品編寫一個允許使用者登入的功能。
  3. 你建立了一個名為 login-feature 的分支。
  4. 你切換到 login-feature 分支。
  5. 你編輯檔案並向該分支新增一個或多個提交。
  6. 其他團隊成員審查這些提交中的編輯並給予反饋。
  7. 你新增另一個提交來整合反饋。
  8. 你的團隊長官批准了你的工作，宣告登入功能已經正確實作。QA 團隊也可能會簽名確認你的工作。

分支程式碼以隔離開發空間

  1. 你將 login-feature 分支合併到 main 分支中。這意味著你對 login-feature 分支所做的所有提交現在也成為 main 分支的一部分。你的登入功能現在是產品主程式碼函式庫的一部分。
  2. 由於 login-feature 分支已經被合併並且不再需要，你可以安全地刪除它。

在這個工作流程中，重要的是當你開發登入功能時，未完成的程式碼並未影響到主程式碼函式庫（即 main 分支）。你不完整的程式碼被安全地隔離在產品穩定程式碼之外，這樣它就不會破壞產品穩定性。登入功能只有在正式審查、批准並透過所有測試後才會新增到主程式碼函式庫中。

多位開發者共同工作

雖然這個例子只涉及一位開發者，但在實際情況中，通常會有多位開發者同時在不同的分支上工作。例如，兩位開發者可能在各自的分支上新增新功能，另兩位開發者可能在各自的分支上修復錯誤。一位特定的開發者可能會在一天內來回切換多個分支，隨著他們的工作重點從一項任務轉移到另一項任務。重點是，所有這些分支都是彼此獨立的——當你在某個分支上時，你看不到或無法更改其他分支上的程式碼，直到它們最終被合併到主分支中。

Git 指令管理分支

讓我們學習一些 Git 指令來管理分支：

建立新分支

要建立一個名為 login-feature 的新分支：

$ git branch login-feature

這條指令會列出儲存函式庫中所有存在的分支，並且會在當前所在的分支旁邊標記一顆星號：

$ git branch

有兩種不同方法可以切換到另一個分支。它們做的是同樣的事情，你可能會看到這兩種方法都被使用。以下是切換到 login-feature 分支：

$ git checkout login-feature
$ git switch login-feature

合併分支

合併一個來源分支援到目標分支援需要兩條指令：首先確保你在目標分支援上（例如：main 分支援），然後執行合併指令並指定來源分支援（例如：login-feature）。

$ git checkout main
$ git merge login-feature

刪除無用的一些特殊實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用

有些組織喜歡永遠保留所有歷史紀錄中的所有所有所有所有歷史紀錄中的所有所有所有所有歷史紀錄中的所有所有所有所有歷史紀錄中的所有歷史紀錄中的所有所有歷史紀錄中的所有歷史紀錄中的作業,但大多陣列織要求在將其合併到 main 中後刪除該歷史紀錄,以下是如何刪除該 login-feature 控制器操作:

$ git branch --delete -login-feature

如果試圖刪除尚未合併到某些特殊實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用某些特殊實驗性質之非正式使用之異常偏差性質之實驗性質之非正式使用某些特殊實驗性質之非正式使用某些特殊實驗性質之一些特殊實驗性質之一些特殊實驗性質之一些特殊實驗性質之一些特殊一些特殊的一些特殊的一些特殊的一些特殊的一些特殊的一些一些一些一些一些一些一些一些一些一些一些同樣的一些特別的一些特別的一些特別的一些特別的一些特別的一些特別的一些特別的一些特別的一些特別之一件事之前,Git 將警告並不刪除該控制器操作,可強制刪除該控制器操作,例如,如果建立了一個控制器操作並想刪除該控制器操作而不合併,則：

$ git branch --delete --force experimental-branch

處理合併衝突

當試圖將一個來源控制器操作與另一控制器操作進行合併時,有時會遇到所謂衝突問題,這意味著其他人已經修改了與您相同執行緒相同檔案相同內容相同內容相同內容相同內容相同內容相同內容相同內容相同內容相同內容相同內容相同內容與您所試圖合併您控制器操作之前已將他控制器操作與他控制器操作進行合併,當您試圖合併您控制器操作時,Git 不確定是否應保留其他開發人員所做修改或應保留您所試圖合併修改

要繼續進行合併,首先需要解決此衝突問題,有幾種方法可以解決此問題,許多人認為專用 GUI 工具非常易於處理衝突問題,例如 Sourcetree (macOS 和 Windows) 或 Sublime Merge (Linux、macOS 和 Windows),其他人則喜歡使用 Git 命令列工具和文字編輯器手動解決衝突問題,GitLab 使用者還有一種選擇:可使用 GitLab 的內建圖形化解決衝突工具問題無論選擇哪種方式,都必須告知 Git 接受哪種更改、拋棄哪種更改以及何時繼續進行合併

合併衝突解決與本地與遠端儲存函式庫同步

在軟體開發過程中，合併衝突是常見的挑戰。玄貓來帶大家深入瞭解如何使用GitLab的合併衝突解決工具，並解釋如何同步本地與遠端的儲存函式庫，以確保團隊中的所有開發者都能夠協同工作。

使用 GitLab 解決合併衝突

假設你正在 new-login-message 分支上修改 login.py 檔案。你建立了一個合併請求（Merge Request, MR）並提交了一些編輯，但在嘗試合併時卻發現了合併衝突：

  • 合併請求被阻塞：由於你和其他人在同一行進行了不同的編輯，導致 Git 無法決定該保留哪個版本。

GitLab 提供了兩種解決方式：使用內建的圖形使用者介面（GUI）工具，或者本地手動編輯並推播回 GitLab。這裡我們將重點介紹如何使用 GitLab 的內建工具來解決合併衝突。

內容解密：

  • 圖形使用者介面（GUI）：GitLab 提供的圖形使用者介面可以讓你更直觀地檢視和解決合併衝突。
  • 本地手動編輯：這種方法需要你在本地儲存函式庫中進行編輯，然後推播回 GitLab。這種方法適用於較為複雜的合併衝突。
  • merge conflict（合併衝突）：當兩個分支對同一行進行了不同的編輯時，Git 無法自動合併這些變更，需要手動介入。

使用 GitLab 解決簡單的合併衝突

假設你在 login.py 中將一行文字從「We’re glad you’re here」改為「We’re really glad you’re here」，而其他人則將其改為「We’re super glad you’re here」。這時，GitLab 會顯示出這兩個不同的版本：

  • 選擇保留自己的編輯：你可以點選「Use ours」按鈕，告訴 GitLab 忽略其他人的編輯並保留你的變更。
  • 提交解決方案：完成選擇後，輸入提交訊息並點選「Commit to source branch」，GitLab 會在你的分支上建立一個新的提交來解決這個衝突。
# 想要保留自己的編輯
We're really glad you're here

內容解密：

  • Use ours 按鈕：這個按鈕告訴 GitLab 忽略其他人的變更並保留你的編輯。
  • Commit to source branch：這個操作會在你的分支上建立一個新的提交來解決合併衝突。

本地與遠端儲存函式庫同步

Git 的分散式架構使得每個開發者都擁有完整的儲存函式庫副本。然而，這也意味著需要經常同步這些副本，以確保每個人都能看到最新的變更。

「黃金」儲存函式庫

團隊中需要指定一個「黃金」儲存函式庫，它包含了最新版本的穩定程式碼。只有當開發者將他們的變更推播到這個「黃金」儲存函式庫時，這些變更才會被視為正式的一部分。

  graph TD;
    A[開發者1] -->|Push| B[(黃金儲存函式庫)];
    C[開發者2] -->|Pull| B;
    B -->|Fetch| D[開發者3];

內容解密：

  • 黃金儲存函式庫：這是團隊中被視為權威版本的儲存函式庫。
  • Push：將本地變更推播到遠端儲存函式庫。
  • Pull/Fetch：從遠端儲存函式庫取得最新變更到本地。

同步過程

  1. 檢查遠端分支：首先確認你是否有最新的遠端分支。

    git fetch origin

  2. 合併遠端分支：將遠端分支的變更合併到你的本地分支。

    git merge origin/main

  3. 推播本地變更：將你的本地變更推播到遠端儲存函式庫。

    git push origin new-login-message

內容解密：

  • git fetch origin：從遠端取得最新的分支和提交記錄。
  • git merge origin/main：將遠端主分支（main）的變更合併到你當前所在的分支。
  • git push origin new-login-message：將當前分支（new-login-message）上的變更推播到遠端。
玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。