Git 差異比較與版本控制技巧

– 54 分鐘閱讀

在版本控制系統中，比較不同版本程式碼的差異至關重要。Git 提供了強大的差異比較演算法和工具，讓開發者能輕鬆追蹤程式碼的變更。理解 Git 的差異比較機制，能幫助我們更有效地進行程式碼審查、除錯和版本控制。此外，掌握 git bisect、git stash 和 Git Submodule 等技巧，能進一步提升開發效率和程式碼品質。git bisect 幫助我們快速定位引入錯誤的提交，git stash 能暫存未完成的修改，而 Git Submodule 則能有效管理專案的外部依賴。這些工具的結合，讓 Git 成為一個強大且靈活的版本控制系統。

Git 如何生成差異比較結果

Git 使用了一種叫做 “diff” 的演算法來計算兩個版本之間的差異。這個演算法會比較兩個版本的內容，然後產生一個描述兩個版本之間差異的結果。

以下是 Git 中 diff 演算法的基本步驟：

  1. 檔案比較：Git 首先會比較兩個版本的檔案內容，包括檔案的新增、刪除和修改。
  2. 區塊比較：如果發現檔案內容有所不同，Git 會進一步比較檔案中的區塊（例如，函式、類別等），以確定哪些區塊有所變化。
  3. 行比較：如果發現區塊有所不同，Git 會進一步比較檔案中的行，以確定哪些行有所變化。
  4. 字元比較：如果發現行有所不同，Git 會進一步比較檔案中的字元，以確定哪些字元有所變化。

這個過程會不斷重複，直到 Git 確定了兩個版本之間的所有差異。然後，Git 會產生一個描述這些差異的結果，這就是我們所看到的 diff 輸出。

以下是一個簡單的範例，展示了 Git 如何生成差異比較結果：

假設我們有一個檔案 example.txt，其內容如下：

Line 1
Line 2
Line 3

現在，我們修改了這個檔案，新增了一行 Line 4。新的檔案內容如下：

Line 1
Line 2
Line 3
Line 4

如果我們使用 Git 的 diff 演算法來比較這兩個版本，我們會得到以下結果：

diff --git a/example.txt b/example.txt
index 1234567..8901234 100644
---
 a/example.txt
+++ b/example.txt
@@ -1,3 +1,4 @@
 Line 1
 Line 2
 Line 3
+Line 4

這個結果顯示了兩個版本之間的差異，即新增了一行 Line 4。

Git 的 diff 演算法是一種非常強大的工具，它可以幫助我們瞭解兩個版本之間的差異，並且可以用於各種不同的應用場景。

Plantuml 圖表解讀 Git Diff 流程

以下使用 Plantuml 流程圖，更清晰地展現 git diff 的比較過程：

內容解密：

這張流程圖展示了 git diff 的不同使用方式以及它們比較的物件。例如，git diff 比較工作目錄和索引區，git diff HEAD 比較工作目錄和最新提交，git diff --cached 比較索引區和最新提交，而 git diff Commit1 Commit2 則比較兩次提交。

透過理解 git diff 的輸出和掌握這些實用技巧，你可以更有效率地追蹤程式碼變更，提升開發效率。

尋找提交

良好的版本控制系統的一部分是它提供的「考古」和調查儲存函式庫的支援。 Git 提供了多種機制來幫助您在儲存函式庫中找到符合特定條件的提交。

在本文中，我們將教您一些可以用來搜尋儲存函式庫提交歷史記錄的技巧。 我們將重點介紹三種可以利用的方法來搜尋儲存函式庫的提交歷史記錄。 第一種方法非常強大，有助於找到滿足搜尋條件的單個提交。 第二種方法提供有關將變更引入檔案的提交的資訊，第三種方法使用帶有常規 git log 命令的特定搜尋變體。

除了在使用 Git 處理提交時為您提供搜尋技能外，本文還為下一篇文章提供了引子，我們將在其中探討更改找到的提交的主題。

使用 git bisect

git bisect 命令是一個功能強大的工具，可用於根據基本上任意的搜尋條件隔離特定提交。 它非常適合您發現某些「錯誤」或「不良」影響您的儲存函式庫並且您知道程式碼以前沒問題的時候。 例如，假設您正在處理 Linux 核心並且測試啟動失敗，但您肯定啟動在之前的某個時間有效，可能是前一週或之前的版本標籤。 在這種情況下，您的儲存函式庫已從已知的「良好」狀態轉變為已知的「不良」狀態。

但是這種轉變是什麼時候發生的呢？ 哪個提交導致它壞了？ 這正是 git bisect 旨在幫助您回答的問題。

唯一的真正搜尋要求是，給定儲存函式庫的已簽出狀態，您能夠確定它是否滿足您的搜尋要求。 在這種情況下，您必須能夠回答這個問題：「已簽出核心的版本是否可以建置和啟動？」 您還必須在開始之前知道提交的良好版本和不良版本，以便限制搜尋範圍。 簡而言之，您不應在搜尋要求中提供不正確的提交範圍。

git bisect 命令在執行時內部應用二分搜尋演算法； 該命令系統地在一端以良好行為為界，另一端以不良行為為界的遞減範圍內選擇新的提交。 最終，這個縮小的範圍將精確指出引入錯誤行為的那個提交。 下圖提供此概念的總體檢視。

圖示：Git bisect 範圍修訂概念

在 bisect 模式下，您無需執行任何操作，只需提供初始的良好提交和不良提交，然後重複回答問題：「這個版本有效嗎？」

首先，您需要識別一個好的提交和一個壞的提交。 實際上，壞版本通常是您目前的 HEAD，因為那是您突然發現某些錯誤或被分配修復錯誤時正在處理的地方。

尋找初始的良好版本可能有點困難，因為它通常隱藏在您的歷史記錄中的某個地方。 您可能可以命名或猜測儲存函式庫歷史記錄中您知道可以正常工作的某個版本。 這可能是標記的版本，例如 v2.6.25，或者您主分支上 100 個修訂版本之前的某個提交，例如 main100。 理想情況下，它接近您的壞提交（main25 比 main~100 好），並且不會埋藏在過去太久。 無論如何，您需要知道或能夠驗證它實際上是一個好的提交。

開始 git bisect 過程之前，必須確保您從乾淨的工作目錄開始，並且您的工作目錄指向專案的頂級目錄。 該過程必然會調整您的工作目錄以包含儲存函式庫的各種版本。 從髒的工作空間開始就是自找麻煩； 您的工作目錄很容易丟失。 如果您有任何工作變更，您可以將它們儲存起來。

內容解密：

這段文字解釋了 Git 如何有效地生成差異比較結果，並且 SVN 等傳統版本控制系統進行了比較。Git 的核心優勢在於其儲存的是檔案的完整快照，而不是像 SVN 那樣儲存差異。這使得 Git 在計算差異時可以直接比較兩個快照，而無需遍歷所有中間版本，從而顯著提高了效率。

此外，本文還介紹了 git bisect 命令，這是一個用於定位引入錯誤的特定提交的強大工具。git bisect 使用二分搜尋演算法，透過使用者反覆確認程式碼在特定提交下的狀態（好或壞），逐步縮小搜尋範圍，最終精確找到導致問題的提交。


在軟體開發過程中，找出程式碼錯誤的根源往往是一項耗時費力的工作。尤其在大型專案中，程式碼的修改歷史錯綜複雜，要精確定位問題的引入點更是難上加難。此時，`git bisect` 就成為了你的得力助手。

`git bisect` 是一種二分搜尋法，它能幫助你快速定位哪一次提交引入了錯誤。它會在你的程式碼歷史中進行二分搜尋，每次將搜尋範圍縮小一半，直到找到問題的根源。

##  實戰演練：在 Linux 核心程式碼函式庫中使用 git bisect

以下，玄貓將以 Linux 核心程式碼函式庫為例，示範如何使用 `git bisect` 進行除錯。

首先，進入程式碼函式庫目錄，並啟動 `git bisect`：

```bash
$ cd linux-2.6
$ git bisect start

啟動後，Git 會進入 bisect 模式，並使用一個分離的 HEAD 指標來管理當前簽出的版本。這個分離的 HEAD 就像一個匿名分支，可以讓你自由地在程式碼歷史中移動。

接下來，告訴 Git 哪個提交是壞的（包含錯誤的版本）和哪個提交是好的（不包含錯誤的版本）。通常，目前的版本是壞的，可以直接使用 HEAD：

$ git bisect bad
$ git bisect good v2.6.27

設定好壞版本後，Git 就會開始二分搜尋。它會簽出一個介於好版本和壞版本之間的提交，並詢問你這個版本是好的還是壞的。

Bisecting: 3857 revisions left to test after this
[cf2fa66055d718ae13e62451bb546505f63906a2] Merge branch 'for_linus'...

假設這個版本是好的：

$ git bisect good

Git 會繼續搜尋，並將範圍縮小一半：

Bisecting: 1939 revisions left to test after this
[2be508d847392e431759e370d21cea9412848758] Merge git://git.infradead.org/mtd-2.6

重複這個過程，直到 Git 找到第一個壞的提交：

$ git bisect good
...
$ git bisect bad
...
$ git bisect good
fa340d9c050e78fb21a142b617304214ae5e0c2d is first bad commit

自動化 bisect：使用 git bisect run

除了手動測試每個版本，你還可以透過 git bisect run 自動化這個過程。你需要提供一個指令碼來判斷每個版本是好是壞。指令碼的傳回值決定了版本의狀態：0 表示好，非 0 表示壞。

$ git bisect start HEAD v2.6.27
$ git bisect run <command>

<command> 可以是任何可以執行並傳回狀態碼の命令或指令碼。

內容解密：git bisect 的工作原理

git bisect 使用二分搜尋法在提交歷史中快速定位問題。它會根據你提供의「好」和「壞」版本，逐步縮小搜尋範圍，直到找到第一個引入問題の提交。這個方法效率很高，即使在大型程式碼函式庫中也能快速找到問題根源。

視覺化 bisect 過程

上圖展示了 git bisect 的搜尋過程。從壞版本開始，每次將搜尋範圍縮小一半，直到找到第一個壞の提交。

玄貓の除錯心得

在實際除錯過程中，我發現 git bisect 是一個非常強大的工具。它能幫助我快速定位問題，節省大量の時間和精力。尤其是在處理複雜問題時，git bisect 更能展現其價值。

重構程式碼，最佳化你的Git Bisect流程

在軟體開發過程中，快速定位問題根源至關重要。Git bisect 是一款強大的工具，可以幫助我們有效地找出引入錯誤の特定提交。我將分享一些使用 bisect の技巧和最佳實踐，並著重說明如何編寫更有效のbisect指令碼以及如何利用其他工具輔助定位問題。

編寫高效のBisect指令碼

Bisect 指令碼の效率直接影響問題定位の速度。一個高效の指令碼應該能夠快速判斷程式碼の狀態，並傳回清晰の離開碼。以下是一個示例指令碼，用於檢測系統是否可以無錯誤啟動：

#!/bin/bash

# 執行必要の建置步驟
make

# 嘗試啟動系統
./start_system

# 檢查啟動結果
if [[ $? -eq 0 ]]; then
    # 啟動成功，離開碼為 0
    exit 0
else
    # 啟動失敗，離開碼為非 0 值（1-127，但不能是 125）
    exit 1
fi

內容解密：

這段指令碼首先執行 make 命令進行建置，然後嘗試啟動系統。$? 檢測上一條命令の離開碼，如果啟動成功，離開碼為 0，指令碼也傳回 0；如果啟動失敗，則傳回 1。這樣の設計符合 bisect の要求，可以清晰地指示程式碼狀態。

請記住，指令碼の離開碼必須遵循 bisect の規範：0 表示程式碼狀態良好，1-127（不包括 125）表示程式碼狀態有問題。

完成 bisect 後，使用 git bisect reset 回到原分支：

git bisect reset

這會讓你回到 bisect 開始前的分支狀態。

你可以使用 --term-old 和 --term-new 選項來自定義 bisect の關鍵字，例如：

git bisect start --term-old fast --term-new slow
git bisect fast
git bisect slow

善用Git Blame精準定位

除了 bisect 外，git blame 也是一個非常有用的工具。它可以顯示檔案中每一行の最後修改者和對應の提交："

內容解密：

此段落描述瞭如何善用 Git Blame 進行精準定位。在軟體開發過程中，如果你需要找出某一行程式碼是誰修改以及修改時間，可以使用 Git Blame 進行查詢。此功能對於團隊合作尤其重要，因為它能夠迅速地查明程式碼變更之責任人以及相關資訊，有助於團隊成員之間進行溝通以及追蹤程式碼修改記錄。此外，這項功能也對於程式碼審查、除錯以及維護都具有重要意義，因為它能夠讓開發人員快速地瞭解程式碼修改之原因以及相關背景，有助於提高團隊合作效率以及程式碼品質。


## 重新思考版本控制：修正提交的技巧

在軟體開發過程中，我們經常需要修正先前的提交。可能是發現了程式碼錯誤，或是需要補充更完整的功能。  我將分享一些修正提交的技巧，這些技巧在我過去的專案中非常實用。

首先，我們來看看如何修改最近一次的提交。假設我們有一個名為 `speech.txt` 的檔案，我們想要修改它的內容：

```bash
# 修改 speech.txt 檔案內容
$ git diff
diff --git a/speech.txt b/speech.txt
index 310bcf9..7328a76 100644
---
 a/speech.txt
