在这篇文章中，我将与你分享7个 GIT 命令。 它们是有用的简短命令，但有时我们会错过它们。
我们将从一个非常短的 git 命令开始这个列表。 有时，我们在分支机构工作。 对于某些季节，我们需要切换到另一个分支。
但我们意识到我们错过了上一个分支中的一些东西。
当然，我们需要使用checkout命令来checkout到上一个分支。
但除了找到（或记住）分支名称来检查这一点之外。 我们完全可以用另一种更简单的方式来做。 我们只需要使用减号而不是分支名称来调用 checkout 命令：
git checkout -
有用，并且很简单。
同样，我们将使用一个简单的命令。 有时，我们想丢弃所有未提交的代码。 Git 为我们提供了一个强大的工具，那就是带有 --hard 选项的 git Reset。
这就是我想在这一部分提到的方式，相信很多开发者都知道这个命令。
在这里，我只想添加一个小技巧，即在运行 git reset 之前使用 git add 。 它将帮助你清除新文件/目录，而不仅仅是清除修改的内容。 我们来测试一下。
没有 git add .:
即使我们运行 git reset 命令，我们可能会看到新文件仍然保留。 让我们尝试一下 git add .：
只需多一步，所有新文件/目录就都清楚了。
在这一部分中，我们将讨论 gitbranch 命令的一个很好的选项。
但有时，我有很多任务要同时处理。 我们在第一个分支工作，然后跳到另一个分支。 之后，我们跳回第一个分支。 跳转到很多分支可能会让你忘记要查找的分支名称。
因此，要查找包含提交的分支，我们只需要使用 contians 选项和哈希提交调用 gitbranch 命令。
git branch --contians <commit>让我们在这个演示中测试一下。 我有一个包含这些提交的存储库。
在此演示中，我有一个分支 contains_commit_2 从分支 contains_commit_1 签出。 分支 contains_commit_3 从分支 contains_commit_2 签出。 这意味着最后两个分支包含来自第一个分支的提交。 让我们检查一下。
是工作！ 找到包含提交的分支非常简单。 让我们进入下一部分。
在这一部分中，我们将使用合并分支。 时间长了，如果我们合并分支后不删除的话，我们可能会得到一堆合并的分支。 要查看合并的分支，我们只需调用带有 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我们来测试一下
我们可能会看到所有合并分支都消失了！
在这一部分中，我们将找到一种方法来检测代码中不需要的更改。
举个例子，我们经常忘记删除调试行（console.log…）。 我知道我们可以通过在 IDE 中查找它们来进行检查，但在这里，我将向您展示如何使用 GIT 进行检查。
您还记得上一部分中的 grep 管道吗？ 这是一个很棒的工具。 我们将把它与 git diff 命令一起使用。 只需这样做：
git diff | grep "^+.*<code function you want to find>"这稍微解释了这个 grep 模式。
在这种模式中，我发现这些行以“+”开头，以确保我们只过滤添加行。
接下来，我们将通过添加包含关键字的行（在我的例子中为“console.log”）来进行过滤。
让我们在这里检查一下总结果：
有效！ 检测提交中添加的内容非常简单。
上面，我们使用了有关检测、清理和列出的命令。
在这一部分中，我们将使用支持调试的命令 git bisect。 我真希望我早点知道这个命令。
在我们的生活中，您是否遇到过错误但无法立即检测到“错误”提交？ 您可能需要检查每个提交，直到找出该提交导致此错误的位置。
所以 GIT 为我们提供了一个很好的工具来处理这种情况。 它就是 git bisect。 使用 git bisect 我们可以节省更多的调试时间。
要使用这个命令，我们需要给它一个“坏”提交和一个“好”提交。 它将帮助我们圈出我们范围内犯下的错误。
我们的工作仍然检查每个提交，但不需要循环所有提交，我们只需要检查更少的提交。 这可能是模棱两可的。
现在，我们来看看演示吧。
我们将制作一个从“第 1 次提交”到“第 10 次提交”超过 10 次提交的演示。
假设我们在 HEAD 中发现了一个问题（第 10 次提交）。 但我们不知道造成这个问题的确切问题是什么。 让我们使用 git bisect 来查找此提交。 第一次，我假设问题提交是“commit 7th”。
因此，提交的状态如下：
10th - BAD9th - BAD8th - BAD7th - BAD6th - GOOD5th - GOOD4th - GOOD3rd - GOOD2nd - GOOD1st - GOOD我们将通过 git bisect start 开始此测试。 然后我们应该给它好的和坏的承诺来制定一个范围：
然后，它使我们进入第五次提交。 当然，这很好。 所以我们只需要注意到这是一个很好的承诺。
然后它使我们进入第七次提交。 它有错误，因此我们将此提交标记为错误：
在最后一步中，我们进入第六次提交。 因为这是第七次提交的前一次提交（该提交发生了错误）。 所以我们将其标记为良好：
我们得到了关于提交使错误提交第七次的最终结果！ 我们只需要测试三次而不是七次！
我认为这是一个很好的 GIT 命令，可以帮助我们更轻松地进行调试。 如果您仍然想优化调试时间，可以尝试使用 git bisect run。 它将帮助你通过脚本检测提交是好还是坏。
本文中的最后一个命令是我希望能够应用到我的生活中的命令之一。
有时，我们在处理一些子任务的分支机构工作时会用到它。
例如：我们需要在页面上制作一个新按钮。
我们可能有三个基本任务：创建单元测试、按钮样式以及处理按钮单击操作。 我假设我们会按照“测试”、“样式”和“脚本”的顺序进行，完成所有这些任务后，我们意识到我们在创建测试时缺少一些东西。 我们应该做什么？
当然，我们会修复它。 但是在修复它并提交之后，我们可能会得到一个不太漂亮的提交列表。
让我们看一个例子：
在此示例中，我们只有一个“添加”提交。 可能没问题。 但是如果我们有很多这样的提交会发生什么呢？ 我们的提交树可能看起来像一件补丁衬衫。 为了解决这个问题，我们可以使用git fixup命令。
要使用这种方式，我们只需要按照正常的方式进行一些添加即可。 我们不需要像普通提交那样提交修复，只需使用选项 --fixup 和我们想要修复的提交的哈希值调用 git commit 命令即可。 它看起来像这样。
我们还有四个提交。 但最后一次提交与需要修复的提交具有相同的消息，并带有前缀“!fixup”。 为了使它们成为真正的解决方案，我们还需要采取进一步的措施。 只需要 git rebase -i --autosquash <previous base commit> 。 我们来试试吧！
完成啦！ 不再有“修复”提交。 提交列表现在很清楚了！
这就是我想在这篇文章中分享的全部内容。 我认为上面的命令使用起来并不太复杂。 每个人都可以轻松记住并使用它们。
本文链接：http://www.28at.com/showinfo-26-11828-0.html您可能会错过的七个有用的 GIT 命令
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 防御性编码的意识与实践
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
