git log 命令是檢視提交歷史的核心工具，能幫助開發者精確追蹤程式碼的演變過程。藉由指定起始提交點或特定提交的 SHA-1 雜湊值，可以精準控制輸出範圍，例如使用 git log main -2 顯示 main 分支的最新兩次提交。對於大型專案，可運用 since..until 語法指定提交區間，或使用 -n 引數限制顯示數量，避免資訊過載。此外，--pretty 選項能客製化輸出格式，而 --graph 選項則以圖形方式呈現提交歷史，清晰展現分支與合併的關係，有助於理解專案的發展脈絡。
掌握 Git 的精髓：版本控制的現代藝術：解析 Git 提交歷史：從線性檢視到圖形化呈現
解析 Git 提交歷史：從線性檢視到圖形化呈現
深入理解 Git 的提交歷史對於有效管理程式碼版本至關重要。我發現，清晰地掌握提交歷史，能幫助開發者快速定位問題、追蹤程式碼演變，並有效地進行協作開發。本文將引導你探索如何有效地瀏覽和理解 Git 提交歷史，從基本的線性檢視到更直觀的圖形化呈現。
利用 git log 精準定位提交記錄
git log 命令是檢視提交歷史的基礎工具。透過指定起始提交點，例如分支名稱或特定提交的 SHA-1 雜湊值，可以精確地控制輸出範圍。例如，git log main -2 將顯示 main 分支上的最新兩次提交。
$ git log main -2
commit 30cc8d0f147546d4dd77bf497f4dec51e7265bd8 (HEAD -> main,...)
Author: Junio C Hamano <[email protected]>
Date: Sat Jul 2 17:01:34 2022 -0700
A regression fix for 2.37
Signed-off-by: Junio C Hamano <[email protected]>
commit 0f0bc2124b25476504e7215dc2af92d5748ad327
Merge: e4a4b31577 4788e8b256
Author: Junio C Hamano <[email protected]>
Date: Sat Jul 2 21:56:08 2022 -0700
Merge branch 'js/add-i-delete'
Rewrite of "git add -i" in C that appeared in Git 2.25 didn't
correctly record a removed file to the index, which was fixed.
* js/add-i-delete:
add --interactive: allow `update` to stage deleted files
內容解密：
這段程式碼示範瞭如何使用 git log 命令檢視 main 分支上的最新兩個提交記錄。每個提交記錄包含提交雜湊值、作者、日期和提交訊息。其中，-2 引數指定了顯示的提交數量。
縮小範圍：提交區間與數量限制
對於大型專案，完整的提交歷史可能龐大而難以分析。透過指定提交區間或限制顯示數量，可以更有效地瀏覽相關的提交記錄。
使用 since..until 語法可以指定提交區間。例如，git log main~9..main~7 將顯示 main 分支上倒數第 9 次到倒數第 7 次之間的提交。-n 引數則可以限制顯示的提交數量，例如 git log -3 只顯示最近三次提交。
$ git log --pretty=short --abbrev-commit main~9..main~7
commit be7935ed8b
Author: Junio C Hamano <[email protected]>
Merged the open-eintr workaround for macOS
commit 58d581c344
Author: Elijah Newren <[email protected]>
Documentation/RelNotes: improve release note for rename detection work
內容解密：
這段程式碼示範瞭如何使用 git log 命令搭配 --pretty=short 和 --abbrev-commit 選項來簡化輸出，並使用 main~9..main~7 語法指定提交區間。
格式化輸出：客製化顯示資訊
--pretty 選項可以控制提交資訊的顯示格式。常用的選項包括 oneline、short、medium 和 full 等。--abbrev-commit 選項可以縮短提交雜湊值的長度。更進一步地，可以使用 --pretty=format 選項來自定義輸出格式。
$ git log --pretty=format:"%an was the author of commit %h, %ar with%nthe commit titled: [%s]%n" --abbrev-commit main~9..main~7
Junio C Hamano was the author of commit be7935ed8b, 12 days ago with
the commit titled: [Merged the open-eintr workaround for macOS]
Elijah Newren was the author of commit 58d581c344, 12 days ago with
the commit titled: [Documentation/RelNotes: improve release note for rename detection work]
內容解密：
這段程式碼示範瞭如何使用 --pretty=format 選項來自定義 git log 的輸出格式。 %an、 %h、 %ar 和 %s 分別代表作者姓名、提交雜湊值、提交日期和提交標題。
圖形化顯示：視覺化分支與合併
--graph 選項可以以圖形方式顯示提交歷史，清晰地展現分支和合併的關係。這對於理解專案的發展脈絡非常有幫助。
$ git log --oneline --graph 89d21f4b649..0a02ce72d9
* 0a02ce7 Clean up the Makefile a bit.
* 839a7a0 Add the simple scripts I used to do a merge with content conflicts.
* b51ad43 Merge the new object model thing from Daniel Barkalow
|\
| * b5039db [PATCH] Switch implementations of merge-base, port to parsing
| * ff5ebe3 [PATCH] Port fsck-cache to use parsing functions
| * 5873b67 [PATCH] Port rev-tree to parsing functions
| * 175785e [PATCH] Implementations of parsing functions
| * 6eb8ae0 [PATCH] Header files for object parsing
* | a4b7dbe [PATCH] fix bug in read-cache.c which loses files when merging...
* | 1bc992a [PATCH] Fix confusing behaviour of update-cache --refresh on...
* | 6ad6d3d Update README to reflect the hierarchical tree objects...
* | 64982f7 [PATCH] (resend) show-diff.c off-by-one fix
* | 75118b1 Pass a "merge-cache" helper program to execute a merge on...
* | 74b2428 [PATCH] fork optional branch point normazilation
* | d9f98ee Ignore any unmerged entries for "checkout-cache -a".
* | 5e5128e Remove extraneous ',' ';' and '.' characters from...
* | 08ca0b0 Make the revision tracking track the object types too.
* | d0d7cbe Make "commit-tree" check the input objects more carefully.
* | 7d60ad7 Make "parse_commit" return the "struct revision" for the commit.
|/
* 6683463 Do a very simple "merge-base" that finds the most recent...
* 15000d7 Make "rev-tree.c" use the new-and-improved "mark_reachable()"
* 01796b0 Make "revision.h" slightly better to use.
內容解密：
這段程式碼示範瞭如何使用 --graph 和 --oneline 選項以圖形化方式顯示提交歷史，並簡化每條提交的輸出訊息。 * 代表提交節點， |\ 和 |/ 等符號表示分支和合併關係。
透過靈活運用這些技巧，開發者可以更有效地探索 Git 提交歷史，從而更好地理解程式碼演變，提升開發效率。
上圖總結了 git log 命令的常用用法，希望能幫助你快速掌握這些技巧。
淺談 Git 的提交圖譜與提交範圍
在 Git 的世界裡，理解提交圖譜和提交範圍對於有效管理專案版本歷史至關重要。我將透過圖表和實際案例，深入淺出地解釋這些概念，並分享一些我在實務中獲得的經驗和技巧。
提交圖譜：專案歷史的藍圖
提交圖譜以視覺化的方式呈現專案的提交歷史，就像專案發展的藍圖。每個提交都被視為一個節點，而節點之間的連線則代表提交之間的父子關係。
上圖展現了一個典型的提交圖譜，其中：
- A 是根提交，沒有父節點。
- H 是一個合併提交，擁有兩個父節點 D 和 G。
- A、B、C、D 構成了
main分支。 - A、B、E、F、G 構成了
pr-17分支。
內容解密：
這個圖譜清晰地展示了分支的建立和合併過程。 pr-17 分支從 B 節點分出，最終合併到 main 分支的 H 節點。
在實際應用中，提交圖譜通常會簡化方向箭頭，因為父子關係可以根據時間順序推斷出來。
Git 版本控制系統：玄貓的深度剖析
Git 是目前最廣泛使用的版本控制系統，它能夠有效地管理和跟蹤軟體開發中的程式碼變動。作為一名開發者，掌握 Git 的基礎知識和高階技巧是非常重要的。本文將對 Git 版本控制系統進行深度剖析，涵蓋基本概念、版本控制流程、分支管理、遠端倉函式庫操作等。
Git 基本概念
Git 是一個分散式版本控制系統，允許多個開發者在不同的時間和地點合作一個專案。它使用 SHA-1 雜湊演算法來識別和追蹤每個版本的變動。
工作目錄、索引和儲存函式庫
Git 中的工作目錄（Working Directory）是用來存放程式碼檔案的地方；索引（Index）則是一個暫存區，存放即將提交的變動；而儲存函式庫（Repository）則是所有版本的儲存地方。
Git 物件
Git 中的物件包括 Blob、Tree、Commit 和 Tag。其中，Blob 對應著檔案內容；Tree 則代表著目錄結構；Commit 代表著一次提交操作；而 Tag 則是一個參照某次提交的標籤。
Git 版本控制流程
- 初始化倉函式庫：使用
git init命令建立一個新的 Git 倉函式庫。 - 新增檔案：使用
git add命令將變動新增到索引中。 - 提交變動：使用
git commit命令將索引中的變動提交到倉函式庫中。 - 檢視狀態：使用
git status命令檢視當前工作目錄和索引的狀態。 - 檢視提交歷史：使用
git log命令檢視提交歷史。
分支管理
分支是 Git 中的一個重要概念，允許開發者建立不同的分支來實作平行開發。分支管理涉及建立分支、切換分支、合併分支等。
建立分支
使用 git branch 命令建立新的分支。
$ git branch feature/new-feature
切換分支
使用 git checkout 命令切換到指定分支。
$ git checkout feature/new-feature
合併分支
使用 git merge 命令合併兩個分支。
$ git checkout main
$ git merge feature/new-feature
遠端倉函式庫操作
Git 支援遠端倉函式庫的操作，允許開發者與團隊成員分享和同步程式碼。遠端倉函式庫操作涉及新增遠端倉函式庫、推播變動、提取變動等。
新增遠端倉函式庫
使用 git remote add 命令新增遠端倉函式庫。
$ git remote add origin https://github.com/user/repository.git
推播變動
使用 git push 命令推播本地變動到遠端倉函式庫。
$ git push origin main
提取變動
使用 git pull 命令提取遠端倉函式庫中的變動到本地。
$ git pull origin main
Git版本控制系統：索引機制與檔案管理技巧
Git版本控制系統是一種強大的工具，讓開發者能夠有效地管理專案中的檔案版本。其中，索引（Index）扮演著至關重要的角色，它就像一個暫存區，儲存著你即將提交到儲存函式庫的檔案變更。理解索引機制對於有效使用Git至關重要。
Git索引的運作方式
當你使用git add指令將檔案加入索引時，Git會將檔案的完整內容複製到物件儲存函式庫中，並以其產生的SHA1名稱進行索引。暫存檔案也稱為快取檔案。
$ git add data
$ git ls-files --stage
100644 0487f44090ad950f61955271cf0a2d6c6a83ad9a 0.gitignore
100644 e476983f39f6e4f453f0fe4a859410f63b58b500 0 data
在上述例子中，data檔案已被加入索引，並且其SHA1雜湊值已被計算。
檔案的移除、更名與忽略
在軟體開發過程中，檔案的管理至關重要。Git提供了強大的檔案管理功能，讓你能有效地追蹤、修改和組織專案中的檔案。
移除檔案
移除檔案看似簡單，但使用錯誤的指令可能會造成困擾。git rm --cached雖然可以讓檔案維持在工作目錄中，但卻會使其脫離Git的版本控制。
$ git rm data
rm 'data'
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: data
檔案更名
更名檔案時，你可以使用git rm和git add的組合，或者直接使用git mv。
$ git mv data mydata
$ git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed: data -> mydata
忽略檔案
忽略檔案是指不想讓Git追蹤某些檔案或目錄。你可以在.gitignore檔案中指定要忽略的檔案或目錄。
$ echo "main.o" >.gitignore
$ git status
On branch main
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
.gitignore
data
在上述例子中，main.o檔案已被加入.gitignore檔案中，因此Git不會追蹤它。
程式碼範例解析
以下是程式碼範例：
$ git init
Initialized empty Git repository in /path/to/repo/.git/
$ touch data
$ git add data
$ git commit -m "Initial commit"
[master (root-commit) 4b5f3b6] Initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 data
$ git rm data
rm 'data'
$ git commit -m "Remove data file"
[master c45a5c8] Remove data file
1 file changed, 0 deletions(-)
delete mode 100644 data
在這個範例中，我們建立了一個新的Git儲存函式庫，新增了一個data檔案，提交了變更，然後移除data檔案並提交了變更。
透過理解Git索引的運作機制和檔案管理技巧，你可以更有效地管理專案中的檔案版本，並確保版本控制的準確性。
Git 合併衝突的成因、解決方法與預防策略
在 Git 中，合併衝突（Conflict）發生是在不同分支對同一檔案進行修改時，由於版本控制系統無法自動決定保留哪一份修改，因此需要人工介入以解決這種狀況。下面，我們將探討 Git 合併衝突的成因、解決方法以及預防策略。
成因：不同分支對同一檔案的修改
當兩個分支（例如 master 和 feature）同時修改了同一個檔案的相同部分時，就會發生合併衝突。Git 會在合併過程中停下，並通知使用者處理衝突。
解決方法：手動修復與選擇保留
當 Git 發現合併衝突時，它會標記出衝突的檔案，並在檔案內插入特殊標記以顯示衝突部分。使用者需要手動檢視和修復這些衝突，然後提交修復後的結果。
以下是一個簡單的步驟：
- 標記衝突檔案：Git 會標記出有衝突的檔案，使用
git status可以看到哪些檔案有問題。 - 編輯與修復：開啟有衝突的檔案，Git 會在檔案中新增
<<<<<<<、=======和>>>>>>>等標記以指示哪些部分有衝突。你需要手動決定要保留哪些修改。 - 提交修復結果：修復完成後，使用
git add將修復好的檔案加入索引，然後使用git commit提交修復結果。
預防策略：溝通、定期合併和小步提交
雖然無法完全避免合併衝突，但透過一些策略可以減少其發生的機率：
- 溝通：團隊成員應該瞭解彼此的工作內容，以避免同時修改相同的檔案。
- 定期合併：定期將最新的主分支（通常是
master）合併到開發分支中，可以提早發現並解決潛在的衝突。 - 小步提交：盡可能地將大功能拆分成多個小功能，並分次提交，可以降低每次合併的複雜度和潛在衝突。
實際案例
假設有一個開源專案，其中有一個檔案名為 main.py，它包含了整個應用程式的入口點。兩個開發者，Alice 和 Bob，各自從主分支（master）建立了自己的開發分支（feature/alice 和 feature/bob），並各自對 main.py 進行了修改。當他們都完成了工作並嘗試將各自的分支合併回主分支時，因為修改了相同的行，因此就會產生合併衝突。
# 首先切換到 master 分支
git checkout master
# 將 Alice 的修改合併進來
git merge feature/alice
# 如果沒有衝突，可以順利合併
# 否則需要手動解決衝突
# 將 Bob 的修改合併進來
git merge feature/bob
# 同樣，如果沒有衝突，可以順利合併
# 否則需要手動解決衝突
在解決衝突時，你可能需要手動編輯 main.py 以決定保留哪些更改。
流程圖：
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title Git提交歷史解析與圖形化呈現
package "圖論網路分析" {
package "節點層" {
component [節點 A] as nodeA
component [節點 B] as nodeB
component [節點 C] as nodeC
component [節點 D] as nodeD
}
package "中心性指標" {
component [度中心性
Degree Centrality] as degree
component [特徵向量中心性
Eigenvector Centrality] as eigen
component [介數中心性
Betweenness Centrality] as between
component [接近中心性
Closeness Centrality] as close
}
}
nodeA -- nodeB
nodeA -- nodeC
nodeB -- nodeD
nodeC -- nodeD
nodeA --> degree : 計算連接數
nodeA --> eigen : 計算影響力
nodeB --> between : 計算橋接度
nodeC --> close : 計算距離
note right of degree
直接連接數量
衡量局部影響力
end note
note right of eigen
考慮鄰居重要性
衡量全局影響力
end note
@enduml
流程說明： 開發者進行程式碼修改 → Git偵測到衝突 → 手動解決衝突 → 提交解決結果 → 繼續開發。
掌握 Git 合併衝突處理技巧，不僅能夠讓你的開發流程更順暢，也能提升團隊合作效率，從而帶來更高效、更高品質的軟體開發成果。