七个有用的 GIT 命令

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

01、查看之前的分支

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

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

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

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

git checkout -

七个有用的 GIT 命令_第1张图片

有用,并且很简单。

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

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

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

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

没有 git add .:

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

七个有用的 GIT 命令_第2张图片

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

03、列出包含提交的分支

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

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

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

git branch --contians 

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

七个有用的 GIT 命令_第3张图片

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

七个有用的 GIT 命令_第4张图片

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

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 命令_第5张图片

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

七个有用的 GIT 命令_第6张图片

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

七个有用的 GIT 命令_第7张图片

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

七个有用的 GIT 命令_第8张图片

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

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

07、Git 修复

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

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

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

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

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

让我们看一个例子:

七个有用的 GIT 命令_第9张图片

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

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

七个有用的 GIT 命令_第10张图片

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

七个有用的 GIT 命令_第11张图片

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

结论

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

你可能感兴趣的:(git,elasticsearch,大数据)