Git 不要只會 pull 和 push,學學這 5 條提高效率的命令

語言: CN / TW / HK

使用 git 作為程式碼版本管理,早已是現在開發者必備的技能,但是大多數的開發者還是隻會最基本的儲存,拉去,推送,遇到一些 commit 管理的問題就束手無策,或者用一些不優雅的方式解決。

下面分享一些在開發工作中實踐過的實用命令,這些都能夠大大提交工作效率,還能解決不少疑難場景。

*st ash*

官方文件:https://git-scm.com/docs/git-stash

git 教程: https://www.bookstack.cn/read/git-tutorial/docs-commands-git-stash.md

*描述:*

官方解釋:當您想記錄工作目錄和索引的當前狀態,但又想返回一個乾淨的工作目錄時,請使用 git stash,該命令將儲存本地修改,並恢復工作喲目錄以及匹配頭部提交。

sash 命令能夠將還未 commit 的程式碼存起來,讓你的目錄變得乾淨。

*應用場景:*

為什麼要變得乾淨呢?

比如:某一天你正在 v2.0 分支開發新需求,突然產品經理跑過來說線上有 bug,必須馬上修復,而此時你的功能開發到一半,於是你急忙想切到 master 分支,然後你就會看到以下報錯:

因為當前有檔案更改了,需要提交 commit 保持工作區乾淨才能切分支。由於情況緊急,你只有急忙 commit 上去,commit 資訊也隨便寫了個 “暫存程式碼”,於是該分支提交記錄就留了一條黑歷史。

*命令使用:*

如果你學會 stash,就不用那麼狼狽了,你只需要:

就這麼簡單,程式碼就被存起來了。

當你修復完線上問題,切回 v2.0 分支,想恢復程式碼也只需要:

*相關命令:*

當有多條 stash,可以指定操作 stash,首先使用 stash list 列出所有記錄:

應用第二條記錄:

*vscode 整合:*

stash 程式碼

填寫備註內容,也可以不填直接 Enter\

在 STASHES 選單中可以看到儲存的 stash

點選 stash 記錄旁的小箭頭,再點選 apply 或者 pop 都可回覆 stash

*r eset –soft*

*描述:*

完全不接觸索引檔案或工作樹(但會像所有模式一樣,將頭部重置),這使您的所有更改的檔案更改為 “要提交的更改”。

回退你已提交的 commit,並將 commit 的修改內容放回到暫存區。

一般我們在使用 reset 命令時,git reset –hard 會被提及的比較多,它能讓 commit 記錄強制回溯到某一個節點。而 git reset –soft 的作用正如其名, --soft(柔軟的) 除了回溯節點外,還會保留節點的修改內容。

*應用場景:*

回溯節點,為什麼要保留修改內容?

應用場景 1:有時候手滑不小心把不該提交的內容 commit 了,這時想改回來,只能再 cmmit 一次,又多一條 “黑歷史”。

應用場景 2:規範些的團隊,一般對於 commit 的內容要求職責明確,顆粒度要細,便於後續出現問題排查。本來屬於兩塊不同功能的修改,一起 commit 上去,這種就屬於不規範,這次恰好又手滑了,一次性 commit 上去。

*命令使用:*

學會 reset –soft 之後,你只需要:

reset –soft 相當於後悔藥,給你重新改過的機會。對於上面的場景,就可以中再次修改重新提交,保持乾淨的 commit 記錄。

以上說的時還未 push 的 commit,對於已經 push 的 commit,也可以使用該命令,不過再次 push 時,由於遠端分支和本地分支有差異,需要強制推送 git push -f 來覆蓋被 reset 的 commit。

還有一點需要注意,在 reset –soft 指定 commit 時,會將該 commit 到最近一次 commit 的所有修改內容全部恢復,而不是隻針對該 commit。

舉個例子:

commit 記錄有 c、b、a.

reset 到 a

此時 HEAD 到了 a, 而 b、c 的修改內容都回到了暫存區。

*cherry-pick*

*描述:*

給定一個或多個現有提交,應用每個提交引入的更改,為每個提交記錄一個新的提交。這需要您的工作樹清潔(沒有從同意提交的修改)。

將已經提交的 commit,複製出新的 commit 應用到分支裡

*應用場景:*

commit 都提交了,為什麼還要複製新的出來?

應用場景 1:有時候版本的一些優化需求開發到一半,可能其中某一個開發完的需求臨時上,或者某些原因導致開發的需求卡住了已開發完成的需求上線,這時候就需要把 commit 抽出來,單獨處理。

應用場景 2:有時候開發分支中的程式碼記錄被汙染了,導致開發分支合到線上分支有問題,這時就需要拉一條幹淨的開發分支,再從舊的開發分支中把 commit 複製到心分支。

*命令使用:*

複製單個

現有一條 v2.0 分支,commit 記錄如下:

需要把 b 複製到另一個分支,首先把 commitHash 複製下來,然後切到 master 分支

當前 master 最新的記錄是 a, 使用 cherry-pick 把 b 應用到當前分支。

完成後看下最新的 log, b 已經應用到 master,作為最新的 commit 了,可以看到 commitHash 和之前不一樣了,但是提交時間還是保留之前的。

複製多個\ 以上是單個 commit 的複製,下面再來看看 cherry-pick 多個 commit 要如何操作

一次轉移多個提交:

上面的命令將 commit1 和 commit2 兩個提交應用到當前分支。

多個連續的 commit,也可區間複製:

上面的命令將 commit1 到 commit2 這個區間的 commit 都應用到當前分支(包含 commit1、commit2),commit 是最早的提交。

*cherry-pick 程式碼衝突:*

在 cherry-pick 多個 commit, 可能會遇到程式碼衝突,這時 cherry-pick 會停下來,讓使用者決定如何繼續操作,下面看看怎麼解決這種場景。

還是 v2.0 分支,現在需要把 c、d、e 都複製到 master 分支上,先把七點 c 和終點 e 的 commitHash 記下來。

切到 master 分支,使用區間的 cherry-pick。 可以看到 c 被複製成功,當進行到 d 時,發現程式碼衝突, cherry-pick 中斷了,這時需要解決程式碼衝突,重新提交到暫存區。

然後使用 cherry-pick –continue 讓 cherry-pick 繼續進行下去,最後 e 也被複制進來,整個流程就完成了。

以上是完整的流程,但有時候可能需要在程式碼衝突後,放棄或者退出流程:

放棄 cherry-pick:

回到操作前的樣子,就像什麼都沒發生過。

退出 cherry-pick:

不回到操作前的樣子,即保留已經 cherry-pick 成功的 commit,並退出 cherry-pick 流程。

*r evert*

*描述:*

給定一個或多個現有提交,恢復相關提交引入的更改,並記錄一些這些更改的新提交,這就要求你的工作樹是乾淨的(沒有來自頭部的修改)。

將現有的提交還原,恢復提交的內容,並生成一條還原記錄。

*應用場景:*

應用場景:有一天測試突然跟你說,你開發上線的功能有問題,需要馬上撤回,否則會影響到系統使用,這時可能會想到用 reset 回退,可是你看了看分支上最新的提交還要其它同事的程式碼,用 reset 會把這部分程式碼也撤回了,由於情況緊急,又想不到好方法,還是人性的使用 reset,然後再讓同事把他的程式碼合一遍(同事聽到想打人),於是你的技術形象在同事眼裡一落千丈。

*命令使用:*

revert 普通提交

學會 revert 之後,立馬就可以拯救這種尷尬的情況

現在 master 記錄如下:

revert 掉自己提交的 commit.

因為 revert 會生成一條新的提交記錄,這時會讓你編輯提交資訊,編輯完後:wq 儲存退出就好了。

再來看下最新的 log,生成一條 revert 記錄,雖然自己之前的提交記錄還會保留著,但你修改的程式碼已經被撤回了。

revert 合併提交

在 git 的 commit 記錄裡,還有一種型別是合併提交,想要 revert 合併提交,使用上會有些不一樣。

現在的 master 分支裡多了條合併提交。

使用剛剛同樣的 revert 方法,會發現命令列報錯了。

為什麼會這樣,在官方文件中有接受:

通常無法 revert 合併,因為您不知道合併的哪一側應被視為主線,此選項指定的父編號(從 1 開始),並允許 revert 反轉相對於指定父編號的更改

我的理解是因為合併提交是兩條分支的交集節點,而 git 不知道需要撤銷的哪一條分支,需要新增引數 -m 指定主線分支,保留主線分支的程式碼,另一條則被撤銷。

revert 合併提交後,再次合併分支會失效

還是上面的場景,在 master 分支 revert 合併提交後,然後切到 v2.0 分支修復好 bug,再合併到 master 分支時,會發現之前被 revert 的修改內容沒有重新合併進來。

因為使用 revert 後,v2.0 分支的 commit 還是會保留再 master 分支的記錄中,當你再次合併進去時,git 判斷有相同的 commitHash,就忽略了相關的 commit 需改內容。

現在 master 的記錄是這樣的

再次使用 revert,之前被 revert 的修改內容就又回來了。

*r eflog*

*描述:*

此命令管理重錄中記錄的資訊

如果說 reset –soft 時後悔藥,那 reflog 就是強力後悔藥,它記錄了所有的 commit 操作記錄,便於錯誤操作後找回記錄。

*應用場景:*

應用場景:某天你眼花,發現自己在其它人分支提交了程式碼還推到遠端分支,這時因為分支只有你的最新提交,就想著使用 reset –hard,結果緊張不小心點錯了 commitHash,reset 過頭,把同事的 commit 搞沒了。

沒辦法,reset –hard 是強制回退的,找不到 commitHash,只能讓同事從本地分支再推一次(同事瞬間拳頭就硬了,怎麼又是你),於是,你的技術形象又一落千丈。

*命令使用:*

分支記錄如上,想要 reset 到 b

誤操作 reset 過頭,b 沒了,最新的只剩下 a

這時用 git reflog 檢視歷史記錄,把錯誤提交的那次 commitHash 記下

再次 reset 回去,就會發現 b 回來了。

*設定 g it 短命令*

對於我這種喜歡橋命令列而不用圖形化工具的愛好者來說,設定短命令可以很好的提高效率,下面介紹兩種設定短命令的方式。

方式一:

方式二:

開啟全域性配置檔案

寫入內容

使用

原始碼附件已經打包好上傳到百度雲了,大家自行下載即可~

連結: https://pan.baidu.com/s/14G-bpVthImHD4eosZUNSFA?pwd=yu27 提取碼: yu27

百度雲連結不穩定,隨時可能會失效,大家抓緊儲存哈。

如果百度雲連結失效了的話,請留言告訴我,我看到後會及時更新~

開源地址

碼雲地址:\ http://github.crmeb.net/u/defu

Github 地址:\ http://github.crmeb.net/u/defu