+++ b/speech.txt
@@ -1,5 +1,5 @@
-Three score and seven years ago
+Four score and seven years ago
our fathers brought forth on this continent,
a new nation, conceived in Liberty,
and dedicated to the proposition
-that all women are created equal.
+that all women and men are created equal.
# 將修改後的檔案加入暫存區
$ git add speech.txt
# 使用 --amend 選項修改最近一次提交
$ git commit --amend

使用 git commit --amend 命令，可以修改最近一次提交的內容和訊息。 這個命令會開啟一個編輯器，允許你修改提交訊息。如果你只想修改提交內容，可以直接關閉編輯器。

內容解密：

上面的 Plantuml 圖表展示了使用 git commit --amend 後的提交歷史。 初始提交 A 被修改後的提交 B 取代。

除了修改最近一次提交，我們還可以使用 git commit --amend --author 修改提交的作者資訊：

$ git commit --amend --author "玄貓（BlackCat） <blackcat@example.com>"

內容解密：

這個命令可以修改提交的作者名稱和電子郵件地址。

接下來，我們來看看 git reset 命令。 這個命令可以將你的儲存函式庫和工作目錄重置到一個已知的狀態。 它可以調整 HEAD 指標，更新索引，甚至修改你的工作目錄。

git reset 命令有三種主要的選項：--soft、--mixed 和 --hard。 這些選項會影響索引和工作目錄的更新方式。

  • git reset --soft: 這個選項只會改變 HEAD 指標，索引和工作目錄保持不變。
  • git reset --mixed: 這個選項會改變 HEAD 指標和索引，但不會修改工作目錄。
  • git reset --hard: 這個選項會改變 HEAD 指標、索引和工作目錄。
# 將HEAD指標重置到上一次提交，並保留工作目錄中的變更
$ git reset --soft HEAD~1

# 將HEAD指標重置到上一次提交，並清除索引，但保留工作目錄中的變更
$ git reset --mixed HEAD~1

# 將HEAD指標重置到上一次提交，並清除索引和工作目錄中的變更
$ git reset --hard HEAD~1

內容解密：

這些命令可以根據你的需求重置HEAD指標、索引和工作目錄。

最後，我們來看看 git cherry-pick 命令。 這個命令可以將一個或多個提交應用到另一個分支上。

# 將特定提交應用到當前分支上
$ git cherry-pick <commit_hash>

內容解密：

這個命令可以將指定的提交應用到當前分支上，從而實作跨分支的程式碼分享和重用。

總之，修正提交是版本控制中的一個重要方面。透過使用 git commit --amend、git reset 和 git cherry-pick 等命令，你可以輕鬆地修改和管理你的提交歷史。記得謹慎使用這些命令，以避免對你的儲存函式庫造成意外的修改。

Git 版本控制精要：最佳實踐與常用指令

Git 是一種廣泛使用的版本控制系統，它能夠幫助開發人員跟蹤程式碼的變更、協作開發和管理不同版本的程式碼。在本文中，我們將介紹 Git 的一些最佳實踐和常用指令，幫助你更好地使用 Git 來管理你的程式碼。

基本概念

在開始使用 Git 之前，瞭解一些基本概念是非常重要的。這包括：

  • 倉函式庫 (Repository)：Git 專案的核心，是一個儲存程式碼所有版本的資料函式庫。
  • 提交 (Commit)：對程式碼進行的一次修改，包括了對程式碼的描述、作者和時間戳等資訊。
  • 分支 (Branch)：一個可以獨立演進的程式碼版本，允許你在不影響主程式碼的情況下開發新功能或修復 bug。
  • 合並 (Merge)：將兩個或多個分支合並成一個單一的分支。

基本 Git 流程

  1. 初始化 Git 倉函式庫：使用 git init 或 git clone 初始化一個新的 Git 倉函式庫。
  2. 新增檔案：使用 git add 將檔案新增到 Git 的追蹤列表中。
  3. 提交變更：使用 git commit 將檔案的變更提交到 Git 倉函式庫中。
  4. 建立分支：使用 git branch 建立一個新的分支。
  5. 切換分支：使用 git checkout 切換到不同的分支。
  6. 合並分支：使用 git merge 將不同分支合並成一個單一的分支。

常用 Git 指令

  • git status：顯示目前 Git 倉函式庫的狀態，包括哪些檔案已經修改或新增。
  • git log：顯示提交歷史，包括提交的描述、作者和時間戳等資訊。
  • git diff：顯示檔案之間的差異。
  • git reset：用於重置提交，重新開始或是還原初始狀態。
  • git cherry-pick：從其他分支挑選特定的提交，然後應用到目前的分支。

合作開發

Git 提供了多種方式來進行合作開發，包括：

  • 遠端倉函式庫 (Remote Repository)：將你的程式碼存放在遠端伺服器上，這樣你的團隊成員就可以方便地分享和合作。
  • Pull Request：當你完成了一項功能或修復了一個 bug 後，可以傳送一個 pull request 請求其他人審核你的程式碼。

最佳實踐

  • 定期提交：每次完成一項任務後，就提交你的變更到 Git 倉函式庫中，以保持程式碼的一致性和追蹤變更。
  • 使用描述性的提交訊息：在提交訊息中簡要描述你的變更，幫助他人瞭解你做了什麼。
  • 保持倉函式庫清潔：定期清理未使用的檔案或分支，以保持倉函式庫的整潔和可維護性。

內容解密：

這個圖表展示了從初始化到完成 Pull Request 的整個過程，並強調了每一步驟在 Git 合作流程中的重要性。透過遵循這個流程，你可以確保你的專案被正確地管理和更新。

Git Stash 的應用

在日常開發中，我們常常會遇到突發狀況，例如需要立即修復 critical bug 或處理優先順序更高的任務。此時，若目前的工作進度尚未完成，又不想提交一個不完整的 commit，git stash 就派上用場了。它能快速儲存目前的修改，讓你的工作目錄保持乾淨，以便切換到其他分支進行工作。

中斷的工作流程

假設你正在修改程式碼，突然收到一個緊急修復 bug 的請求。此時，你可以使用 git stash 儲存目前的修改：

$ cd the-git-project
# 編輯許多檔案，工作尚未完成
# 緊急修復 bug！
# 必須放下手邊工作，立即處理 bug！
$ git stash push
Saved working directory and index state WIP on main: 1En0v80...
# 編輯並修復 bug
# 提交修改
# 繼續之前暫存的工作
$ git stash pop

git stash pop 會還原之前儲存的修改，讓你繼續之前的工作。由於 push 是 git stash 的預設選項，你可以省略 push。Git 也會提供一個預設的 log 訊息，但你也可以自定義訊息，例如：

$ git stash -m "WIP: 進行中的工作"

“WIP” 是 “work in progress” 的縮寫，表示工作正在進行中。

相較於使用分支和提交來儲存修改，git stash 更為簡潔快速。若使用分支和提交，你需要手動建立一個新分支，提交修改，然後切換回原分支繼續工作，最後再合併儲存的分支。步驟如下：

$ git branch wip-branch
$ git checkout wip-branch
$ git add.
$ git commit -m "WIP: 進行中的工作"
$ git checkout main
# 修復 bug
$ git checkout wip-branch
$ git merge main

多個 Stash

如果你需要暫存多個工作，那麼 git stash 就會變得更加強大。你可以使用 git stash list 來檢視所有暫存的工作：

$ git stash list
stash@{0}: WIP on main: 1En0v80...
stash@{1}: WIP on main: 2d6b8f5...

然後，你可以使用 git stash apply 來應用特定的 stash：

$ git stash apply stash@{1}

或者，你可以使用 git stash pop 來移除並應用最新的 stash：

$ git stash pop stash@{1}
內容解密：
  • git stash push: 暫存目前的修改。
  • git stash pop: 還原之前暫存的修改。
  • git stash -m "WIP: 進行中的工作": 自定義暫存訊息。
  • git stash list: 檢視所有暫存的工作。
  • git stash apply: 應用特定的暫存。
  • git stash pop: 移除並應用最新的暫存。

流程圖：

程式碼範例：

# 暫存目前的修改
$ git stash push

# 檢視所有暫存的工作
$ git stash list

# 應用特定的暫存
$ git stash apply stash@{1}

# 移除並應用最新的暫存
$ git stash pop

Git Stash 的使用與最佳實踐

基本用法

