摘要:背景背景大家都有學習如何規范簡潔的編寫代碼,但卻很少學習如何規范簡潔的提交代碼。
大家都有學習如何規范簡潔的編寫代碼,但卻很少學習如何規范簡潔的提交代碼。現在大家基本上都用 Git 作為源碼管理的工具,Git 提供了極大的靈活性,我們按照各種 workflow 來提交/合并 code,這種靈活性把控不好,也會帶來很多問題
最常見的問題就是亂成一團的 git log history,那真的是老太太的裹腳布, 又臭又長, 個人極其不喜歡這種 log
造成這個問題的根本原因就是隨意提交代碼。
代碼都提交了,那還有什么辦法拯救嗎?三個錦囊,就可以完美解決了
這個命令的幫助文檔是這樣描述的:
--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.txt0 directories, 2 files
假設我們提交 feature 1.3
的時候,忘記了一個配置文件 config.yaml
, 不想修改 log,不想添加新的 commit-id,那下面的這個命令就非常好用了
echo "feature 1.3 config info" > config.yamlgit add .git commit --amend --no-edit
git commit --amend --no-edit
就是靈魂所在了,來看一下當前的 repo 文件:
.├── README.md├── config.yaml└── feat1.txt0 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 加成,威力更大一些
可以看著,上面的 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 = 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
我們再來看一下 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 已經完整的開發完了,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 技術棧相關知識,本著將復雜問題簡單化,抽象問題具體化和圖形化原則逐步分解技術問題,技術持續更新,請持續關注......
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/124127.html
摘要:即便對于行家來說,調試神經網絡也是一項艱巨的任務。神經網絡對于所有失真應該具有不變性,你需要特別訓練這一點。對于負數,會給出,這意味著函數沒有激活。換句話說,神經元有一部分從未被使用過。這是因為增加更多的層會讓網絡的精度降低。 即便對于行家來說,調試神經網絡也是一項艱巨的任務。數百萬個參數擠在一起,一個微小的變化就能毀掉所有辛勤工作的成果。然而不進行調試以及可視化,一切就只能靠運氣,最后可能...
摘要:合并到多個目標分支或其他人正在使用當前分支這是應該使用因為你執行時當前分支原先的會被刪除會影響他人,形成新的連接在目標分支最新之后。 閱讀原文:合并分支使用Merge還是Rebase? 作為一個有追求的開發者,我一定會選擇更好的版本管理工具(Git), 使用中我們難免會在 Merge 和 Rebase 中選擇其一用于合并分支。 Rebase 和 merge 都是被設計用于集成你所做的改...
摘要:適配器模式橋接模式過濾器模式組合模式裝飾器模式外觀模式享元模式代理模式行為型模式這些設計模式特別關注對象之間的通信。對象適配器另外一種適配器模式是對象適配器,它不是使用多繼承或繼承再實現的方式,而是使用直接關聯,或者稱為委托的方式。 設計模式匯總 創建型模式 這些設計模式提供了一種在創建對象的同時隱藏創建邏輯的方式,而不是使用新的運算符直接實例化對象。這使得程序在判斷針對某個給定實例需...
閱讀 1209·2021-11-22 12:05
閱讀 1335·2021-09-29 09:35
閱讀 630·2019-08-30 15:55
閱讀 3122·2019-08-30 14:12
閱讀 954·2019-08-30 14:11
閱讀 2874·2019-08-30 13:10
閱讀 2400·2019-08-29 16:33
閱讀 3326·2019-08-29 11:02