摘要:背景背景大家都有學(xué)習(xí)如何規(guī)范簡(jiǎn)潔的編寫(xiě)代碼,但卻很少學(xué)習(xí)如何規(guī)范簡(jiǎn)潔的提交代碼。
大家都有學(xué)習(xí)如何規(guī)范簡(jiǎn)潔的編寫(xiě)代碼,但卻很少學(xué)習(xí)如何規(guī)范簡(jiǎn)潔的提交代碼。現(xiàn)在大家基本上都用 Git 作為源碼管理的工具,Git 提供了極大的靈活性,我們按照各種 workflow 來(lái)提交/合并 code,這種靈活性把控不好,也會(huì)帶來(lái)很多問(wèn)題
最常見(jiàn)的問(wèn)題就是亂成一團(tuán)的 git log history,那真的是老太太的裹腳布, 又臭又長(zhǎng), 個(gè)人極其不喜歡這種 log
造成這個(gè)問(wèn)題的根本原因就是隨意提交代碼。
代碼都提交了,那還有什么辦法拯救嗎?三個(gè)錦囊,就可以完美解決了
這個(gè)命令的幫助文檔是這樣描述的:
--amend amend previous commit
也就是說(shuō),它可以幫助我們修改最后一次提交
既可以修改我們提交的 message,又可以修改我們提交的文件,最后還會(huì)替換最后一個(gè) commit-id
我們可能會(huì)在某次提交的時(shí)候遺漏了某個(gè)文件,當(dāng)我們?cè)俅翁峤痪涂赡軙?huì)多處一個(gè)無(wú)用的 commit-id,大家都這樣做,git log 慢慢就會(huì)亂的無(wú)法追蹤完整功能了
假設(shè)我們有這樣一段 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
假設(shè)我們要修改最后一個(gè) log message,就可以使用下面命令:
git commit --amend -m "feat: [JIRA123] add feature 1.2 and 1.3"
我們?cè)賮?lái)看一下 log 信息, 可以發(fā)現(xiàn),我們用新的 commit-id 5e354d1
替換了舊的 commit-id 98a75af
, 修改了 message,并沒(méi)有增加節(jié)點(diǎn)
* 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
現(xiàn)在我們的 repo 中文件是這樣的:
.├── README.md└── feat1.txt0 directories, 2 files
假設(shè)我們提交 feature 1.3
的時(shí)候,忘記了一個(gè)配置文件 config.yaml
, 不想修改 log,不想添加新的 commit-id,那下面的這個(gè)命令就非常好用了
echo "feature 1.3 config info" > config.yamlgit add .git commit --amend --no-edit
git commit --amend --no-edit
就是靈魂所在了,來(lái)看一下當(dāng)前的 repo 文件:
.├── README.md├── config.yaml└── feat1.txt0 directories, 3 files
再來(lái)看一下 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
知道這個(gè)技巧,就可以確保我們的每次提交都包含有效的信息了。一張圖描述這個(gè)過(guò)程就是這個(gè)樣子了:
有了 --no-edit
的 buff 加成,威力更大一些
可以看著,上面的 log 都是在開(kāi)發(fā) feature1,我們?cè)诎?feature 分支 merge 到 main 分支之前,還是應(yīng)該繼續(xù)合并 log commit 節(jié)點(diǎn)的,這就用到了
git rebase -i HEAD~n
其中 n 代表最后幾個(gè)提交,上面我們針對(duì) feature 1 有三個(gè)提交,所以就可以使用:
git rebase -i HEAD~3
運(yùn)行后,會(huì)顯示一個(gè) vim 編輯器,內(nèi)容如下:
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 = use commit 9 # r, reword = use commit, but edit the commit message 10 # e, edit = use commit, but stop for amending 11 # s, squash = use commit, but meld into previous commit 12 # f, fixup = like "squash", but discard this commit"s log message 13 # x, exec = run command (the rest of the line) using shell 14 # d, drop = remove commit 15 # l, label
合并 commit-id 最常用的是 squash
和 fixup
, 前者包含 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
我們?cè)賮?lái)看一下 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
上面的 feature1 已經(jīng)完整的開(kāi)發(fā)完了,main 分支也有了其他人的更新,在將 feature merge 回 main 分支之前,以防代碼有沖突,需要先將 main 分支的內(nèi)容合并到 feature 中,如果用 merge 命令,就會(huì)多處一個(gè) merge 節(jié)點(diǎn),log history 中也會(huì)出現(xiàn)拐點(diǎn),并不是線性的,所以這里我們可以在 feature 分支上使用 rebase 命令
git pull origin main --rebase
pull 命令的背后是自動(dòng)幫我們做 merge 的,但是這里以 rebase 的形式,再來(lái)看一下 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 的提交節(jié)點(diǎn),還是保持線性,接下來(lái)就可以 push 代碼,然后提 PR,將你的 feature merge 到 main 分支了
簡(jiǎn)單描述 merge 和 rebase 的區(qū)別就是這樣的:
我這里使用 git pull origin main --rebase
省略了切換 main 并拉取最新內(nèi)容再切回來(lái)的過(guò)程,一步到位,背后的原理都是上圖展示的這樣
使用 rebase 是要遵守一個(gè)黃金法則的,這個(gè)之前有說(shuō)過(guò),就不再是贅述了
有了這三個(gè)錦囊,相信大家的 git log 都無(wú)比的清晰,如果你還不知道,完全可以用起來(lái),如果你的組內(nèi)成員不知道,你完全可以推廣起來(lái),這樣的 repo 看起來(lái)才更健康
接下來(lái)會(huì)介紹一個(gè)多分支切換互不影響的錦囊
個(gè)人博客:https://dayarch.top
加我微信好友, 進(jìn)群娛樂(lè)學(xué)習(xí)交流,備注「進(jìn)群」
歡迎持續(xù)關(guān)注公眾號(hào):「日拱一兵」
- 前沿 Java 技術(shù)干貨分享
- 高效工具匯總 | 回復(fù)「工具」
- 面試問(wèn)題分析與解答
- 技術(shù)資料領(lǐng)取 | 回復(fù)「資料」
以讀偵探小說(shuō)思維輕松趣味學(xué)習(xí) Java 技術(shù)棧相關(guān)知識(shí),本著將復(fù)雜問(wèn)題簡(jiǎn)單化,抽象問(wèn)題具體化和圖形化原則逐步分解技術(shù)問(wèn)題,技術(shù)持續(xù)更新,請(qǐng)持續(xù)關(guān)注......
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/124127.html
摘要:即便對(duì)于行家來(lái)說(shuō),調(diào)試神經(jīng)網(wǎng)絡(luò)也是一項(xiàng)艱巨的任務(wù)。神經(jīng)網(wǎng)絡(luò)對(duì)于所有失真應(yīng)該具有不變性,你需要特別訓(xùn)練這一點(diǎn)。對(duì)于負(fù)數(shù),會(huì)給出,這意味著函數(shù)沒(méi)有激活。換句話說(shuō),神經(jīng)元有一部分從未被使用過(guò)。這是因?yàn)樵黾痈嗟膶訒?huì)讓網(wǎng)絡(luò)的精度降低。 即便對(duì)于行家來(lái)說(shuō),調(diào)試神經(jīng)網(wǎng)絡(luò)也是一項(xiàng)艱巨的任務(wù)。數(shù)百萬(wàn)個(gè)參數(shù)擠在一起,一個(gè)微小的變化就能毀掉所有辛勤工作的成果。然而不進(jìn)行調(diào)試以及可視化,一切就只能靠運(yùn)氣,最后可能...
摘要:還可以通過(guò)檢查對(duì)象內(nèi)容的的哈希值和對(duì)象名是否相同,來(lái)判斷對(duì)象內(nèi)容是否正確。對(duì)象對(duì)象和其它所有的對(duì)象一樣,都用其內(nèi)容的哈希值來(lái)命名的只有當(dāng)兩個(gè)對(duì)象的內(nèi)容完全相同包括其所指向所有子對(duì)象時(shí),它的名字才會(huì)一樣,反之亦然。 git是什么 簡(jiǎn)單來(lái)說(shuō),Git,它是一個(gè)快速的 分布式版本控制系統(tǒng) (Distributed Version Control System,簡(jiǎn)稱 DVCS) 。 同傳統(tǒng)的 集...
摘要:合并到多個(gè)目標(biāo)分支或其他人正在使用當(dāng)前分支這是應(yīng)該使用因?yàn)槟銏?zhí)行時(shí)當(dāng)前分支原先的會(huì)被刪除會(huì)影響他人,形成新的連接在目標(biāo)分支最新之后。 閱讀原文:合并分支使用Merge還是Rebase? 作為一個(gè)有追求的開(kāi)發(fā)者,我一定會(huì)選擇更好的版本管理工具(Git), 使用中我們難免會(huì)在 Merge 和 Rebase 中選擇其一用于合并分支。 Rebase 和 merge 都是被設(shè)計(jì)用于集成你所做的改...
摘要:適配器模式橋接模式過(guò)濾器模式組合模式裝飾器模式外觀模式享元模式代理模式行為型模式這些設(shè)計(jì)模式特別關(guān)注對(duì)象之間的通信。對(duì)象適配器另外一種適配器模式是對(duì)象適配器,它不是使用多繼承或繼承再實(shí)現(xiàn)的方式,而是使用直接關(guān)聯(lián),或者稱為委托的方式。 設(shè)計(jì)模式匯總 創(chuàng)建型模式 這些設(shè)計(jì)模式提供了一種在創(chuàng)建對(duì)象的同時(shí)隱藏創(chuàng)建邏輯的方式,而不是使用新的運(yùn)算符直接實(shí)例化對(duì)象。這使得程序在判斷針對(duì)某個(gè)給定實(shí)例需...
閱讀 1289·2021-11-22 12:05
閱讀 1416·2021-09-29 09:35
閱讀 703·2019-08-30 15:55
閱讀 3199·2019-08-30 14:12
閱讀 1019·2019-08-30 14:11
閱讀 2940·2019-08-30 13:10
閱讀 2482·2019-08-29 16:33
閱讀 3393·2019-08-29 11:02