git stash 是一個強大的工具，能夠暫時儲存你當前的工作進度，讓你可以在其他分支或任務上工作，然後再還原之前的修改。基本用法如下：

$ git stash  # 暫存當前的工作進度
$ git stash list  # 列出所有暫存的工作進度
$ git stash apply  # 還原最近一次暫存的工作進度
$ git stash drop  # 刪除最近一次暫存的工作進度

進階用法

除了基本用法，git stash 還有一些進階用法，可以幫助你更好地管理你的工作進度。

$ git stash save "描述"  # 暫存當前的工作進度，並新增描述
$ git stash apply stash@{n}  # 還原指定的暫存工作進度
$ git stash branch 新分支  # 根據暫存的工作進度建立一個新分支

最佳實踐

使用 git stash 時，應該遵循一些最佳實踐，以避免出現問題：

  1. 定期提交: 對於尚未完成的工作，應該定期提交，以避免因為 git stash 而丟失修改。
  2. 使用描述: 當使用 git stash save 時，應該新增描述，以便於之後識別暫存的工作進度。
  3. 小心使用 git stash drop: 在刪除暫存的工作進度之前，應該確保你不再需要這些修改。
  4. 使用 git stash apply 而非 git stash pop: 如果你需要還原多次暫存的工作進度，應該使用 git stash apply 而非 git stash pop，以避免丟失修改。

第一部分：儲存函式庫概念

本部分討論的儲存函式庫概念是在分享和分散式環境中理解和使用 Git 儲存函式庫的根本。以下章節將介紹關鍵原則和重要術語，以幫助您過渡到在 Git 儲存函式庫中工作。

裸儲存函式庫和開發儲存函式庫

Git 儲存函式庫可以是裸儲存函式庫或開發（非裸）儲存函式庫。

開發儲存函式庫用於正常的日常開發。它維護當前分支的概念，並在工作目錄中提供當前分支的已簽出副本。到目前為止，本章中提到的所有儲存函式庫都是開發儲存函式庫。

相反，裸儲存函式庫沒有工作目錄，不應用於正常開發。此外，裸儲存函式庫沒有已簽出分支的概念。可以將裸儲存函式庫想像成僅包含.git 目錄的內容。換句話說，您不應該在裸儲存函式庫中進行提交。

裸儲存函式庫似乎沒什麼用處，但它的作用至關重要：作為協作開發的權威焦點。其他開發人員從裸儲存函式庫複製和提取，並將更新推播到裸儲存函式庫。我們將在本章稍後透過一個範例展示所有這些是如何協同工作的。

首先，讓我們檢查一下 –bare 旗標如何影響建立開發儲存函式庫和裸儲存函式庫時初始化的目錄：

# 開發（非裸）儲存函式庫
$ cd /tmp
$ git init -b main fluff
Initialized empty Git repository in /private/tmp/fluff/.git/
$ tree fluff
fluff
└──.git
    ├── branches
    ├── config
    ├── description
    ├── HEAD
    ├── hooks
    │   ├── applypatch-msg.sample
    │   ├── commit-msg.sample
    │   ├── post-commit.sample
    │   ├── post-merge.sample
    │   ├── post-receive.sample
    │   ├── post-update.sample
    │   ├── pre-applypatch.sample
    │   ├── pre-commit.sample
    │   ├── pre-push.sample
    │   ├── pre-rebase.sample
    │   ├── pre-receive.sample
    │   └── prepare-commit-msg.sample
    ├── info
    │   └── exclude
    ├── objects
    │   └── info
    │       └── packs
    ├── refs
    │   ├── heads
    │   └── tags
    └── refs

0 directories, 20 files

# 裸儲存函式庫
$ git init --bare -b main bar
Initialized empty Git repository in /private/tmp/bar/
$ tree bar
bar
├── branches
├── config
├── description
├── HEAD
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── post-commit.sample
│   ├── post-merge.sample
│   ├── post-receive.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   └── prepare-commit-msg.sample
├── info
│   └── exclude
├── objects
│   └── info
│       └── packs
├── refs
│   ├── heads
│   └── tags

0 directories, 18 files

如您所見，兩個目錄結構幾乎相同，不同之處在於裸儲存函式庫缺少工作目錄層次結構。

克隆

Git 的 clone 命令會建立一個現有儲存函式庫的副本，並初始化新的儲存函式庫，以便它可以與原始儲存函式庫進行通訊。這通常是您在新機器上開始工作或與他人分享專案時要做的第一件事。

當您執行 git clone 時，Git 會自動為原始儲存函式庫設定一個遠端參照，預設名稱為 origin。這使得您稍後可以輕鬆地從原始儲存函式庫提取更改或將更改推播回原始儲存函式庫。


$ git clone -b main file:///tmp/fluff fluff-clone

現在，讓我們看看 clone 建立了什麼：


$ cd fluff-clone

$ git remote -v

origin  file:///tmp/fluff (fetch)

origin  file:///tmp/fluff (push)

如您所見，clone 命令已經設定了 origin 遠端參照，指向原始 fluff 儲存函式庫。

遠端

遠端是指向其他 Git 儲存函式庫的別名。它們允許您輕鬆地識別並與其他 Git 儲存函式庫進行互動。

您可以使用 git remote 命令列出、新增、刪除和重新命名遠端。例如，要列出當前遠端，可以執行：


$ git remote -v

這將顯示所有遠端及其對應的 URL。

要新增新的遠端，可以執行：


$ git remote add <name> <url>

例如，要新增一個名為 upstream 的新的遠端，可以執行：


$ git remote add upstream https://github.com/user/repo.git

這將建立一個名為 upstream 的新的遠端，指向指定的 URL。

要刪除遠端，可以執行：


$ git remote rm <name>

例如，要刪除名為 upstream 的遠端，可以執行：


$ git remote rm upstream

提取和推播

一旦您設定了遠端，您就可以使用 git fetch 和 git push 命令從遠端倉函式庫提取更改或將更改推播到遠端倉函式庫。

要從遠端倉函式庫提取更改，可以執行：


$ git fetch <remote>

例如，要從名為 origin 的遠端倉函式庫提取更改，可以執行：


$ git fetch origin

這將從遠端倉函式庫下載最新的更改，但不會自動合併它們到您的當前分支中。

要將更改推播到遠端倉函式庫，可以執行：


$ git push <remote> <branch>

例如，要將更改推播到名為 origin 的遠端倉函式庫的 main 分支，可以執行：


$ git push origin main

這將您的更改上傳到遠端倉函式庫並更新 main 分支。

本文將探討如何使用 Git 的遠端功能來管理外部儲存函式庫，並分享一些實際專案中的經驗和技巧。

首先，我們需要了解 Git 的遠端功能。遠端是一個用於參考其他儲存函式庫的名稱，允許您輕鬆地從遠端儲存函式庫中提取和推播變更。您可以使用 git remote 命令來新增、刪除和管理遠端。

當您從其他儲存函式庫中提取變更時，您需要使用 git fetch 命令。這個命令會從遠端儲存函式庫中下載所有變更，但不會自動合併到您的本地分支中。您需要使用 git merge 或 git pull 命令來合併變更。

如果您想要推播變更到遠端儲存函式庫，您需要使用 git push 命令。這個命令會將您的本地變更上傳到遠端儲存函式庫中。

在管理外部儲存函式庫時，需要注意幾個重要的事項：

  1. 建立遠端: 在開始管理外部儲存函式庫之前，您需要建立一個遠端來參考該儲存函式庫。
  2. 提取變更: 使用 git fetch 命令從遠端儲存函式庫中提取變更。
  3. 合併變更: 使用 git merge 或 git pull 命令來合併變更。
  4. 推播變更: 使用 git push 命令來推播變更到遠端儲存函式庫。

在實際專案中，我們可以使用以下步驟來管理外部儲存函式庫：

  1. 新增遠端: 使用 git remote add 命令新增一個遠端來參考外部儲存函式庫。
  2. 提取變更: 使用 git fetch 命令從遠端儲存函式庫中提取變更。
  3. 建立本地分支: 使用 git branch 命令建立一個本地分支來跟蹤遠端分支。
  4. 合併變更: 使用 git merge 或 git pull 命令來合併變更。
  5. 推播變更: 使用 git push 命令來推播變更到遠端儲存函式庫。

總之，使用 Git 的遠端功能可以有效地管理外部儲存函式庫。透過建立遠端、提取變更、合併變更和推播變更，您可以輕鬆地與其他儲存函式庫協作並保持您的專案更新。

內容解密：

上述程式碼片段展示瞭如何使用 Git 的遠端功能來管理外部儲存函式庫。透過使用 git remote 命令新增遠端，使用 git fetch 命令提取變更，使用 git merge 或 git pull 命令合併變更，最後使用 git push 命令推播變更，您可以輕鬆地與其他儲存函式庫協作並保持您的專案更新。

圖表解析：

下圖展示瞭 Git 的遠端功能的工作流程： 在這個工作流程中，首先新增一個遠端來參考外部儲存函式庫，然後提取變更，建立本地分支，合併變更，最後推播變改到遠端儲存函式庫。

Git遠端儲存函式倉管理：玄貓的深度

1.

在軟體開發的過程中，版本控制系統（VCS）是不可或缺的一部分。Git作為一種分散式版本控制系統，已經成為軟體開發者的首選工具。在這篇文章中，我們將探討Git遠端儲存函式庫的管理，包括遠端儲存函式庫的建立、設定、同步等。

2. 遠端儲存函式庫的建立

要建立一個遠端儲存函式庫，首先需要建立一個新的Git儲存函式庫。可以使用git init命令來初始化一個新的Git儲存函式庫。

git init

然後，可以使用git remote add命令來新增一個遠端儲存函式庫。

git remote add origin https://github.com/user/repo.git

3. 遠端儲存函式庫的設定

新增遠端儲存函式庫後，需要設定遠端儲存函式庫的URL和分支。可以使用git remote set-url命令來設定遠端儲存函式庫的URL。

git remote set-url origin https://github.com/user/repo.git

可以使用git branch命令來檢視本地分支。

git branch

可以使用git push命令來推播本地分支到遠端儲存函式庫。

git push origin master

4. 遠端儲存函式庫的同步

要同步遠端儲存函式庫，可以使用git fetch命令來下載遠端儲存函式庫的最新提交。

git fetch origin

然後，可以使用git merge命令來合併遠端儲存函式庫的提交。

git merge origin/master

或者，可以使用git pull命令來下載和合併遠端儲存函式庫的提交。

git pull origin master
內容解密：
  • git init：初始化一個新的Git儲存函式庫。
  • git remote add：新增一個遠端儲存函式庫。
  • git remote set-url：設定遠端儲存函式庫的URL。
  • git branch：檢視本地分支。
  • git push：推播本地分支到遠端儲存函式庫。
  • git fetch：下載遠端儲存函式庫的最新提交。
  • git merge：合併遠端儲存函式庫的提交。
  • git pull：下載和合併遠端儲存函式庫的提交。

