在這篇文章中，我將與你分享7個 GIT 命令。 它們是有用的簡短命令，但有時我們會錯過它們。

01、查看之前的分支

我們將從一個非常短的 git 命令開始這個列表。 有時，我們在分支機構工作。 對于某些季節(jié)，我們需要切換到另一個分支。 

但我們意識到我們錯過了上一個分支中的一些東西。 

當然，我們需要使用checkout命令來checkout到上一個分支。 

但除了找到（或記住）分支名稱來檢查這一點之外。 我們完全可以用另一種更簡單的方式來做。 我們只需要使用減號而不是分支名稱來調(diào)用 checkout 命令：

git checkout -

有用，并且很簡單。

02、丟棄所有未提交的代碼

同樣，我們將使用一個簡單的命令。 有時，我們想丟棄所有未提交的代碼。 Git 為我們提供了一個強大的工具，那就是帶有 --hard 選項的 git Reset。 

這就是我想在這一部分提到的方式，相信很多開發(fā)者都知道這個命令。 

在這里，我只想添加一個小技巧，即在運行 git reset 之前使用 git add 。 它將幫助你清除新文件/目錄，而不僅僅是清除修改的內(nèi)容。 我們來測試一下。

沒有 git add .:

即使我們運行 git reset 命令，我們可能會看到新文件仍然保留。 讓我們嘗試一下 git add .：

只需多一步，所有新文件/目錄就都清楚了。

03、列出包含提交的分支

在這一部分中，我們將討論 gitbranch 命令的一個很好的選項。

但有時，我有很多任務要同時處理。 我們在第一個分支工作，然后跳到另一個分支。 之后，我們跳回第一個分支。 跳轉(zhuǎn)到很多分支可能會讓你忘記要查找的分支名稱。 

因此，要查找包含提交的分支，我們只需要使用 contians 選項和哈希提交調(diào)用 gitbranch 命令。

git branch --contians <commit>

讓我們在這個演示中測試一下。 我有一個包含這些提交的存儲庫。

在此演示中，我有一個分支 contains_commit_2 從分支 contains_commit_1 簽出。 分支 contains_commit_3 從分支 contains_commit_2 簽出。 這意味著最后兩個分支包含來自第一個分支的提交。 讓我們檢查一下。

是工作！ 找到包含提交的分支非常簡單。 讓我們進入下一部分。

04、查看/刪除所有合并的分支

在這一部分中，我們將使用合并分支。 時間長了，如果我們合并分支后不刪除的話，我們可能會得到一堆合并的分支。 要查看合并的分支，我們只需調(diào)用帶有 merged 選項的 gitbranch 命令即可。 我們來測試一下：

git branch --merged <branch>

在這個演示中，我們可能會看到我們列出了合并到主分支中的所有分支。 現(xiàn)在，我們將轉(zhuǎn)向?qū)⑺鼈內(nèi)縿h除的方法。 

這非常簡單，因為我們有辦法列出需要刪除的分支。 我們只需要將管道與 xargs 和 gitbranch -D 一起使用，如下所示：

git branch --merged <branch> | xargs git branch -D

但在運行此命令之前，我們需要使用 --merged 解決純 gitbranch 命令中的一些小問題。 

首先，我們可以看到該命令還列出了合并分支中的主分支。 要刪除它，我們只需要添加一個管道 grep，如下所示：

git branch --merged <branch name> | grep -v "<branch name>"

讓我們看看結果：

這個問題就解決了。 但我們還有另一個問題是當前分支。 我們可能會看到該命令還列出了當前分支。 我們還使用 grep 管道刪除當前分支，如下所示：

grep -v "^*"

這是完整的命令：

git branch --merged main | grep -v "main" | grep -v "^*" | xargs git branch -D

我們來測試一下

我們可能會看到所有合并分支都消失了！

05、過濾新行

在這一部分中，我們將找到一種方法來檢測代碼中不需要的更改。 

舉個例子，我們經(jīng)常忘記刪除調(diào)試行（console.log…）。 我知道我們可以通過在 IDE 中查找它們來進行檢查，但在這里，我將向您展示如何使用 GIT 進行檢查。 

您還記得上一部分中的 grep 管道嗎？ 這是一個很棒的工具。 我們將把它與 git diff 命令一起使用。 只需這樣做：

git diff | grep "^+.*<code function you want to find>"

這稍微解釋了這個 grep 模式。

