七个有用的 GIT 命令

在这篇文章中，我将与你分享7个 GIT 命令。它们是有用的简短命令，但有时我们会错过它们。

01、查看之前的分支

我们将从一个非常短的 git 命令开始这个列表。有时，我们在分支机构工作。对于某些季节，我们需要切换到另一个分支。

但我们意识到我们错过了上一个分支中的一些东西。

当然，我们需要使用checkout命令来checkout到上一个分支。

但除了找到（或记住）分支名称来检查这一点之外。我们完全可以用另一种更简单的方式来做。我们只需要使用减号而不是分支名称来调用 checkout 命令：

git checkout -

有用，并且很简单。

02、丢弃所有未提交的代码

同样，我们将使用一个简单的命令。有时，我们想丢弃所有未提交的代码。 Git 为我们提供了一个强大的工具，那就是带有 --hard 选项的 git Reset。

这就是我想在这一部分提到的方式，相信很多开发者都知道这个命令。

在这里，我只想添加一个小技巧，即在运行 git reset 之前使用 git add 。它将帮助你清除新文件/目录，而不仅仅是清除修改的内容。我们来测试一下。

没有 git add .:

即使我们运行 git reset 命令，我们可能会看到新文件仍然保留。让我们尝试一下 git add .：

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

03、列出包含提交的分支

在这一部分中，我们将讨论 gitbranch 命令的一个很好的选项。

但有时，我有很多任务要同时处理。我们在第一个分支工作，然后跳到另一个分支。之后，我们跳回第一个分支。跳转到很多分支可能会让你忘记要查找的分支名称。

因此，要查找包含提交的分支，我们只需要使用 contians 选项和哈希提交调用 gitbranch 命令。

git branch --contians <commit>

让我们在这个演示中测试一下。我有一个包含这些提交的存储库。

在此演示中，我有一个分支 contains_commit_2 从分支 contains_commit_1 签出。分支 contains_commit_3 从分支 contains_commit_2 签出。这意味着最后两个分支包含来自第一个分支的提交。让我们检查一下。

是工作！找到包含提交的分支非常简单。让我们进入下一部分。

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

在这一部分中，我们将使用合并分支。时间长了，如果我们合并分支后不删除的话，我们可能会得到一堆合并的分支。要查看合并的分支，我们只需调用带有 merged 选项的 gitbranch 命令即可。我们来测试一下：

git branch --merged <branch>

在这个演示中，我们可能会看到我们列出了合并到主分支中的所有分支。现在，我们将转向将它们全部删除的方法。

这非常简单，因为我们有办法列出需要删除的分支。我们只需要将管道与 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、过滤新行

在这一部分中，我们将找到一种方法来检测代码中不需要的更改。

举个例子，我们经常忘记删除调试行（console.log…）。我知道我们可以通过在 IDE 中查找它们来进行检查，但在这里，我将向您展示如何使用 GIT 进行检查。

您还记得上一部分中的 grep 管道吗？这是一个很棒的工具。我们将把它与 git diff 命令一起使用。只需这样做：

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

这稍微解释了这个 grep 模式。

在这种模式中，我发现这些行以“+”开头，以确保我们只过滤添加行。

接下来，我们将通过添加包含关键字的行（在我的例子中为“console.log”）来进行过滤。

让我们在这里检查一下总结果：

有效！检测提交中添加的内容非常简单。

06、Git 一分为二

上面，我们使用了有关检测、清理和列出的命令。

在这一部分中，我们将使用支持调试的命令 git bisect。我真希望我早点知道这个命令。

在我们的生活中，您是否遇到过错误但无法立即检测到“错误”提交？您可能需要检查每个提交，直到找出该提交导致此错误的位置。

所以 GIT 为我们提供了一个很好的工具来处理这种情况。它就是 git bisect。使用 git bisect 我们可以节省更多的调试时间。

要使用这个命令，我们需要给它一个“坏”提交和一个“好”提交。它将帮助我们圈出我们范围内犯下的错误。

我们的工作仍然检查每个提交，但不需要循环所有提交，我们只需要检查更少的提交。这可能是模棱两可的。

现在，我们来看看演示吧。

我们将制作一个从“第 1 次提交”到“第 10 次提交”超过 10 次提交的演示。

假设我们在 HEAD 中发现了一个问题（第 10 次提交）。但我们不知道造成这个问题的确切问题是什么。让我们使用 git bisect 来查找此提交。第一次，我假设问题提交是“commit 7th”。

因此，提交的状态如下：

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

我们将通过 git bisect start 开始此测试。然后我们应该给它好的和坏的承诺来制定一个范围：

然后，它使我们进入第五次提交。当然，这很好。所以我们只需要注意到这是一个很好的承诺。

然后它使我们进入第七次提交。它有错误，因此我们将此提交标记为错误：

在最后一步中，我们进入第六次提交。因为这是第七次提交的前一次提交（该提交发生了错误）。所以我们将其标记为良好：

我们得到了关于提交使错误提交第七次的最终结果！我们只需要测试三次而不是七次！

我认为这是一个很好的 GIT 命令，可以帮助我们更轻松地进行调试。如果您仍然想优化调试时间，可以尝试使用 git bisect run。它将帮助你通过脚本检测提交是好还是坏。

07、Git 修复

本文中的最后一个命令是我希望能够应用到我的生活中的命令之一。

有时，我们在处理一些子任务的分支机构工作时会用到它。

例如：我们需要在页面上制作一个新按钮。

我们可能有三个基本任务：创建单元测试、按钮样式以及处理按钮单击操作。我假设我们会按照“测试”、“样式”和“脚本”的顺序进行，完成所有这些任务后，我们意识到我们在创建测试时缺少一些东西。我们应该做什么？

当然，我们会修复它。但是在修复它并提交之后，我们可能会得到一个不太漂亮的提交列表。

让我们看一个例子：

在此示例中，我们只有一个“添加”提交。可能没问题。但是如果我们有很多这样的提交会发生什么呢？我们的提交树可能看起来像一件补丁衬衫。为了解决这个问题，我们可以使用git fixup命令。

要使用这种方式，我们只需要按照正常的方式进行一些添加即可。我们不需要像普通提交那样提交修复，只需使用选项 --fixup 和我们想要修复的提交的哈希值调用 git commit 命令即可。它看起来像这样。

我们还有四个提交。但最后一次提交与需要修复的提交具有相同的消息，并带有前缀“!fixup”。为了使它们成为真正的解决方案，我们还需要采取进一步的措施。只需要 git rebase -i --autosquash <previous base commit> 。我们来试试吧！

完成啦！不再有“修复”提交。提交列表现在很清楚了！

结论

这就是我想在这篇文章中分享的全部内容。我认为上面的命令使用起来并不太复杂。每个人都可以轻松记住并使用它们。