6. 視覺化 Git 遠端儲存函式倉管理

內容解密：

  • 初始化Git儲存函式庫：建立一個新的Git儲存函式庫。
  • 新增遠端儲存函式庫：新增一個遠端儲存函式庫到本地Git儲存函式庫。
  • 設定遠端儲存函式庫URL：設定遠端儲存函式庫的URL。
  • 推播本地分支：推播本地分支到遠端儲存函式庫。
  • 下載遠端儲存函式庫提交：下載遠端儲存函式庫的最新提交。
  • 合併遠端儲存函式庫提交：合併遠端儲存函式庫的提交到本地分支。
  • 同步完成：完成Git遠端儲存函式庫的同步。

Git 遠端儲存函式庫協作開發流程

在現代軟體開發中，團隊協作和版本控制至關重要。Git 提供了強大的分支和遠端儲存函式庫功能，讓團隊成員能同時開發不同功能，並有效地整合程式碼變更。本文將探討 Git 遠端儲存函式庫的協作開發流程，著重於分支追蹤和程式碼更新策略。

瞭解分支追蹤

分支追蹤是 Git 的核心機制，它建立了本地分支和遠端分支之間的關聯。當使用 git branch -a 檢視所有分支時，可以看到本地分支和遠端追蹤分支的關係。

$ git branch -a
* main
  remotes/origin/HEAD -> origin/main
  remotes/origin/main

更新遠端儲存函式庫

當修改了程式碼後，可以使用 git push 將變更推播到遠端儲存函式庫：

$ git push
...
To /tmp/Depot/my_website.git
  2daf640..a5f8133 main -> main

取得遠端更新

當其他團隊成員也提交了變更到遠端儲存函式庫後，可以使用 git pull 更新本地儲存函式庫：

$ git pull
...
From /tmp/Depot/my_website
  a5f8133..c4e45f7 main -> origin/main
Updating a5f8133..c4e45f7
Fast-forward
 index.html | 2 ++
 1 file changed, 2 insertions(+)

分步操作：Fetch 與 Merge

有時，可能希望先檢視遠端變更，再決定是否合併。這時可以單獨執行 git fetch：

$ git fetch origin

然後使用 git log、git diff 或其他工具檢視遠端追蹤分支的變更。確認後，再使用 git merge 合併：

$ git merge origin/main

Negative Refspecs 的應用

Git 2.29 版本引入了 negative refspecs，允許在 fetch 或 push 時排除特定分支。例如，要排除 skip-me 分支：

$ git fetch newdev refs/heads/*:refs/remotes/newdev/* ^refs/heads/skip-me

或者在設定檔中設定：

[remote "newdev"]
url = /tmp/Depot/my_website.git
fetch = +refs/heads/dev:refs/remotes/origin/dev
fetch = +refs/heads/stable:refs/remotes/origin/stable
fetch = ^refs/heads/skip-me

選擇性分支更新

可以在設定檔中明確指定要更新的分支：

[remote "newdev"]
url = /tmp/Depot/my_website.git
fetch = +refs/heads/dev:refs/remotes/origin/dev
fetch = +refs/heads/stable:refs/remotes/origin/stable

內容解密：關於 Git Pull 的核心概念

git pull 指令簡化了同步遠端儲存函式庫的流程，但理解其背後的 fetch 和 merge 操作至關重要。

Git Pull 流程示意

這個流程圖清晰地展示了 git pull 的執行步驟，以及 fetch 和 merge 的角色。

應該合併還是 Rebase？

那麼，在 pull 操作期間應該合併還是 rebase 變更呢？簡短的答案是「隨心所欲」。但是為什麼要選擇其中一個呢？以下是一些需要考慮的問題。

使用合併，每次 pull 時都可能會產生一個額外的合併提交，以記錄每個分支中同時出現的更新變更。從某種意義上說，它真實地反映了兩個獨立發生的開發路徑，然後被合併在一起。在合併期間必須解決衝突。每個分支上的每個提交序列都將根據最初編寫它的提交。當推播到上游時，任何合併提交都將繼續存在。有些人認為這些合併是多餘的，不希望它們弄亂歷史記錄。其他人則認為這些合併更準確地描繪了開發歷史，並希望保留它們。

由於 rebase 從根本上改變了提交序列何時何地開發的概念，因此開發歷史的某些方面將會丟失。具體來說，最初根據其進行開發的原始提交將更改為遠端追蹤分支新提取的 HEAD。這會使開發看起來比實際發生的時間晚（按提交順序）。如果您可以接受，我們也沒問題。它只是與合併歷史記錄相比有所不同與更簡單。當然，在 rebase 操作期間仍然需要根據需要解決衝突。由於正在 rebase 的變更仍然嚴格限制在儲存函式庫本地，並且尚未釋出，因此確實沒有理由擔心此 rebase 的「不要更改歷史記錄」的說法。

對於合併和 rebase，都應該考慮新的最終內容與每個開發分支上獨立存在的內容不同。因此，在推播到上游儲存函式庫之前，可能需要以新形式進行某種形式的驗證：也許是編譯和測試週期。

我們傾向於喜歡看到更簡單、線性的歷史記錄。在我們的大部分個人開發過程中，我們通常不太關心我們的變更相對於同事在遠端追蹤分支 fetch 中引入的變更的輕微重新排序，因此我們喜歡使用 rebase 選項。

遠端儲存函式庫開發週期圖解

將本地開發與上游儲存函式庫的變更整合是 Git 分散式開發週期的核心。讓我們花點時間想像一下在 clone 和 pull 操作期間本地儲存函式庫和上游 origin 儲存函式庫會發生什麼。

內容解密：關於 Git Pull 的核心概念

git pull 指令簡化了同步遠端儲存函式庫的流程，但理解其背後的 fetch 和 merge 操作至關重要。

Git Pull 流程示意

這個流程圖清晰地展示了 git pull 的執行步驟，以及 fetch 和 merge 的角色。

流程圖：Git Clone 和 Pull 過程

這個流程圖展示了 Git Clone 和 Pull 過程中的主要步驟。

遠端追蹤分支的進階操作：新增、刪除與同步

(圖 11-2 簡單的儲存函式庫與提交) (圖 11-3 複製的儲存函式庫) (圖 11-4 具有新提交的本地儲存函式庫)

遠端倉函式庫的操作：同步與合併的藝術

在軟體開發過程中，遠端倉函式庫扮演著至關重要的角色，它不僅是程式碼的備份中心，更是團隊協作的樞紐。我經常將遠端倉函式庫比作一箇中央圖書館，所有開發者都可以在其中取得最新的知識，並貢獻自己的智慧。

(視覺化遠端操作) 內容解密： 該流程圖展示了與遠端倉函式庫同步和合併的典型步驟。首先，使用 git fetch 取得遠端更新。如果存在衝突，則需要解決衝突併合併遠端分支。最後，使用 git push 將合併後的更改推播到遠端倉函式庫。

透過 Git 遠端指令精準操控程式碼版本

(Git 遠端指令) 內容解密： 上圖展示了常用的 git remote 指令與本地和遠端儲存函式庫之間的關係。git remote add 新增遠端儲存函式庫，git remote set-url 設定遠端儲存函式庫的 URL，git remote show 顯示遠端儲存函式庫資訊，git remote prune 清理過時的遠端追蹤分支，git remote update 更新本地儲存函式庫的遠端追蹤分支。

遠端追蹤分支的進階操作：新增、刪除與同步

(建立遠端追蹤分支) 內容解密： 該流程圖展示了建立遠端追蹤分支的步驟。使用 git checkout --track 指令可以建立一個本地分支來追蹤遠端分支。

透過這些圖表和解釋，我們可以更好地理解 Git 遠端指令和遠端追蹤分支的操作，從而更有效地管理程式碼版本和進行團隊協作。

Git 遠端儲存函式倉管理與最佳實務

###Git 遠端儲存函式庫的概念

Git 是一個分散式版本控制系統，它允許多個開發者在不同的地點合作於同一個專案。遠端儲存函式庫（Remote Repository）是 Git 中的一個重要概念，它指的是一個儲存函式庫的複製，通常位於伺服器上，供多個開發者分享和同步。

###建立遠端儲存函式庫

要建立遠端儲存函式庫，首先需要在伺服器上建立一個新的 Git 儲存函式庫。然後，開發者可以使用 git remote add 命令將遠端儲存函式庫新增到本地儲存函式庫中。例如：

git remote add origin git://git.example.org/myproject.git

這裡，origin 是遠端儲存函式庫的名稱，git://git.example.org/myproject.git 是遠端儲存函式庫的 URL。

###推播和提取變更

一旦遠端儲存函式庫被新增到本地儲存函式庫中，開發者就可以使用 git push 和 git pull 命令將變更推播到遠端儲存函式庫或提取遠端儲存函式庫的變更。例如：

git push origin master
git pull origin master

這裡，master 是要推播或提取的分支名稱。

###遠端追蹤分支

Git 使用遠端追蹤分支（Remote Tracking Branch）來追蹤來自其他儲存函式庫的變更。遠端追蹤分支是一個特殊的分支，它指向遠端儲存函式庫中的某個分支。開發者可以使用 git branch -a 命令檢視所有遠端追蹤分支。例如：

git branch -a
* master
  origin/master
  origin/dev

這裡，origin/master 和 origin/dev 是遠端追蹤分支，它們指向遠端儲存函式庫中的 master 和 dev 分支。

###合併和更新

當開發者想要將遠端儲存函式庫的變更合併到本地儲存函式庫中時，可以使用 git merge 命令。例如：

git merge origin/master

這裡，origin/master 是要合併的遠端追蹤分支。

如果開發者想要更新本地儲存函式庫以反映遠端儲存函式庫的最新變更，可以使用 git pull 命令。例如：

git pull origin master

這裡，master 是要更新的分支名稱。

###最佳實務

  1. 定期推播變更：開發者應該定期將變更推播到遠端儲存函式庫，以確保其他開發者可以看到最新的變更。
  2. 定期提取變更：開發者應該定期提取遠端儲存函式庫的變更，以確保本地儲存函式庫是最新的。
  3. 使用合併：開發者應該使用 git merge 命令來合併遠端儲存函式庫的變更，而不是使用 git pull 命令。
  4. 使用分支：開發者應該使用分支來組織程式碼和合作於專案中。
  5. 定期備份：開發者應該定期備份本地儲存函式庫和遠端儲存函式庫，以防止資料丟失。

###總結

Git 遠端儲存函式倉管理與最佳實務是合作於專案中的重要部分。透過瞭解如何建立遠端儲存函式庫、推播和提取變更、使用遠端追蹤分支、合併和更新，可以幫助開發者有效地合作於專案中。同時，遵循最佳實務可以幫助開發者避免常見的錯誤和問題。

玄貓帶你深入理解Git儲存函式庫釋出的奧秘

在軟體開發的江湖中，版本控制系統如同武林秘笈，記錄著每一次程式碼的演變。而Git，作為當今版本控制系統的佼佼者，其儲存函式庫的釋出與管理更是重中之重。今天，玄貓將帶領各位深入探索Git儲存函式庫釋出的各種技巧，助你在程式碼管理的道路上更加得心應手。

公開儲存函式庫：讓你的程式碼閃耀世界

公開儲存函式庫的核心在於讓所有人都能存取你的程式碼。最簡單的方式是在組織內部的檔案系統上釋出一個裸儲存函式庫，所有開發者都能讀寫。檔案系統URL，例如/path/to/Depot/project.git或file://path/to/Depot/project.git，就能滿足需求。雖然效能可能不是最佳，但透過NFS掛載的檔案系統可以提供這樣的分享支援。

內容解密：

上圖展示了多個開發者透過分享檔案系統存取同一個裸儲存函式庫的架構。這種方式簡單易用，適合團隊內部程式碼分享。

若開發團隊使用多台機器，則需要更複雜的存取方式。例如，公司IT部門可能會提供一個中央伺服器來存放儲存函式庫，並定期備份。如果無法直接存取檔案系統（例如NFS），可以使用SSH URL來命名儲存函式庫。

desktop$ git clone ssh://example.com/tmp/Depot/my_website.git

內容解密：

這個指令示範瞭如何透過SSH協定複製遠端儲存函式庫。開發者需要在中央伺服器上擁有帳號才能進行存取。

受控存取：程式碼的安全守護者

當你需要對儲存函式庫的存取進行更精細的控制時，Gitolite專案值得一試。它在Git之上提供了一個存取控制層，可以根據使用者或群組設定不同的存取許可權。

$ git clone https://github.com/sitaramc/gitolite.git

內容解密：

這個指令示範瞭如何複製Gitolite專案的程式碼。你可以根據專案檔案設定Gitolite，以管理儲存函式庫的存取許可權。

匿名讀取：分享程式碼的便捷之門

如果你想分享程式碼但不想授予寫入許可權，匿名唯讀存取是一個常見的解決方案。使用git-daemon和HTTP伺服器可以輕鬆實作。

使用 git-daemon 釋出儲存函式庫

設定git-daemon允許你使用Git原生協定匯出儲存函式庫。你需要在裸儲存函式庫的頂層目錄中建立git-daemon-export-ok檔案，以標記儲存函式庫可以被匯出。

# 在 /etc/inetd.conf 中新增一行
git stream tcp nowait nobody /usr/bin/git-daemon git-daemon --inetd --verbose --export-all --base-path=/pub/git

內容解密：

這個設定片段示範瞭如何在inetd中組態git-daemon，將/pub/git目錄下的所有儲存函式庫公開。

你也可以使用--interpolated-path選項來建立虛擬主機，讓不同的儲存函式庫看起來像是位於不同的主機上。

玄貓的錦囊妙計

在釋出儲存函式庫時，務必選擇適合專案需求的存取控制策略。對於開源專案，匿名讀取通常就足夠了。而對於商業專案，則需要更嚴格的存取控制，以保護程式碼安全。

選擇合適的釋出方式，才能讓你的程式碼在江湖中大放異彩！

玄貓帶你深入淺出 Git 伺服器架設：開發高效能私有 Git 伺服器

在軟體開發的江湖中，版本控制系統如同武林秘笈，是團隊協作的根本。Git 以其分散式架構和高效能聞名，成為版本控制領域的佼佼者。今天，玄貓將帶領各位深入 Git 伺服器的架設，開發一個高效能的私有 Git 伺服器。

利用 HTTP 協定釋出儲存函式庫

有時候，要讓匿名使用者讀取儲存函式庫最簡單的方法就是透過 HTTP 協定。若你設定了 gitweb，使用者就能直接在瀏覽器輸入網址，檢視儲存函式庫索引，並透過點選和瀏覽器傳回按鈕進行操作，無需執行 Git 就能下載檔案。

在透過 HTTP 協定釋出之前，你需要對裸 Git 儲存函式庫進行設定，啟用 hooks/post-update 選項：

$ cd /path/to/bare/repo.git
$ mv hooks/post-update.sample hooks/post-update

確認 post-update 指令碼可執行，或使用 chmod 755 確保其可執行許可權。最後，將裸 Git 儲存函式庫複製到 HTTP 伺服器的目錄下。現在，你可以使用類別似以下的網址釋出你的專案：

http://www.example.org/software/repository.git

如果你看到類別似以下的錯誤訊息：

...not found: did you run git update-server-info on the server?

或

Perhaps git-update-server-info needs to be run there?

很可能是伺服器上的 hooks/post-update 指令碼沒有正確執行。

Smart HTTP 釋出儲存函式庫

透過 Smart HTTP 釋出儲存函式庫的原理相當簡單，但你可能需要參考 git-http-backend 指令的手冊頁，以獲得更完整的說明。以下簡要說明操作步驟：

  1. 首先，Smart HTTP 主要用於 Apache。以下範例將示範如何修改 Apache 設定檔。在 Ubuntu 系統中，這些檔案位於 /etc/apache2。

  2. 接著，需要定義從釋出的儲存函式庫名稱到 Apache 可存取的磁碟儲存函式庫佈局的對映。此處的對映設定讓 http://$host_name/git/foo/bar.git 對應到 Apache 檔案檢視下的 /var/www/git/foo/bar.git。

  3. 最後，需要啟用三個 Apache 模組：mod_cgi、mod_alias 和 mod_env。

定義一些變數和指向 git-http-backend 指令的指令碼別名，如下所示：

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/

git-http-backend 的位置可能不同。例如，Ubuntu 將其放在 /usr/lib/git-core/git-http-backend。

現在，你可以選擇允許匿名使用者讀取，但需要驗證寫入許可權，或者讀寫都需要驗證。

對於匿名使用者讀取，設定 LocationMatch 指令：

<LocationMatch "^/git/.*/git-receive-pack$">
AuthType Basic
AuthName "Git Access"
Require group committers
...
</LocationMatch>

