七个有用的 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 让我们在这个演示中测试一下。 我有一个包含这些提交的存储库。
在此演示中，我有一个分支 contains_commit_2 从分支 contains_commit_1 签出。 分支 contains_commit_3 从分支 contains_commit_2 签出。 这意味着最后两个分支包含来自第一个分支的提交。 让我们检查一下。
是工作！ 找到包含提交的分支非常简单。 让我们进入下一部分。
04、查看/删除所有合并的分支
在这一部分中，我们将使用合并分支。 时间长了，如果我们合并分支后不删除的话，我们可能会得到一堆合并的分支。 要查看合并的分支，我们只需调用带有 merged 选项的 gitbranch 命令即可。 我们来测试一下：
git branch --merged 在这个演示中，我们可能会看到我们列出了合并到主分支中的所有分支。 现在，我们将转向将它们全部删除的方法。
这非常简单，因为我们有办法列出需要删除的分支。 我们只需要将管道与 xargs 和 gitbranch -D 一起使用，如下所示：
git branch --merged | xargs git branch -D 但在运行此命令之前，我们需要使用 --merged 解决纯 gitbranch 命令中的一些小问题。
首先，我们可以看到该命令还列出了合并分支中的主分支。 要删除它，我们只需要添加一个管道 grep，如下所示：
git branch --merged | grep -v "" 让我们看看结果：
这个问题就解决了。 但我们还有另一个问题是当前分支。 我们可能会看到该命令还列出了当前分支。 我们还使用 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 "^+.*"这稍微解释了这个 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
完成啦！ 不再有“修复”提交。 提交列表现在很清楚了！
结论
这就是我想在这篇文章中分享的全部内容。 我认为上面的命令使用起来并不太复杂。每个人都可以轻松记住并使用它们。