您可能會(huì)錯(cuò)過的七個(gè)有用的 GIT 命令
在這篇文章中，我將與你分享7個(gè) GIT 命令。 它們是有用的簡(jiǎn)短命令，但有時(shí)我們會(huì)錯(cuò)過它們。
01、查看之前的分支
我們將從一個(gè)非常短的 git 命令開始這個(gè)列表。 有時(shí)，我們?cè)诜种C(jī)構(gòu)工作。 對(duì)于某些季節(jié)，我們需要切換到另一個(gè)分支。
但我們意識(shí)到我們錯(cuò)過了上一個(gè)分支中的一些東西。
當(dāng)然，我們需要使用checkout命令來checkout到上一個(gè)分支。
但除了找到（或記住）分支名稱來檢查這一點(diǎn)之外。 我們完全可以用另一種更簡(jiǎn)單的方式來做。 我們只需要使用減號(hào)而不是分支名稱來調(diào)用 checkout 命令：
git checkout -
有用，并且很簡(jiǎn)單。
02、丟棄所有未提交的代碼
同樣，我們將使用一個(gè)簡(jiǎn)單的命令。 有時(shí)，我們想丟棄所有未提交的代碼。 Git 為我們提供了一個(gè)強(qiáng)大的工具，那就是帶有 --hard 選項(xiàng)的 git Reset。
這就是我想在這一部分提到的方式，相信很多開發(fā)者都知道這個(gè)命令。
在這里，我只想添加一個(gè)小技巧，即在運(yùn)行 git reset 之前使用 git add 。 它將幫助你清除新文件/目錄，而不僅僅是清除修改的內(nèi)容。 我們來測(cè)試一下。
沒有 git add .:
即使我們運(yùn)行 git reset 命令，我們可能會(huì)看到新文件仍然保留。 讓我們嘗試一下 git add .：
只需多一步，所有新文件/目錄就都清楚了。
03、列出包含提交的分支
在這一部分中，我們將討論 gitbranch 命令的一個(gè)很好的選項(xiàng)。
但有時(shí)，我有很多任務(wù)要同時(shí)處理。 我們?cè)诘谝粋€(gè)分支工作，然后跳到另一個(gè)分支。 之后，我們跳回第一個(gè)分支。 跳轉(zhuǎn)到很多分支可能會(huì)讓你忘記要查找的分支名稱。
因此，要查找包含提交的分支，我們只需要使用 contians 選項(xiàng)和哈希提交調(diào)用 gitbranch 命令。
git branch --contians <commit>讓我們?cè)谶@個(gè)演示中測(cè)試一下。 我有一個(gè)包含這些提交的存儲(chǔ)庫。
在此演示中，我有一個(gè)分支 contains_commit_2 從分支 contains_commit_1 簽出。 分支 contains_commit_3 從分支 contains_commit_2 簽出。 這意味著最后兩個(gè)分支包含來自第一個(gè)分支的提交。 讓我們檢查一下。
是工作！ 找到包含提交的分支非常簡(jiǎn)單。 讓我們進(jìn)入下一部分。
04、查看/刪除所有合并的分支
在這一部分中，我們將使用合并分支。 時(shí)間長(zhǎng)了，如果我們合并分支后不刪除的話，我們可能會(huì)得到一堆合并的分支。 要查看合并的分支，我們只需調(diào)用帶有 merged 選項(xiàng)的 gitbranch 命令即可。 我們來測(cè)試一下：
git branch --merged <branch>
在這個(gè)演示中，我們可能會(huì)看到我們列出了合并到主分支中的所有分支。 現(xiàn)在，我們將轉(zhuǎn)向?qū)⑺鼈內(nèi)縿h除的方法。
這非常簡(jiǎn)單，因?yàn)槲覀冇修k法列出需要?jiǎng)h除的分支。 我們只需要將管道與 xargs 和 gitbranch -D 一起使用，如下所示：
git branch --merged <branch> | xargs git branch -D但在運(yùn)行此命令之前，我們需要使用 --merged 解決純 gitbranch 命令中的一些小問題。
首先，我們可以看到該命令還列出了合并分支中的主分支。 要?jiǎng)h除它，我們只需要添加一個(gè)管道 grep，如下所示：
git branch --merged <branch name> | grep -v "<branch name>"讓我們看看結(jié)果：
這個(gè)問題就解決了。 但我們還有另一個(gè)問題是當(dāng)前分支。 我們可能會(huì)看到該命令還列出了當(dāng)前分支。 我們還使用 grep 管道刪除當(dāng)前分支，如下所示：
grep -v "^*"這是完整的命令：
git branch --merged main | grep -v "main" | grep -v "^*" | xargs git branch -D我們來測(cè)試一下
我們可能會(huì)看到所有合并分支都消失了！
05、過濾新行
在這一部分中，我們將找到一種方法來檢測(cè)代碼中不需要的更改。
舉個(gè)例子，我們經(jīng)常忘記刪除調(diào)試行（console.log…）。 我知道我們可以通過在 IDE 中查找它們來進(jìn)行檢查，但在這里，我將向您展示如何使用 GIT 進(jìn)行檢查。
您還記得上一部分中的 grep 管道嗎？ 這是一個(gè)很棒的工具。 我們將把它與 git diff 命令一起使用。 只需這樣做：
git diff | grep "^+.*<code function you want to find>"這稍微解釋了這個(gè) grep 模式。
在這種模式中，我發(fā)現(xiàn)這些行以“+”開頭，以確保我們只過濾添加行。
接下來，我們將通過添加包含關(guān)鍵字的行（在我的例子中為“console.log”）來進(jìn)行過濾。
讓我們?cè)谶@里檢查一下總結(jié)果：
有效！ 檢測(cè)提交中添加的內(nèi)容非常簡(jiǎn)單。
06、Git 一分為二
上面，我們使用了有關(guān)檢測(cè)、清理和列出的命令。
在這一部分中，我們將使用支持調(diào)試的命令 git bisect。 我真希望我早點(diǎn)知道這個(gè)命令。
在我們的生活中，您是否遇到過錯(cuò)誤但無法立即檢測(cè)到“錯(cuò)誤”提交？ 您可能需要檢查每個(gè)提交，直到找出該提交導(dǎo)致此錯(cuò)誤的位置。
所以 GIT 為我們提供了一個(gè)很好的工具來處理這種情況。 它就是 git bisect。 使用 git bisect 我們可以節(jié)省更多的調(diào)試時(shí)間。
要使用這個(gè)命令，我們需要給它一個(gè)“壞”提交和一個(gè)“好”提交。 它將幫助我們?nèi)Τ鑫覀兎秶鷥?nèi)犯下的錯(cuò)誤。
我們的工作仍然檢查每個(gè)提交，但不需要循環(huán)所有提交，我們只需要檢查更少的提交。 這可能是模棱兩可的。
現(xiàn)在，我們來看看演示吧。
我們將制作一個(gè)從“第 1 次提交”到“第 10 次提交”超過 10 次提交的演示。
假設(shè)我們?cè)?HEAD 中發(fā)現(xiàn)了一個(gè)問題（第 10 次提交）。 但我們不知道造成這個(gè)問題的確切問題是什么。 讓我們使用 git bisect 來查找此提交。 第一次，我假設(shè)問題提交是“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 開始此測(cè)試。 然后我們應(yīng)該給它好的和壞的承諾來制定一個(gè)范圍：
然后，它使我們進(jìn)入第五次提交。 當(dāng)然，這很好。 所以我們只需要注意到這是一個(gè)很好的承諾。
然后它使我們進(jìn)入第七次提交。 它有錯(cuò)誤，因此我們將此提交標(biāo)記為錯(cuò)誤：
在最后一步中，我們進(jìn)入第六次提交。 因?yàn)檫@是第七次提交的前一次提交（該提交發(fā)生了錯(cuò)誤）。 所以我們將其標(biāo)記為良好：
我們得到了關(guān)于提交使錯(cuò)誤提交第七次的最終結(jié)果！ 我們只需要測(cè)試三次而不是七次！
我認(rèn)為這是一個(gè)很好的 GIT 命令，可以幫助我們更輕松地進(jìn)行調(diào)試。 如果您仍然想優(yōu)化調(diào)試時(shí)間，可以嘗試使用 git bisect run。 它將幫助你通過腳本檢測(cè)提交是好還是壞。
07、Git 修復(fù)
本文中的最后一個(gè)命令是我希望能夠應(yīng)用到我的生活中的命令之一。
有時(shí)，我們?cè)谔幚硪恍┳尤蝿?wù)的分支機(jī)構(gòu)工作時(shí)會(huì)用到它。
例如：我們需要在頁面上制作一個(gè)新按鈕。
我們可能有三個(gè)基本任務(wù)：創(chuàng)建單元測(cè)試、按鈕樣式以及處理按鈕單擊操作。 我假設(shè)我們會(huì)按照“測(cè)試”、“樣式”和“腳本”的順序進(jìn)行，完成所有這些任務(wù)后，我們意識(shí)到我們?cè)趧?chuàng)建測(cè)試時(shí)缺少一些東西。 我們應(yīng)該做什么？
當(dāng)然，我們會(huì)修復(fù)它。 但是在修復(fù)它并提交之后，我們可能會(huì)得到一個(gè)不太漂亮的提交列表。
讓我們看一個(gè)例子：
在此示例中，我們只有一個(gè)“添加”提交。 可能沒問題。 但是如果我們有很多這樣的提交會(huì)發(fā)生什么呢？ 我們的提交樹可能看起來像一件補(bǔ)丁襯衫。 為了解決這個(gè)問題，我們可以使用git fixup命令。
要使用這種方式，我們只需要按照正常的方式進(jìn)行一些添加即可。 我們不需要像普通提交那樣提交修復(fù)，只需使用選項(xiàng) --fixup 和我們想要修復(fù)的提交的哈希值調(diào)用 git commit 命令即可。 它看起來像這樣。
我們還有四個(gè)提交。 但最后一次提交與需要修復(fù)的提交具有相同的消息，并帶有前綴“!fixup”。 為了使它們成為真正的解決方案，我們還需要采取進(jìn)一步的措施。 只需要 git rebase -i --autosquash <previous base commit> 。 我們來試試吧！
完成啦！ 不再有“修復(fù)”提交。 提交列表現(xiàn)在很清楚了！
結(jié)論
這就是我想在這篇文章中分享的全部?jī)?nèi)容。 我認(rèn)為上面的命令使用起來并不太復(fù)雜。 每個(gè)人都可以輕松記住并使用它們。