對於需要驗證的讀取，設定儲存函式庫或其父目錄的 Location 指令：

<Location /git/private>
AuthType Basic
AuthName "Private Git Access"
Require group committers
...
</Location>

手冊頁中還有更多設定，例如設定 gitweb 存取、提供多個儲存函式庫名稱空間，以及設定靜態頁面的加速存取等。

透過 Git 和 HTTP 協定釋出儲存函式庫

雖然使用網頁伺服器和瀏覽器很方便，但請仔細考慮伺服器的流量負載。開發專案可能很大，HTTP 的效率不如原生 Git 協定。

你可以同時提供 HTTP 和 Git 協定存取，但這可能需要在 Git 伺服器和 HTTP 伺服器之間進行調整和協調。具體來說，可能需要使用 git-daemon 的 --interpolated-path 選項和 Apache 的 Alias 選項來提供對相同資料的兩種檢視的無縫整合。更多關於 --interpolated-path 選項的細節，請參考 git daemon 手冊頁；關於 Apache Alias 選項的細節，請參考 Apache 檔案或其設定檔 /etc/apache2/mods-available/alias.conf。

允許匿名使用者寫入的儲存函式庫

技術上，你可以使用 Git 原生協定網址格式來允許匿名使用者寫入 git-daemon 提供的儲存函式庫。這需要在已釋出儲存函式庫的設定檔中啟用 receivepack 選項：

[daemon]
receivepack = true

你可以在每個開發人員都受信任的私有區域網路上這樣做，但這並非最佳實踐。建議你考慮透過 SSH 連線建立通道來滿足 Git 推播需求。

儲存函式庫釋出建議

在建立伺服器和託管服務來託管 Git 儲存函式庫之前，請先考慮你的實際需求以及提供 Git 儲存函式庫的原因。或許現有的公司、網站或服務已經可以滿足你的需求。

對於私有程式碼，或者即使是公開程式碼，如果你重視服務價值，可以考慮使用商業 Git 託管服務。如果你提供的是開源儲存函式庫，與服務需求或期望不高，市面上有許多 Git 託管服務可供選擇，有些還提供升級到支援服務的選項，例如 GitHub、GitLab 和 Bitbucket 等都是主流的熱門選擇。

更複雜的情況是，當你想要在內部儲存私有程式碼時，就必須建立和維護自己的主儲存函式庫託管平台，而與別忘了備份！即使如此，也有企業級的 Git 託管平台提供所有這些功能，可以透過訂閱或授權的方式使用。

如果你需要建立自己的伺服器，通常의做法是使用 Git-over-SSH 協定，並要求所有儲存函式庫使用者都具有 SSH 存取託管伺服器 的許可權。在伺服器上，通常會建立一個半通用的使用者帳戶和群組（例如，gituser) 。所有 儲 存 函式庫 都 歸 該 使用 者 群 組 所 有 ，並且 通 常 位 於 專門 為 此 目 的 保 留 的 檔 案 空 間 中 （例如 /git 、 /opt/git 或 /var/git) 。

關鍵在於：該目錄必須歸 gituser) 群組所有，可由該群組寫入，並且設定了黏著位。

現在，如果你想在伺服器上建立一個名為 newrepo.git) 的新託管儲 存 函 式 函式庫，只需 透過 SSH 登入伺服器並執行以下操作：

$ ssh gituser@my-host.example.com 
$ cd /git 
$ mkdir newrepo.git 
$ cd newrepo.git 
$ git init --shared --bare

以上四個指令可以簡化如下：

$ git --git-dir /git/newrepo.git init --shared

Git 分散式版本控制的精髓

Git 是一個強大的分散式版本控制系統，允許多個開發者在不同的位置合作完成專案。它的分散式架構使得開發者可以在本地工作，並將變更推播到遠端儲存函式庫。

分散式版本控制的優點

Git 的分散式版本控制有以下優點：

  1. 彈性: Git 允許開發者在本地工作，並將變更推播到遠端儲存函式庫。這使得開發者可以在不同的位置合作完成專案。
  2. 安全: Git 的分散式架構使得開發者可以在本地工作，並將變更推播到遠端儲存函式庫。這減少了單點故障的風險，並提高了專案的安全性。
  3. 高效: Git 的分散式版本控制使得開發者可以在本地工作，並將變更推播到遠端儲存函式庫。這提高了開發者的生產力，並減少了等待時間。

Git 的時間觀

Git 在遍歷提交的有向無環圖 (DAG) 時，體現了這種對分支變化的歷史模糊性。因此，如果 Git 在嘗試線性化提交序列時遇到合併提交，它必須先選擇一個分支。

上游與下游流程

從另一個儲存函式庫複製出來的兩個儲存函式庫之間並沒有嚴格的關係。然而，通常將父儲存函式庫稱為新複製儲存函式庫的上游。相對地，新的複製儲存函式庫通常被描述為原始父儲存函式庫的下游。

內容解密

此流程圖展示了多個開發者分支合併到主分支的流程，體現了 Git 分散式版本控制的精髓。

