Git命令生成器 — 停止每天在谷歌搜索相同的命令

我曾经有一个浏览器标签页永久打开着git文档。不是因为我不了解git——我已经使用了多年——而是因为我总是忘记我只是偶尔使用的命令的确切语法。当我想取消暂存但不丢失更改时，是git reset --soft还是git reset --cached？git stash apply是删除stash还是保留它？设置上游的标志是-u还是--set-upstream？

我认识的每个开发者都有这种经历的某个版本。Git是那种在几周内日常命令就成为反射动作的工具，但中等频率的命令——每隔几天或每周使用一次的命令——从来就不太稳固。学了，忘了，再学，再忘。

ToolBox Hub上的Git命令生成器正是为这些时刻而存在的。您可以按类别过滤，按您想做的事情搜索，填写分支名或提交哈希，然后复制完整命令，而无需搜索文档或调试错误标志。

工具的工作原理

打开Git命令生成器时，您会看到一个搜索栏和一行类别按钮：Basic（基础）、Branching（分支）、Remote（远程）、Undo（撤销）、Stash（暂存）和Advanced（高级）。

命令卡片每张都显示等宽代码块中的命令、对其功能的简明英文描述以及复制按钮。对于需要参数的命令——分支名、文件路径、提交哈希——卡片下方有一个文本输入框。您输入的内容会实时替换到命令模板中，因此复制按钮始终复制可直接运行的版本。

例如，如果您点击"创建并切换到新分支"卡片，在分支名字段中输入feature/payments，命令块立即更新为git checkout -b feature/payments，这就是复制到剪贴板的内容。

搜索栏在命令名称和描述中进行过滤，因此您可以输入"undo"查看所有相关命令，或输入"stash"将完整的stash工作流放在一起。

您实际会使用的命令

与其按字母顺序列出所有40多个命令，不如按它们在真实工作日中出现的方式来介绍各个类别。

设置和日常基础

Basic类别中的命令是在您的第一个月内就成为肌肉记忆的命令。git status可能是使用最多的git命令——它告诉您什么已暂存、什么未暂存以及什么未被跟踪。git add .暂存当前目录中的所有内容。git commit -m "消息"创建一个提交。

我看到开发者在这个类别中未充分利用的两个命令是git diff和git diff --staged。在添加任何内容之前运行git diff，可以准确查看自上次提交以来工作树中发生了什么变化。添加后运行git diff --staged，可以查看实际进入下一次提交的内容。养成在每次提交前检查这些的习惯，可以发现令人惊讶数量的调试日志、被注释掉的代码块和意外的文件包含。

git log --oneline是另一个被低估的日常工具。默认的git log输出冗长到难以浏览。--oneline版本将每个提交压缩为一行：哈希值的前7个字符和提交消息主题。查找您要找的提交要快得多。

分支策略

Branching类别涵盖从创建分支到合并和打标签的所有内容。

git checkout -b <分支>（或更新的git switch -c <分支>）是大多数功能工作的开始方式。命名它，切换到它，然后构建。当工作完成后，您打开拉取请求或将其合并回去。标准流程。

人们感到模糊的命令是git merge对比git rebase。两者都将一个分支的变更集成到另一个分支，但方式不同。

git merge创建一个合并提交。您的分支历史和目标分支历史都得以保留，合并提交显示它们结合的位置。如果您查看git图，合并提交会创建一个菱形。这忠实于实际发生的事情——两条并行的工作流合并了——对于团队工作流来说是安全的默认值。

git rebase获取您的提交，将分支指针倒回到目标分支末端，并在其上重放您的提交。结果是没有合并菱形的直线提交。优点是可读性——git log更容易跟踪。缺点是rebase会重写提交哈希，如果其他人已经拉取了这些提交，就会产生问题。规则：在个人或本地分支上rebase，在共享分支上merge。

git branch -d <分支>在合并后删除本地分支。Git在这里是保守的，如果分支有未合并的提交，会拒绝删除。如果您真的想丢弃一个未合并的分支，请使用-D（大写）。生成器专门包含-d是因为它是安全版本。

与远程协作

Remote类别涵盖接触服务器的命令。

git fetch origin与git pull有微妙的不同。Fetch只从远程下载新的提交和分支——完全不碰您的本地分支。Pull是fetch后接合并。我更喜欢先fetch，然后在合并之前查看变化，特别是在活跃的共享分支上。这是一个小习惯，不止一次让我避开了意外冲突。

git push -u origin <分支>是新分支的第一次推送。-u标志设置上游跟踪关系，因此在此之后，该分支上无参数的git push和git pull会自动工作。如果您在第一次推送时跳过-u，后续的git push调用会提示没有配置上游。

git remote -v是"我的设置是什么"命令。在任何不熟悉的仓库上，立即运行这个命令，告诉您fetch和push的去向。令人惊讶的是，这经常会暴露出指向意想不到位置的远程。

git cherry-pick <哈希>值得一提。它将历史中任何地方的单个提交复制到您的当前分支。经典用例：一个热修复已合并到main，但您正在一个也需要该修复的长期运行功能分支上工作。Cherry-pick提交哈希，它就落在您的分支上，而没有main的其余变更。

撤销错误

这是人们最紧迫搜索的类别。出了什么问题，您需要在不让情况变得更糟的情况下撤销它。

git reset --soft HEAD~1是最温和的撤销。它将分支指针向后移动一个提交，但保留所有变更处于暂存状态，可以重新提交。当您提交得太早，想要添加更多变更或重写消息时使用这个。

