猿猿有責,維持整潔的 Git 提交記錄,三個錦囊送給你

日拱一兵發表於2021-11-22

背景

大家都有學習如何規範簡潔的編寫程式碼,但卻很少學習如何規範簡潔的提交程式碼。現在大家基本上都用 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 中檔案是這樣的:

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

0 directories, 2 files

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

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

git commit --amend --no-edit 就是靈魂所在了,來看一下當前的 repo 檔案:

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

0 directories, 3 files

再來看一下 git log

* 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

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

有了 --no-edit 的 buff 加成,威力更大一些

善用 git rebase -i

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

git rebase -i HEAD~n

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

git rebase -i HEAD~3

執行後,會顯示一個 vim 編輯器,內容如下:

  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-id 最常用的是 squashfixup, 前者包含 commit message,後者不包含,這裡使用 fixup, 然後 :wq 退出

  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

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

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

善用 rebase

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

git pull origin main --rebase

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

* d40daa6 (HEAD -> feature/JIRA123-amend-test) feat: [JIRA123] add feature 1
* 446f463 (origin/main, origin/HEAD) Create main.properties
* c69f53d (origin/feature/JIRA123-amend-test, main) Initial commit

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

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

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

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

總結

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

接下來會介紹一個多分支切換互不影響的錦囊
個人部落格:https://dayarch.top
加我微信好友, 進群娛樂學習交流,備註「進群」

歡迎持續關注公眾號:「日拱一兵」

  • 前沿 Java 技術乾貨分享
  • 高效工具彙總 | 回覆「工具」
  • 面試問題分析與解答
  • 技術資料領取 | 回覆「資料」

以讀偵探小說思維輕鬆趣味學習 Java 技術棧相關知識,本著將複雜問題簡單化,抽象問題具體化和圖形化原則逐步分解技術問題,技術持續更新,請持續關注......


相關文章