分散式開發的最佳實踐

以下章節將描述使用一個或多個分享 Git 儲存函式庫時的常見最佳實踐、準則和經驗法則。

  1. 修改已釋出的歷史紀錄: 一旦您釋出了一個其他人可能複製的儲存函式庫，您就應該將其視為靜態的，並避免重寫任何分支的歷史紀錄。
  2. 瞭解你的位置: 參與分散式開發專案時，瞭解你、你的儲存函式庫以及你的開發工作如何融入更大的圖景非常重要。
流程解密

此流程圖展示了多個開發者分支合併到主分支的流程，體現了 Git 分散式版本控制的精髓。

內容解密

此圖展示了 Git 儲存函式庫之間的關係，並非線性而是可以形成網狀結構，體現了 Git 的靈活性。

流程解密

此流程圖展示了多個開發者分支合併到主分支的流程，體現了 Git 分散式版本控制的精髓。

Git 版本控制：工作流程和最佳實踐

版本控制簡介

版本控制是一種管理檔案和程式碼變化的系統，它讓開發者能夠追蹤修改記錄、合併變化、以及管理不同的版本。在軟體開發中，版本控制是一種必不可少的工具。

Git 版本控制

Git 是一個分散式版本控制系統，它在近年來逐漸成為開發者們最為喜愛的版本控制工具。Git 能夠管理從小型到大型的軟體專案，它提供了一套完整的版本控制解決方案。

Git 的基本概念

Git 有以下幾個基本概念：

  1. Repository（儲存函式庫）： Git 的儲存函式庫是一個用來存放版本控制檔案和目錄的場所。每一個儲存函式庫都可以獨立工作，並且能夠跟蹤檔案和目錄的變化。
  2. Branch（分支）：Git 的分支是一個可以讓開發者們能夠同時進行多個獨立任務的工具。每一個分支都代表著不同的工作流程和任務，並且能夠進行不同程度的開發工作。
  3. Commit（提交）：Git 的提交是一種對檔案和目錄變化的紀錄。提交讓開發者們能夠將自己的修改紀錄下來，並且分享給其他開發者。

Git 基本命令

以下是幾個 Git 基本命令：

  • git init：初始化 Git 儲存函式庫。
  • git add：將檔案增加到暫存區。
  • git commit：提交檔案到 Git 儲存函式庫。
  • git branch：建立新分支。
  • git checkout：切換分支或檔案。
  • git merge：合併分支。

Git 分支管理

Git 分支管理是用來管理不同的工作流程和任務的一種機制。分支管理可以讓多個開發者同時工作於不同的任務，並且可以避免因為併衝而造成的問題。

以下是幾種常見的分支管理策略：

  1. Feature Branch：建立一個新分支用於開發新的功能，然後在功能完成後合併回主線。
  2. Release Branch：建立一個新分支用於釋出新版本，然後在版本釋出後合併回主線。
  3. Hotfix Branch：建立一個新分支用於快速修復緊急 bug，然後在修復後合併回主線和釋出分支。

Git Merge 與 Rebase

Merge 和 Rebase 是 Git 中兩種合併變化的方式，它們各自有優缺點，視具體情況而定，可以選擇其中之一。

Merge

Merge 可以把另一個分支的東西直接融合到目前所在分支上，而不會影響目前所在的工作。

優點：

  • Merge 的方式更加自然，類別似於人的思維模式，因為大部分人對 merge 比較熟悉。

缺點：

  • 這種做法會使目前 branch 產生更多 merge 的節點，使其 historical graph 更加複雜，不利於 debug。
  • 一個新的 commit nodes 就這樣莫名奇妙出現了，它完全是多餘且沒必要產生的，從功能性或 version control 方面來看，都不利於 project 之間進行溝通、交換 information、merge work等等

Rebase

Rebase 把 commit 都刪掉然後 reapply 一次，若在 reapply 的過程中遇到 conflict，就暫停等待人為解決 conflict並再次執行 rebase 命令；如此重復直到順利完成全部 commit 的重新套用，即完成了版本整合作業。最終你看到的 branch 上每個 commits 看起來像是 linear 續的一條時間線

優點：

  • rebase 是按照時間先後排序，這有助於清晰地識別改動
  • 使用rebase能生成一個乾淨清晰、線性的commit 歷史
  • commit 不會很亂也便於管理查詢和分析
  • 使用 rebase 方式比 merge 要來得好清晰
  • 也利於多人合作與溝通交流project info 等事宜
  • 也是使用 frequency 次數最多的手法，其它幾乎大部分 situation 都適用該技巧。並且即時使用branch時也是有相當比例是適用此技術

缺點：

  • 這個操作不直接就看得出與 feature 之間存在著互動作用，即當 developer B 去對 project 進行操作或提出需求或有問題想一起來改正時可能因為 linear 結構，沒有明確瞭解誰最後才把版本搞成現在這樣（或搞壞）什麼鬼東西，還有 feature 到底被做多少了 等一系列資訊反饋及溝通協調能力不強 situation下往往需要費較多 effort
  • Conflict 解決上也稍有麻煩因為一直停著來等人為處理這實在非常不便，如果 project 不斷更新，我要不斷的做 conflicts solve 然後重新開始 做事情，太花費時間也不方便debug，version 很難管控。假設我們一人一個 branch 或甚至一人維護多個 version的情況這種狀況會更嚴重。但通常對這些人說明一番他應該明白也比較容易配合並認可

Patch

Patch 是一個描述程式碼之間差異的檔案，用於修復軟體 bug 或增加新功能。在 Git 中，我們可以使用 git diff 指令產生 Patch 檔案。下面示範如何生成、傳送以及應用 Patch。

  1. 產生 Patch

    使用 git format-patch 命令來產生 Patch 檔案。

    # 使用 git format-patch 指令產生 Patch 檔案
git format-patch origin

  2. 傳送 Patch

    你可以透過電子郵件傳送 Patch 檔案給他人，使用 git send-email 指令即可。

    # 安裝 git-email
sudo apt-get install git-email

# 傳送Patch 到信箱 
git send-email *.patch

  3. 應用 Patch

    你可以使用 git am 命令將 Patch 應用到你的當前工作目錄中。

    # 應用Patch
git am *.patch

內容解密：上述程式碼展示瞭如何使用 Patch 和相關命令，在不同的版本之間交換變化、分享和更新程式碼。

Patch 能夠提供比整體傳送更多彈性的方法，不同開發者的不同目錄或目錄結構內容更新與修改以 email 方式實作，可降低不必要 code change collision 和降低郵件 attachment 運送時壓縮比效率太差的情況，如何運作需根據需求確定使用與否，但此處示範方法適合作為備考。

最後，小結一下文章內容，在本篇文章中，我們學習瞭解了版本控制和 Git 版本控制系統相關知識；並研究瞭如何建立並操作倉函式庫和 Commit，以及理解 Git 基礎指令 operation 等基礎常識，並闡述 Merge 和 Rebase 在開發過程中的使用場景，以及不同傳送 patches 技術。在 Git 工作中，我們能夠善用 Branch 做 task，並理解 branch 管理等工作流程方法，因此，我們還探討了 patches相關知識。

以上所述基礎 git 操作原理對大部分學習 git 入門初學者朋友，有助於提供瞭解版本控制知識背景以及日後學習提升所需；也與許多初階開發朋友所追求目標需求相同。不論何時，你都會持續不斷學習這些原理並拓展更多技術面知識，如高階 Git 技巧與最佳實踐，以及它與團隊協作實踐方法之間有著緊密聯絡。無論如何，有了一步一步向前邁進，每個人都可能透過不斷累積、吸收以及積極投入而找到自信、奮發進取共同面對更多更大的考驗。同時我希望，每一次學習歷程結束時，心中不斷滋生更多創新思考模式！

Git 版本控制與協同開發：Patch 的生成和應用

Git 是目前最廣泛使用的版本控制系統，提供了強大的 patch 功能，方便開發者在不同分支間分享和整合程式碼變更。本文將探討 Git 中 patch 的生成機制、使用方法以及最佳實踐，涵蓋從單一提交到複雜分支合併的各種情境。

基礎概念：提交、分支和 Patch

在 Git 中，每次提交都會建立一個新的版本文點，而 patch 就是這些版本文點之間的差異。開發者可以使用 git format-patch 生成 patch 檔案，以便在不同的分支或儲存函式庫之間傳輸。

生成 Patch：使用 git format-patch

git format-patch 命令可以根據指定的提交範圍生成一系列的 patch 檔案。每個 patch 檔案對應一個提交，包含提交的作者、日期、日誌訊息和變更內容。

以下是一個簡單的範例，演示如何使用 git format-patch 生成最近兩個提交的 patch：

# 初始化一個 Git 儲存函式庫
mkdir patch-demo
cd patch-demo
git init -b main

# 建立一個檔案並提交
echo A > file
git add file
git commit -m "Add A"

# 增加更多內容並提交
echo B >> file
git commit -m "Add B" -a

echo C >> file
git commit -m "Add C" -a

echo D >> file
git commit -m "Add D" -a

# 生成最近兩個提交的 Patch
git format-patch -2

應用 Patch：使用 git apply

一旦生成了 patch 檔案，就可以使用 git apply 將其應用到目標分支。這個過程可以簡化為三步驟：

  1. 生成 patch 檔案。
  2. 將 patch 檔案傳送給其他開發者或郵件列表。
  3. 使用 git apply 將 patch 檔案應用到目標分支。

以下是一個簡單的範例，演示如何使用 git apply 將一個 patch 檔案應用到目標分支：

# 假設已經生成了一個名為 0001-Add-C.patch 的 patch 檔案
git apply 0001-Add-C.patch

分支策略與 Patch 的結合

在更複雜的場景中，Patch 可以與分支策略結合使用，例如：

  • 功能分支：開發者可以在功能分支上進行開發，然後使用 git format-patch 生成 Patch，提交程式碼審查。審查透過後，再將 Patch 應用到主分支。
  • 釋出分支：維護者可以使用 Patch 將錯誤修復或功能增強應用到釋出分支，而無需合併整個開發分支。

最佳實踐：Patch 的管理與分享

在實際應用中，需要注意以下幾點：

  • 保持 Patch 的完整性：確保每個 Patch 都包含完整的提交資訊和變更內容。
  • 使用明確的 Patch 名稱：使用描述性的名稱來命名 Patch 檔案，以便於識別和管理。
  • 測試和驗證：在應用 Patch 之前，需要進行充分的測試和驗證，以確保其正確性和相容性。

透過以上介紹，我們深入瞭解了 Git 中 Patch 的生成機制、使用方法以及最佳實踐。Patch 提供了一種靈活且高效的方式來管理和分享程式碼變更，在團隊協作和版本控制中發揮著重要作用。

深入剖析 Git 的郵件傳輸機制