git reset HEAD~1（默认的"mixed"模式）向后移动指针并取消暂存变更，但将其留在您的工作树中。当您想在重新暂存之前重新检查更改时使用这个。

git reset --hard HEAD~1是核武器选项。它向后移动指针并完全丢弃变更。没有内置的撤销——变更从工作树中消失了。只有在您确定不需要那些变更时才使用它。

**git revert <哈希>**是当您想撤销的提交已经被推送时的正确工具。Revert创建一个新提交，应用原始变更的逆操作。历史得以保留。拉取了它的队友的工作不会被打扰。

git restore <文件>丢弃对特定文件的工作树更改。git restore --staged <文件>取消暂存文件，不改变工作树。这些命令在Git 2.23中作为重载的git checkout和git reset的更清晰替代而添加，更容易推理。

暂存进行中的工作

Stash是"我现在需要切换上下文但还没准备好提交"的逃生口。

git stash将您的未提交变更（已暂存和未暂存的）保存到一个堆栈，并将您的工作树恢复到最后一次提交的状态。您现在可以切换分支、拉取变更、修复一个bug——任何您需要的事情。当您回来时，git stash pop恢复您的变更。

git stash push -m "描述性消息"一旦您有超过一个stash条目时，就比简单的git stash更值得使用。消息使您在后来运行git stash list时更容易识别条目。名为WIP: 重构认证中间件的stash条目比stash@{2}有用得多。

git stash apply stash@{1}应用特定条目而不将其从列表中删除。当您想将相同的stash应用于多个分支时很有用，或者当您还没准备好弹出它时。

高级和不常用命令

Advanced类别涵盖偶尔出现但难以记住的命令。

git log --oneline --graph --all是我推荐所有人定期在其仓库上运行的命令。ASCII分支图给了您一个关于您的分支如何关联的视觉图景——哪些已经分叉，合并在哪里发生，标签在哪里。这是使抽象版本历史变得具体的命令之一。

git bisect start开始二分搜索以查找哪个提交引入了bug。您用git bisect good <哈希>标记已知良好的提交，用git bisect bad <哈希>标记已知有问题的提交，git为您签出中间点提交进行测试。您继续标记good或bad，直到git确定出问题的确切提交。对于不运行代码就难以复现的bug，bisect是无价之宝。

**git blame <文件>**显示谁最后修改了文件的每一行以及在哪个提交中修改的。这个名字听起来带有指责性——实际上，它通常通过查找提交并阅读其消息和差异来理解某行代码为什么是现在这个样子。优秀的团队将blame用于上下文，而非指责。

git reflog是救援命令。即使在硬重置后，git也会保留HEAD所在位置的内部日志。如果您不小心销毁了需要的提交，git reflog会向您显示需要用git reset --hard <恢复的哈希>来恢复它们的哈希值。我见过这个命令挽救了数小时的工作。

更流畅Git工作流的专业技巧

几个能带来显著差异的习惯：

用祈使句写提交消息。 "添加认证中间件"而不是"添加了认证中间件"或"正在添加认证中间件"。这个惯例之所以存在，是因为git自己的生成消息（合并提交、reverts）使用祈使句，所以您的消息自然地整合进去。

频繁地小量提交。 原子提交——每个提交一个逻辑变更——使git log可读，使代码审查更容易，并使git bisect有效。每天提交一次带有巨大"进展"消息的提交会失去git的大部分价值。

积极使用.gitignore。 构建产物、IDE元数据、环境文件——这些永远不应出现在您的仓库中。如果git status因您从不打算提交的文件而杂乱，请修复您的.gitignore。

学习--patch标志。 git add --patch（或git add -p）让您以交互方式选择要暂存文件的哪些块。当一个文件有两种不同目的的变更时，您可以将它们拆分为单独的提交。这是您在实际开发的混乱现实中工作，同时维护干净、有意义的提交历史的方法。

值得与此配合使用的工具

如果您在花时间处理git工作流，网站上还有几个其他工具直接相关：

Cron解析器 — CI/CD管道通常在事件触发任务旁边有计划任务。如果您的部署管道包括cron计划，并且您需要解码或构建cron表达式，这个工具可以即时处理。

URL编码器 — Git远程URL有时包含需要编码的字符，特别是当认证凭据或令牌嵌入URL中时。如果远程URL没有被正确解析，请先通过编码器运行它。

常见问题

git fetch和git pull有什么区别？ git fetch从远程下载新的提交和分支，但不碰您的本地分支。git pull是fetch后接合并。当您想先检查时使用fetch，当您准备集成时使用pull。

如何撤销已推送的提交？ 使用git revert <提交哈希>创建一个新提交，在不重写历史的情况下撤销变更。git reset只对尚未推送的提交安全。

git stash有什么用？ Stash临时搁置未提交的变更，让您可以切换上下文——切换分支、拉取变更、应用热修复——而无需提交半成品工作。当您回来时，git stash pop恢复变更。

什么时候应该用rebase而不是merge？ 在您想要合并到main之前想要干净线性历史的个人分支上。永远不要rebase其他人已经拉取的提交——它重写哈希并导致冲突。

如何在git reset --hard之后恢复提交？ 运行git reflog查看HEAD位置的历史。找到您需要的提交哈希，运行git reset --hard <那个哈希>来恢复它。

总结

Git是开发者工具包中几乎比其他任何东西都更值得时间投入的工具之一。感觉神秘的命令会变得自动化，曾经需要文档标签的工作流会成为第二天性。

Git命令生成器是为中间阶段准备的——当您知道需要做什么但记不清确切语法时。将其加入书签、使用它，当您使用了足够多次之后，您可能已经记住了这些命令。