在這種模式中，我發(fā)現(xiàn)這些行以“+”開頭，以確保我們只過濾添加行。 

接下來，我們將通過添加包含關鍵字的行（在我的例子中為“console.log”）來進行過濾。 

讓我們在這里檢查一下總結果：

有效！ 檢測提交中添加的內(nèi)容非常簡單。

06、Git 一分為二

上面，我們使用了有關檢測、清理和列出的命令。 

在這一部分中，我們將使用支持調(diào)試的命令 git bisect。 我真希望我早點知道這個命令。 

在我們的生活中，您是否遇到過錯誤但無法立即檢測到“錯誤”提交？ 您可能需要檢查每個提交，直到找出該提交導致此錯誤的位置。 

所以 GIT 為我們提供了一個很好的工具來處理這種情況。 它就是 git bisect。 使用 git bisect 我們可以節(jié)省更多的調(diào)試時間。 

要使用這個命令，我們需要給它一個“壞”提交和一個“好”提交。 它將幫助我們?nèi)Τ鑫覀兎秶鷥?nèi)犯下的錯誤。 

我們的工作仍然檢查每個提交，但不需要循環(huán)所有提交，我們只需要檢查更少的提交。 這可能是模棱兩可的。 

現(xiàn)在，我們來看看演示吧。

我們將制作一個從“第 1 次提交”到“第 10 次提交”超過 10 次提交的演示。

假設我們在 HEAD 中發(fā)現(xiàn)了一個問題（第 10 次提交）。 但我們不知道造成這個問題的確切問題是什么。 讓我們使用 git bisect 來查找此提交。 第一次，我假設問題提交是“commit 7th”。 

因此，提交的狀態(tài)如下：

10th - BAD
9th - BAD
8th - BAD
7th - BAD
6th - GOOD
5th - GOOD
4th - GOOD
3rd - GOOD
2nd - GOOD
1st - GOOD

我們將通過 git bisect start 開始此測試。 然后我們應該給它好的和壞的承諾來制定一個范圍：

然后，它使我們進入第五次提交。 當然，這很好。 所以我們只需要注意到這是一個很好的承諾。

然后它使我們進入第七次提交。 它有錯誤，因此我們將此提交標記為錯誤：

在最后一步中，我們進入第六次提交。 因為這是第七次提交的前一次提交（該提交發(fā)生了錯誤）。 所以我們將其標記為良好：

我們得到了關于提交使錯誤提交第七次的最終結果！ 我們只需要測試三次而不是七次！

我認為這是一個很好的 GIT 命令，可以幫助我們更輕松地進行調(diào)試。 如果您仍然想優(yōu)化調(diào)試時間，可以嘗試使用 git bisect run。 它將幫助你通過腳本檢測提交是好還是壞。

07、Git 修復

本文中的最后一個命令是我希望能夠應用到我的生活中的命令之一。 

有時，我們在處理一些子任務的分支機構工作時會用到它。 

例如：我們需要在頁面上制作一個新按鈕。 

我們可能有三個基本任務：創(chuàng)建單元測試、按鈕樣式以及處理按鈕單擊操作。 我假設我們會按照“測試”、“樣式”和“腳本”的順序進行，完成所有這些任務后，我們意識到我們在創(chuàng)建測試時缺少一些東西。 我們應該做什么？ 

當然，我們會修復它。 但是在修復它并提交之后，我們可能會得到一個不太漂亮的提交列表。 

讓我們看一個例子：

在此示例中，我們只有一個“添加”提交。 可能沒問題。 但是如果我們有很多這樣的提交會發(fā)生什么呢？ 我們的提交樹可能看起來像一件補丁襯衫。 為了解決這個問題，我們可以使用git fixup命令。

要使用這種方式，我們只需要按照正常的方式進行一些添加即可。 我們不需要像普通提交那樣提交修復，只需使用選項 --fixup 和我們想要修復的提交的哈希值調(diào)用 git commit 命令即可。 它看起來像這樣。

我們還有四個提交。 但最后一次提交與需要修復的提交具有相同的消息，并帶有前綴“!fixup”。 為了使它們成為真正的解決方案，我們還需要采取進一步的措施。 只需要 git rebase -i --autosquash <previous base commit> 。 我們來試試吧！

完成啦！ 不再有“修復”提交。 提交列表現(xiàn)在很清楚了！

結論

這就是我想在這篇文章中分享的全部內(nèi)容。 我認為上面的命令使用起來并不太復雜。 每個人都可以輕松記住并使用它們。