除了 Patch 之外，Git 還提供了強大的郵件傳輸機制，讓開發者可以輕鬆地交換程式碼更新。本文將探討 git send-email 命令，解析其工作原理、使用方法以及最佳實踐。

內容解密：Patch 範例解析

以下是一個使用 git format-patch 生成 Patch 的範例：

git format-patch -2  # 生成最近兩個提交的 patch

這段程式碼會生成最近兩個提交的 Patch 檔案。每個 Patch 檔案都包含完整的提交資訊和變更內容，可以用於在不同的分支或儲存函式庫之間傳輸。

視覺化 Patch 流程

上圖展示了使用 Patch 交換程式碼的流程。開發者 A 使用 git format-patch 生成 Patch 檔案，然後透過 git send-email 傳送到郵件伺服器。開發者 B 從郵件伺服器接收 Patch，並使用 git am 命令應用到自己的儲存函式庫。

透過理解 Patch 的應用場景、生成方式和應用方法，開發者可以更有效地進行程式碼協作和版本控制。Patch 提供了一種靈活且高效的方式來管理和分享程式碼變更，在團隊協作和版本控制中發揮著重要作用。

結語

本文探討了 Git 中 Patch 的生成機制、使用方法以及最佳實踐。透過對 Patch 功能的理解和運用，開發者可以提高團隊協作效率和版本控制品質。在軟體開發中，有效地管理和分享程式碼變更至關重要，而 Git 的 Patch 功能正是提供了一種強大且靈活的工具來實作這一目標。

使用 Git 的郵件傳輸機制

Git 的郵件傳輸機制提供了一種方便的方式來分享和套用修補程式。以下是使用郵件傳輸機制的步驟：

產生修補程式

首先，您需要產生一個修補程式。您可以使用 git format-patch 命令來產生一個修補程式。例如：

git format-patch --stdout main~2..main > mbox

這個命令會產生一個包含最近兩個提交的修補程式，並將其輸出到 mbox 檔案中。

傳送修補程式

然後，您可以使用 git send-email 命令來傳送修補程式。例如：

git send-email --to devlist@example.org mbox

這個命令會將 mbox 檔案中的修補程式傳送到 devlist@example.org 郵件列表。

套用修補程式

當您收到一個修補程式時，您可以使用 git am 命令來套用它。例如：

