0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

維持整潔的Git提交記錄

dyquk4xk2p3d ? 來源:良許Linux ? 2023-05-12 16:40 ? 次閱讀

	

	

	

	

背景

大家都有學(xué)習(xí)如何規(guī)范簡潔的編寫代碼,但卻很少學(xué)習(xí)如何規(guī)范簡潔的提交代碼?,F(xiàn)在大家基本上都用 Git 作為源碼管理的工具,Git 提供了極大的靈活性,我們按照各種 workflow 來提交/合并 code,這種靈活性把控不好,也會帶來很多問題

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

7c130554-f09b-11ed-90ce-dac502259ad0.png

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

代碼都提交了,那還有什么辦法拯救嗎?三個錦囊,就可以完美解決了

善用 git commit --amend

這個命令的幫助文檔是這樣描述的:

--amendamendpreviouscommit

也就是說,它可以幫助我們修改最后一次提交

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

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

假設(shè)我們有這樣一段 log 信息

*98a75af(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

假設(shè)我們要修改最后一個 log message,就可以使用下面命令:

gitcommit--amend-m"feat:[JIRA123]addfeature1.2and1.3"

我們再來看一下 log 信息, 可以發(fā)現(xiàn),我們用新的 commit-id5e354d1替換了舊的 commit-id98a75af, 修改了 message,并沒有增加節(jié)點

*5e354d1(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2and1.3
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

現(xiàn)在我們的 repo 中文件是這樣的:

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

0directories,2files

假設(shè)我們提交feature 1.3的時候,忘記了一個配置文件config.yaml, 不想修改 log,不想添加新的 commit-id,那下面的這個命令就非常好用了

echo"feature1.3configinfo">config.yaml
gitadd.
gitcommit--amend--no-edit

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

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

0directories,3files

再來看一下 git log

*247572e(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1.2and1.3
*119f86efeat:[JIRA123]addfeature1.1
*5dd0ad3feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

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

7c275ff4-f09b-11ed-90ce-dac502259ad0.png

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

善用 git rebase -i

可以看著,上面的 log 都是在開發(fā) feature1,我們在把 feature 分支 merge 到 main 分支之前,還是應(yīng)該繼續(xù)合并 log commit 節(jié)點的,這就用到了

gitrebase-iHEAD~n

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

gitrebase-iHEAD~3

運行后,會顯示一個 vim 編輯器,內(nèi)容如下:

1pick5dd0ad3feat:[JIRA123]addfeature1
2pick119f86efeat:[JIRA123]addfeature1.1
3pick247572efeat:[JIRA123]addfeature1.2and1.3
4
5#Rebasec69f53d..247572eontoc69f53d(3commands)
6#
7#Commands:
8#p,pick=usecommit
9#r,reword=usecommit,buteditthecommitmessage
10#e,edit=usecommit,butstopforamending
11#s,squash=usecommit,butmeldintopreviouscommit
12#f,fixup=like"squash",butdiscardthiscommit'slogmessage
13#x,exec=runcommand(therestoftheline)usingshell
14#d,drop=removecommit
15#l,label

合并 commit-id 最常用的是squashfixup, 前者包含 commit message,后者不包含,這里使用 fixup, 然后:wq退出

1pick5dd0ad3feat:[JIRA123]addfeature1
2fixup119f86efeat:[JIRA123]addfeature1.1
3fixup247572efeat:[JIRA123]addfeature1.2and1.3

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

*41cd711(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1
*c69f53d(origin/main,origin/feature/JIRA123-amend-test,origin/HEAD,main)Initialcommit

善用 rebase

上面的 feature1 已經(jīng)完整的開發(fā)完了,main 分支也有了其他人的更新,在將 feature merge 回 main 分支之前,以防代碼有沖突,需要先將 main 分支的內(nèi)容合并到 feature 中,如果用 merge 命令,就會多處一個 merge 節(jié)點,log history 中也會出現(xiàn)拐點,并不是線性的,所以這里我們可以在 feature 分支上使用 rebase 命令

gitpulloriginmain--rebase
7c442a08-f09b-11ed-90ce-dac502259ad0.png

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

*d40daa6(HEAD->feature/JIRA123-amend-test)feat:[JIRA123]addfeature1
*446f463(origin/main,origin/HEAD)Createmain.properties
*c69f53d(origin/feature/JIRA123-amend-test,main)Initialcommit

我們的 feature1 功能on top ofmain 的提交節(jié)點,還是保持線性,接下來就可以 push 代碼,然后提 PR,將你的 feature merge 到 main 分支了

簡單描述 merge 和 rebase 的區(qū)別就是這樣的:

7c5c6898-f09b-11ed-90ce-dac502259ad0.gif7cad170c-f09b-11ed-90ce-dac502259ad0.gif

我這里使用git pull origin main --rebase省略了切換 main 并拉取最新內(nèi)容再切回來的過程,一步到位,背后的原理都是上圖展示的這樣

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

總結(jié)

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


	

	

	

	


審核編輯 :李倩


聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 源碼
    +關(guān)注

    關(guān)注

    8

    文章

    641

    瀏覽量

    29216
  • 編輯器
    +關(guān)注

    關(guān)注

    1

    文章

    806

    瀏覽量

    31176
  • Git
    Git
    +關(guān)注

    關(guān)注

    0

    文章

    200

    瀏覽量

    15765

原文標題:維持整潔的 Git 提交記錄,三個錦囊送給你

文章出處:【微信號:良許Linux,微信公眾號:良許Linux】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    如何使用SSH簽名Git提交記錄

    Git 支持使用 GPG 來簽名提交記錄。但 GPG 用起來很復(fù)雜,一直賴得搞。
    發(fā)表于 06-16 16:21 ?577次閱讀

    git命令的基本使用

    git config 第一次使用git或者剛安裝的git時,使用此命令設(shè)置身份Name 和 Eamail 地址。并且每次提交時會使用此信息。
    的頭像 發(fā)表于 12-11 13:53 ?915次閱讀

    git之推送提交

    這兩天試著使用了git的推送,把本地的文件上傳到倉庫,中間遇到點問題,就是本地的倉庫文件和遠端的倉庫相比,多出來一些文件,是我自己新產(chǎn)生的,于是push不是很順利,特此記錄下來,主要參考了如
    發(fā)表于 12-17 09:20

    git簡單使用(一)

    本帖最后由 iysheng 于 2017-2-19 23:09 編輯 編程,經(jīng)常會修改代碼,不管是將代碼托管到本地還是網(wǎng)上,使用git進行版本控制無疑是比較流行的方法。今天我就記錄下如何創(chuàng)建
    發(fā)表于 02-17 16:18

    第一本Git命令教程(六) - 日志

    今天是 Git 系列課程第六課,上一課我們學(xué)會了 Git 本地提交,今天痞子衡要講的是如何查看 Git 本地歷史提交。 當我們在倉庫里做了很
    的頭像 發(fā)表于 12-05 17:22 ?797次閱讀

    如何快速批量修改Git提交記錄中的用戶信息

    使用該腳本,替換其中 [Your Old Email] [Your New Author Name] [Your New Email] 之后在 git 目錄中執(zhí)行即可。
    的頭像 發(fā)表于 02-06 16:09 ?2027次閱讀

    Git是怎樣的一個系統(tǒng) Git的工作原理

    執(zhí)行完成了 git commit 命令,究竟做了什么呢? Git 倉庫中的提交記錄保存的是你的目錄下所有文件的快照,就像是把整個目錄復(fù)制,然后再粘貼一樣,但比復(fù)制粘貼優(yōu)雅許多!
    發(fā)表于 02-22 10:41 ?322次閱讀

    git rebase與相關(guān)git merge命令比較

    。 #概念 ????首先要理解的是git rebase和git merge解決了同樣的問題。這兩個命令都旨在將更改從一個分支集成到另一個分支 - 它們只是以不同的方式進行。試想一下當你開始在專用分支中開發(fā)新功能時另一個團隊成員以新提交
    的頭像 發(fā)表于 05-26 16:22 ?886次閱讀
    <b class='flag-5'>git</b> rebase與相關(guān)<b class='flag-5'>git</b> merge命令比較

    git rebase和git merge的區(qū)別

    "origin"已經(jīng)有了 2 個提交,如圖。 現(xiàn)在我們在這個分支做一些修改,然后生成兩個提交(commit)。 ? $?vi?file.txt$?git?commit$?vi?otherfile.txt$?
    的頭像 發(fā)表于 07-05 09:54 ?643次閱讀
    <b class='flag-5'>git</b> rebase和<b class='flag-5'>git</b> merge的區(qū)別

    Git是什么 Git介紹

    git 是什么? Git 誕生于 2005 年,是一款免費、開源、分布式版本控制系統(tǒng)。 直接記錄快照,而非差異比較 Git 和其它版本控制系統(tǒng)的主要差別在于
    的頭像 發(fā)表于 07-22 10:50 ?1794次閱讀
    <b class='flag-5'>Git</b>是什么 <b class='flag-5'>Git</b>介紹

    git如何記錄每次更新到倉庫

    記錄每次更新到倉庫 工作目錄下的每一個文件都不外乎這兩種狀態(tài):已跟蹤 或 未跟蹤。 已跟蹤包括:已提交(committed)、已修改(modified) 和 已暫存(staged) 檢查當前文件狀態(tài)
    的頭像 發(fā)表于 07-22 11:11 ?541次閱讀
    <b class='flag-5'>git</b>如何<b class='flag-5'>記錄</b>每次更新到倉庫

    git中如何查看提交歷史

    查看提交歷史 在提交了若干更新,又或者克隆了某個項目之后,你也許想回顧下提交歷史。完成這個任務(wù)最簡單而又有效的工具是 git log 命令。 我們使用一個非常簡單的 “simplegi
    的頭像 發(fā)表于 07-22 11:21 ?955次閱讀
    <b class='flag-5'>git</b>中如何查看<b class='flag-5'>提交</b>歷史

    git基本操作命令用法

    基本用法 上面的四條命令在工作目錄、暫存目錄(也叫做索引)和倉庫之間復(fù)制文件。 git add files把當前文件放入暫存區(qū)域。 git commit給暫存區(qū)域生成快照并提交git
    的頭像 發(fā)表于 09-13 16:29 ?788次閱讀
    <b class='flag-5'>git</b>基本操作命令用法

    如何在 Git 中恢復(fù)隱藏的修改記錄

    git stash 和 git stash pop 這樣的命令是用來擱置(藏匿)和恢復(fù)我們工作目錄中的變化的。在本教程中,我們將學(xué)習(xí)如何在 Git 中恢復(fù)隱藏的修改記錄。 在工作目
    的頭像 發(fā)表于 10-09 14:09 ?1014次閱讀

    Git命令解決常見場景記錄

    本文主要歸納一下git的學(xué)習(xí)記錄,在開發(fā)期間發(fā)現(xiàn)了git在sourcetree的處理不是很好,對于多選文件的丟棄這點不是很方便,所以做一個記錄,由于項目中有新建的文件,所以被識別為未跟
    的頭像 發(fā)表于 12-20 09:44 ?498次閱讀
    用<b class='flag-5'>Git</b>命令解決常見場景<b class='flag-5'>記錄</b>