3招搞定！保持清潔的Git提交記錄

這篇文章為大家帶來了關於保持清潔的Git提交記錄的相關知識，其中包括了「git commit –amend」、「git rebase -i」和「rebase」的相關問題，希望對大家有幫助。

推薦學習：《Git教學》

大家都有學習如何規範簡潔的 寫程式碼 ，但卻很少學習如何規範簡潔的 提交程式碼 。現在大家基本上都用Git 作為原始碼管理的工具，Git 提供了極大的彈性，我們按照各種workflow 來提交/合併code，這種彈性把控不好，也會帶來很多問題

最常見的問題就是亂成一團的git log history，那真的是老太太的裹腳布, 又臭又長, 個人極其不喜歡這種log

造成這個問題的根本原因就是隨意提交程式碼。

程式碼都提交了，那還有什麼辦法可以拯救嗎？三個錦囊，就可以完美解決了

善用git commit –amend

這個指令的幫助文件是這樣描述的：

--amend               amend previous commit

也就是說，它可以幫我們修改 最後一次提交

既可以修改我們提交的message，又可以修改我們提交的文件，最後還會替換最後一個commit-id

我們可能會在某次提交的時候遺漏了某個文件，當我們再次提交就可能會多處一個無用的commit-id，大家都這樣做，git log 慢慢就會亂得無法追踪完整功能了

假設我們有這樣一段log 訊息

* 98a75af (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

假設我們要修改最後一個log message，就可以使用下面命令：

git commit --amend -m "feat: [JIRA123] add feature 1.2 and 1.3"

我們再來看一下log 資訊, 可以發現，我們用新的commit-id 5e354d1 替換了舊的commit-id 98a75af , 修改了message，並沒有增加節點

* 5e354d1 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

現在我們的repo 中文件是這樣的：

假設我們提交 feature 1.3 的時候，忘記了一個設定檔 config.yaml , 不想修改log，不想新增新的commit-id，那下面的這個指令就非常好用了

.
├── README.md
└── feat1.txt

0 directories, 2 files

git commit -- amend --no-edit 就是靈魂所在了，來看看目前的repo 檔案：

echo "feature 1.3 config info" > config.yaml
git add .
git commit --amend --no-edit

再來看git log

.
├── README.md
├── config.yaml
└── feat1.txt

0 directories, 3 files

知道這個技巧，就可以確保我們的每次提交都包含有效的資訊了。一張圖描述這個過程就是這個樣子了：

有了 --no-edit 的buff 加成，威力更大一點

善用git rebase -i

可以看著，上面的log 都是在開發feature1，我們在把feature 分支merge 到main 分支之前，還是應該繼續合併log commit 節點的，這就用到了

* 247572e (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1.2 and 1.3
* 119f86e feat: [JIRA123] add feature 1.1
* 5dd0ad3 feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

其中n 代表最後幾個提交，上面我們針對feature 1 有三個提交，所以就可以使用：

git rebase -i HEAD~n

運行後，會顯示一個vim 編輯器，內容如下：

git rebase -i HEAD~3

合併commit-id 最常用的是 squash 和 fixup , 前者包含commit message，後者不包含，這裡使用fixup, 然後 :wq 退出

 1 pick 5dd0ad3 feat: [JIRA123] add feature 1
 2 pick 119f86e feat: [JIRA123] add feature 1.1
 3 pick 247572e feat: [JIRA123] add feature 1.2 and 1.3
 4
 5 # Rebase c69f53d..247572e onto c69f53d (3 commands)
 6 #
 7 # Commands:
 8 # p, pick <commit> = use commit
 9 # r, reword <commit> = use commit, but edit the commit message
10 # e, edit <commit> = use commit, but stop for amending
11 # s, squash <commit> = use commit, but meld into previous commit
12 # f, fixup <commit> = like "squash", but discard this commit's log message
13 # x, exec <command> = run command (the rest of the line) using shell
14 # d, drop <commit> = remove commit
15 # l, label <label> = label current HEAD with a name
16 # t, reset <label> = reset HEAD to a label
17 # m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
18 # .       create a merge commit using the original merge commit's
19 # .       message (or the oneline, if no original merge commit was
20 # .       specified). Use -c <commit> to reword the commit message.
21 #
22 # These lines can be re-ordered; they are executed from top to bottom.
23 #
24 # If you remove a line here THAT COMMIT WILL BE LOST.
25 #
26 #   However, if you remove everything, the rebase will be aborted.
27 #
28 #
29 # Note that empty commits are commented out</commit></oneline></label></commit></commit></label></label></commit></command></commit></commit></commit></commit></commit>

我們再來看一下log, 這就非常清晰了

1 pick 5dd0ad3 feat: [JIRA123] add feature 1
2 fixup 119f86e feat: [JIRA123] add feature 1.1
3 fixup 247572e feat: [JIRA123] add feature 1.2 and 1.3

善用rebase

上面的feature1 已經完整地開發完了，main 分支也有了其他人的更新，再將feature merge 回main 分支之前，以防程式碼有衝突，需要先將main 分支的內容合併到feature 中，如果用merge 指令，就會多處一個merge 節點，log history 中也會出現拐點，並不是線性的，所以這裡我們可以在feature 分支上使用rebase 指令

* 41cd711 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* c69f53d (origin/main, origin/feature/JIRA123-amend-test, origin/HEAD, main) Initial commit

pull 指令的背後是自動幫我們做merge 的，但是這裡以rebase 的形式，再來看一下log

git pull origin main --rebase

我們的feature1 功能 on top of main 的提交節點，還是保持線性，接下來就可以push 程式碼，然後提PR，將你的feature merge 到main 分支了

簡單描述merge 和rebase 的區別就是這樣的：

我在這裡使用 git pull origin main --rebase 省略了切換main 並拉取最新內容再切回來的過程，一步到位，背後的原理都是上圖展示的這樣

使用rebase 是要遵守一個黃金法則的，這個之前有說過，就不再是贅述了

總結

有了這三個錦囊，相信大家的git log 都無比的清晰，如果你還不知道，完全可以用起來，如果你的組內成員不知道，你完全可以推廣起來，這樣的repo 看起來才更健康

#推薦學習：《Git教程》

#

以上是3招搞定！保持清潔的Git提交記錄的詳細內容。更多資訊請關注PHP中文網其他相關文章！