git am /tmp/patches/*

這個命令會套用 /tmp/patches/ 目錄中的所有修補程式。

解決衝突

如果套用修補程式時發生衝突，您可以使用 git am --show-current-patch=diff 命令來檢視衝突的內容。然後，您可以手動解決衝突，並使用 git am --continue 命令來繼續套用修補程式。

內容解密

上述命令和步驟都是根據 Git 的郵件傳輸機制。以下是每個命令的詳細解釋：

  • git format-patch: 產生一個修補程式。
  • git send-email: 傳送修補程式。
  • git am: 套用修補程式。
  • git am --show-current-patch=diff: 檢視衝突的內容。
  • git am --continue: 繼續套用修補程式。

這些命令和步驟可以幫助您使用 Git 的郵件傳輸機制來分享和套用修補程式。

巧妙運用Git的三路合併解決Patch適用性問題

在分散式版本控制系統中，使用 patch 檔案分享和整合程式碼變更非常普遍。然而，當專案分支眾多，變更頻繁時，直接應用 patch 檔案可能會遇到問題，例如 patch 檔案無法正確套用或產生衝突。我曾經在一個大型專案中就遇到過這種情況，當時團隊成員提交的 patch 檔案根據不同的分支，導致我無法直接應用到我的分支上。

這個問題的核心在於 patch 檔案的適用性。傳統的 patch 檔案只包含變更內容，沒有記錄變更前的原始狀態資訊。因此，如果目標檔案的內容與 patch 檔案預期的原始狀態不一致，patch 應用就會失敗。

Git 提供了一個巧妙的解決方案：三路合併（three-way merge）。Git 生成的 patch 檔案包含額外的資訊，用於識別 patch 檔案適用的原始狀態。讓我們以一個 patch 檔案 0004-Add-X.patch 為例：

diff --git a/file b/file
index 35d242b..7f9826a 100644
---
 a/file
+++ b/file

在 diff --git 行之後，Git 增加了一行 index 35d242b..7f9826a 100644。這行資訊包含了 patch 檔案適用的原始狀態的 SHA1 雜湊值 35d242b。透過這個雜湊值，Git 可以精確地找到 patch 檔案適用的檔案版本。

$ git show 35d242b
A
B

如果儲存函式庫中存在這個版本的檔案，Git 就可以使用三路合併策略應用 patch 檔案。三路合併是指 Git 會比較 patch 檔案中的變更、目前檔案版本以及 patch 檔案適用的原始版本，從而更準確地應用變更。

以下示範如何使用 git am -3 命令應用一系列 patch 檔案：

# 清除先前的 git am 狀態
$ rm -rf.git/rebase-apply/

# 回到起始 commit A
$ git reset --hard 11200ff

# 使用 -3 選項應用 patch 檔案
$ git am -3 /tmp/patches/*

如果 patch 檔案應用過程中發生衝突，Git 會暫停 git am 命令，並提示你解決衝突。解決衝突後，使用 git add 標記已解決的檔案，然後使用 git am --continue 繼續應用 patch 檔案。

使用 git am -3 命令可以有效地解決 patch 檔案的適用性問題，即使 patch 檔案根據不同的分支，也能夠正確地應用變更。

Patch 檔案的缺陷與合併策略的比較

儘管 patch 檔案在程式碼分享和整合中扮演著重要的角色，但它也存在一些缺陷。例如，郵件傳輸過程中可能發生的換行問題會導致 patch 檔案損壞。此外，patch 檔案的格式也可能與不同的工具不相容，導致應用失敗。

相較於 patch 檔案，Git 的合併（merge）功能提供了更強大與更可靠的程式碼整合方式。合併功能可以自動處理分支之間的程式碼變更，並有效地解決衝突。現代 Git 平台提供豐富的功能，可以無縫地整合分散式儲存函式庫中的程式碼變更，並確保所有開發者都能夠同步最新的程式碼。

儘管如此，patch 檔案仍然有其應用價值。在某些情況下，例如無法直接存取遠端儲存函式庫時，patch 檔案仍然是一種有效的程式碼分享方式。Git 也能夠很好地處理 patch 檔案和合併功能的混合使用，即使提交的程式碼來自不同的儲存函式庫，Git 也能透過比較內容來正確地整合變更。

內容解密：程式碼範例解析

以下程式碼片段展示瞭如何使用 git log 命令檢視提交歷史：

$ git log --graph --oneline

這行程式碼會以圖形化方式顯示提交歷史，並只顯示每條提交的簡短資訊。--graph 選項會以圖形方式顯示分支和合併的關係，--oneline 選項則會將每條提交的資訊顯示在一行。

另一個常用的 git log 命令選項是 --pretty=fuller，它會顯示更詳細的提交資訊，包括作者、提交日期等：

$ git log --pretty=fuller -1 a9e1a1b

這行程式碼會顯示提交 a9e1a1b 的詳細資訊， -1 選項表示只顯示一條提交記錄。

透過以上說明，希望能幫助你更好地理解 Git 中 patch 檔案的應用和三路合併策略，以及如何使用 git log 命令檢視提交歷史。

淺談 Git Hooks 的應用與實務

Git Hooks 允許我們微調標準的 Git 操作，在特定的事件（例如提交或應用補丁）發生時，執行自定義指令碼。這為開發流程的自動化和客製化提供了強大的機制。

Hooks 的型別與安裝

Hooks 分為客戶端和伺服器端兩種。客戶端 Hooks 在本地倉函式庫中執行，而伺服器端 Hooks 則在遠端倉函式庫中執行。大多數 Git Hooks 又可歸類別為 “pre” 和 “post” 兩種：

  • “pre” Hooks： 在動作完成前執行，可用於在變更套用前進行審核、拒絕或調整。例如，pre-commit hook 可用於在提交前執行程式碼風格檢查。
  • “post” Hooks： 在動作完成後執行，可用於觸發通知（例如電子郵件）或啟動其他處理，例如執行構建或關閉 bug。post-receive hook 常用於自動佈署程式碼。

Hooks 本質上是指令碼，位於倉函式庫的 .git/hooks 目錄下。Git 並不會在倉函式庫之間複製 Hooks，因此需要自行設定。

Hooks 的使用注意事項

雖然 Hooks 功能強大，但使用時仍需謹慎。Hooks 會改變 Git 的標準行為，如果指令碼存在錯誤，可能會干擾工作流程。此外，Hooks 的執行可能會降低 Git 操作的速度，例如在 pre-commit hook 中執行大量的測試可能會導致提交變慢。

Hooks 並非版本控制的一部分，因此不會自動在團隊成員之間同步。這需要額外的機制來確保所有開發者都使用相同的 Hooks。

Hooks 的合理使用場景

Hooks 最佳的應用場景是在無法透過其他方式實作相同結果時。例如，以下幾種情況適合使用 Hooks：

  • 強制執行程式碼風格： 在提交前使用 pre-commit hook 執行程式碼風格檢查，確保所有提交的程式碼都符合規範。
  • 自動化佈署： 在推播到遠端倉函式庫後使用 post-receive hook 觸發自動化佈署流程。
  • 整合外部系統： 使用 Hooks 與 bug 追蹤系統、CI/CD 平台等整合，實作更自動化的開發流程。

建立簡單的 Git Hook

以下是如何建立一個簡單的 pre-commit hook 的示例：

  1. 在 .git/hooks 目錄下建立一個名為 pre-commit 的檔案。
  2. 將以下程式碼複製到檔案中：
#!/bin/sh

echo "This is a pre-commit hook"
exit 0
  1. 設定檔案的可執行許可權：
chmod +x.git/hooks/pre-commit

現在，每次提交前都會執行這個指令碼，並輸出 “This is a pre-commit hook”。

Hooks 的實務應用與例項

  • 程式碼品品檢查： 使用 pre-commit hook 執行程式碼風格檢查、靜態分析等，提升程式碼品質。
  • 自動化測試： 在 pre-push hook 中執行單元測試，確保推播到遠端倉函式庫的程式碼沒有問題。
  • 自動生成檔案： 在 post-commit hook 中自動生成檔案，保持檔案與程式碼同步。

透過以上說明和例項，可以幫助讀者更好地理解和應用 Git Hooks，以提升開發效率和程式碼品質。

本文詳細介紹瞭 Git 中如何運用三路合併解決 patch 適用的問題，以及 Git Hooks 的應用與實務。同時，也提供瞭相關例項和 Plantuml 圖表，以便讀者能夠快速掌握相關知識並將其運用於實際開發中。

玄貓帶你理解 Git Hooks：開發自動化開發流程

Git Hooks 是 Git 中的一個強大功能，允許開發者在 Git 操作的不同階段執行自定義的指令碼。這些指令碼可以用於自動化各種任務，例如程式碼檢查、測試、佈署等。

Git Hooks 入門：基礎概念與實作

每個 Hook 指令碼都以其關聯的事件命名。例如，在 git commit 操作執行前觸發的 Hook 名為 .git/hooks/pre-commit。Hook 指令碼必須遵循 Unix 指令碼的規則：它必須是可執行的（chmod a+x.git/hooks/pre-commit），並且必須以一行指示指令碼編寫語言的 shebang 開頭（例如 #!/bin/bash 或 #!/usr/bin/perl）。

當特定名稱和許可權的 Hook 指令碼存在時，Git 會自動執行它。

探索預裝 Hook

根據 Git 版本的不同，在建立新的儲存函式庫時，你可能會在 .git/hooks 目錄下找到一些預裝的 Hook 範例。這些範例指令碼通常以 .sample 作為副檔名，需要重新命名才能啟用。

$ mkdir hooks-sample && cd hooks-sample
$ git init -b main
$ tree.git/hooks
.git/hooks
├── applypatch-msg.sample
├── commit-msg.sample
├── fsmonitor-watchman.sample
├── post-update.sample
├── pre-applypatch.sample
├── pre-commit.sample
├── pre-merge-commit.sample
├── pre-push.sample
├── pre-rebase.sample
├── pre-receive.sample
├── prepare-commit-msg.sample
├── push-to-checkout.sample
└── update.sample

0 directories, 12 files

要啟用某個 Hook，只需移除 .sample 副檔名即可（例如 mv.git/hooks/pre-commit.sample.git/hooks/pre-commit）。

建立你的第一個 Hook

讓我們建立一個 pre-commit Hook，用於在提交程式碼前檢查程式碼中是否包含特定字串。

# 建立 Hook 指令碼
$ touch.git/hooks/pre-commit

使用你喜歡的編輯器，將以下程式碼新增到 .git/hooks/pre-commit 檔案中：

#!/bin/bash

# 檢查程式碼中是否包含 "FIXME" 字串
if git diff --cached | grep '^\+' | grep -q 'FIXME'; then
  echo "錯誤：程式碼中包含 FIXME，請修正後再提交！" >&2
  exit 1 # 拒絕提交
fi

exit 0 # 允許提交

內容解密：

這段指令碼會檢查即將提交的程式碼改動中，是否有新增的行包含 “FIXME” 字串。如果找到，則會印出錯誤訊息並阻止提交。git diff --cached 命令顯示暫存區和上次提交之間的差異，grep '^\+' 篩選出新增的行，grep -q 'FIXME' 檢查是否包含 “FIXME” 字串。

設定指令碼為可執行：

$ chmod a+x.git/hooks/pre-commit

現在，當你嘗試提交包含 “FIXME” 的程式碼時，提交操作將會被阻止。

$ echo "This is a test with FIXME" > test.txt
$ git add test.txt
$ git commit -m "Add test file"
錯誤：程式碼中包含 FIXME，請修正後再提交！

Git Hooks 的型別與應用

Git 提供了許多不同型別的 Hooks，涵蓋了提交、推播、合併等各種 Git 操作。以下列出一些常用的 Hook：

  • pre-commit：在提交前執行，可用於程式碼檢查、執行測試等。
  • commit-msg：在提交訊息編輯後執行，可用於檢查提交訊息格式。
  • pre-push：在推播前執行，可用於執行最終測試或檢查程式碼品質。
  • post-receive：在遠端儲存函式庫接收推播後執行，可用於觸釋出署流程。

透過這些 Hooks，我們可以根據專案需求定製各種自動化流程，提升開發效率和程式碼品質。

圖表說明： 此流程圖展示了使用 Git Hooks 進行程式碼檢查和測試的自動化流程。在提交和推播程式碼之前，分別執行程式碼檢查和測試，確保程式碼品質。

善用 Git Hooks，能讓你的開發流程更加順暢高效，同時也能夠有效提升團隊協作和程式碼品質。從程式碼風格檢查到自動化佈署，Git Hooks 提供了無限的可能性，等待你去探索和發掘。

深入解析 Git Submodules：模組化專案的利器

在軟體開發過程中，我們經常會遇到許多應用程式依賴同一個程式函式庫或一組程式函式庫的情況。理想情況下，每個應用程式都應該在獨立的 Git 儲存函式庫中開發、分享、分支和合併，這樣做更符合邏輯上的分離，也更易於程式碼的管理。

然而，這種分離式開發也帶來了新的挑戰：每個應用程式都依賴特定版本的分享程式函式庫，我們需要精確追蹤這些版本。如果不小心將程式函式庫升級到未經測試的版本，可能會導致應用程式當機。此外，程式函式庫本身也在不斷演進，開發者會根據自身應用程式的需求新增功能，最終再將這些新功能分享給其他應用程式使用。

傳統的解決方案，例如部分複製、直接匯入程式碼或將程式函式庫複製到專案子資料夾，都存在一定缺陷。Git 提供了更優雅的解決方案：Submodules。

Gitlinks：指向其他儲存函式庫的橋樑

Submodule 的核心機制是 gitlink。gitlink 是樹物件到提交物件的連結。每個提交物件指向一個樹物件，而每個樹物件指向一組 blob 和樹，分別對應檔案和子目錄。提交的樹物件唯一標識了與該提交關聯的檔案、檔名和許可權。提交物件本身在有向無環圖 (DAG) 中相互連線，每個提交物件指向零個或多個父提交，共同描述了專案的歷史記錄。

gitlink 允許樹物件指向提交物件，從而實作對其他儲存函式庫的參照。以下範例說明瞭如何使用 git submodule add 命令將一個儲存函式庫作為 submodule 匯入到另一個儲存函式庫中：

$ git submodule add https://github.com/example/library.git lib/library

這個命令會將 https://github.com/example/library.git 儲存函式庫匯入到當前儲存函式庫中的 lib/library 目錄，並建立一個 gitlink 連結到指定的提交版本。

管理 Submodules

一旦 submodule 被加入到你的儲存函式庫中，你就可以像管理普通檔案一樣管理它。你可以對 submodule 執行各種 Git 命令，如 git status、git add、git commit 等。

然而，由於 submodule 是一個獨立的儲存函式庫，你需要小心管理它們之間的版本依賴關係。你可以使用 git submodule update 命令更新 submodule 到最新版本，也可以使用 git submodule foreach 命令對所有 submodule 執行特定命令。

$ git submodule update --remote
$ git submodule foreach git pull origin main

Git Submodule：管理專案依賴的利器

Git submodule 是一個強大的工具，能夠有效地管理專案中的外部依賴。它允許我們將其他 Git 倉函式庫作為子模組嵌入到主專案中，精確記錄了父專案提交歷史中每個子模組的狀態。

新增 Submodule

使用 git submodule add 命令可以輕鬆地將外部倉函式庫新增為子模組。Git 會自動建立 .gitmodules 檔案和一個包含子模組檔案的子目錄。

git submodule add https://github.com/your-username/your-submodule.git

初始化 Submodule

克隆包含子模組的倉函式庫時，子模組目錄預設是空的。需要使用 git submodule update --init 或 git submodule update --init --recursive 來初始化子模組。

git clone --recurse-submodules <superproject_url> <superproject_directory>

修改 Submodule

在主專案中修改子模組的檔案與在任何 Git 倉函式庫中修改檔案的方式相同。需要注意的是，使用 --recurse-submodules 克隆或使用 git submodule update 更新子模組後，子模組會處於 detached HEAD 狀態。

cd <submodule_directory>
git checkout main
# 修改子模組檔案
git add.
git commit -m "Update submodule"
git push

更新 Submodule

更新超級專案的子模組專案有兩種方法。一種是透過標準的 Git fetch 操作，然後執行 merge 操作。另一種方法是使用 git submodule update --remote 指令。

git submodule update --remote
內容解密：Submodule 的版本控制

子模組的版本控制與主專案相互獨立。當我們提交主專案的變更時，Git 只會記錄子模組的提交 ID，而不會記錄子模組的完整歷史記錄。

流程圖解：新增 Submodule 的步驟

流程圖解：修改 Submodule 的步驟

視覺化 Submodule 結構

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Git 差異比較與版本控制技巧

package "Git 版本控制" {
    package "工作區域" {
        component [工作目錄
Working Directory] as work
        component [暫存區
Staging Area] as stage
        component [本地倉庫
Local Repository] as local
        component [遠端倉庫
Remote Repository] as remote
    }

    package "基本操作" {
        component [git add] as add
        component [git commit] as commit
        component [git push] as push
        component [git pull] as pull
    }

    package "分支管理" {
        component [git branch] as branch
        component [git merge] as merge
        component [git rebase] as rebase
    }
}

work --> add : 加入暫存
add --> stage : 暫存變更
stage --> commit : 提交變更
commit --> local : 版本記錄
local --> push : 推送遠端
remote --> pull : 拉取更新
branch --> merge : 合併分支

note right of stage
  git status 查看狀態
  git diff 比較差異
end note

@enduml

這個圖表展示了超級專案和其 submodule 的關係。超級專案包含一個檔案 sp-readme.md 和一個名為 git 的 submodule。git submodule 是一個指向外部 Git 儲存函式庫特定提交的連結。

Git 子模組與 subtree 的差異：深度解析

在 Git 中，子模組（submodule）和 subtree 是兩種不同的方式，用於管理多個專案之間的關係。這兩種方法各有其優缺點，本文將對它們進行深度比較。

子模組（Submodule）

子模組是一種方式，允許您將一個 Git 專案作為另一個專案的子目錄嵌入。這意味著您可以在主專案中包含另一個專案的程式碼和歷史記錄，而不需要將它們合併到同一個倉函式庫中。子模組的優點包括：

  1. 彈性: 子模組允許您將不同部分的程式碼存放在不同的倉函式庫中，使得合作和維護變得更加容易。
  2. 歷史記錄: 子模組保留了原來專案的歷史記錄，這對於追蹤變更和合作至關重要。

但是，子模組也有其缺點：

  1. 複雜性: 子模組可能使您的專案結構變得複雜，因為您需要管理多個不同的倉函式庫和分支。
  2. 同步: 子模組需要手動同步，這可能會導致版本衝突和其他問題。

Subtree

Subtree 是另一種管理多個專案關係的方式。它允許您將一個 Git 專案的程式碼和歷史記錄直接嵌入到另一個專案中。Subtree 的優點包括：

  1. 簡潔性: Subtree 比子模組更簡潔，因為它不需要額外的倉函式庫和分支。
  2. 易於管理: Subtree 可以更容易地管理，因為所有程式碼都存在於同一個倉函式庫中。

但是，Subtree 也有一些缺點：

  1. 歷史記錄: Subtree 合併了兩個專案的歷史記錄，這可能會使歷史記錄變得混亂和難以追蹤。
  2. 可讀性: Subtree 可能會使您的倉函式庫變得過大和難以管理，因為所有程式碼都混合在一起。
玄貓 BlackCat

玄貓 BlackCat

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