关于 Git 的 6 大提示和技巧

引言

Git 在软件开发领域是协作工具中的佼佼者。即便是独立工作的程序员，也经常依赖 Git 来管理代码版本。虽然大多数人习惯于通过命令行操作 Git，但许多编程工具和集成开发环境（IDE）都提供了 Git 的集成功能，使得日常开发更加便捷。尽管 Git 应用广泛，但许多程序员对 Git 的深度功能了解有限。

如果您对 Git 的基础操作已经有所了解，本文将助您一臂之力，让您在协作中更加游刃有余。

这些 Git 的小技巧和窍门，将大幅提升您的工作效率和编程生产力。毕竟，熟练掌握您频繁使用的 Git 工具，将让您有更多时间专注于编写代码。想象一下，如果能够减少在 git merge 和 git rebase 之间犹豫不决的时间，那该多好！

1. 创建空提交

你是否曾为了启动持续集成（CI）构建或其他集成流程，而不得不对 README 文件做些小修改来调试问题？我过去经常这么做，直到我发现了一个非常实用的命令：

git commit --allow empty -m 'it works!' 

这个 git 命令允许你即使没有更改任何文件内容，也能成功提交，避免了通常因为没有暂存的更改而出现的错误提示。这个技巧尤其适合在不需要对 README 或其他文件进行任何实际更改的情况下启动工作流程。虽然 git diff 命令不会显示任何差异，但这个提交在你需要触发 CI 流程或甚至是生产环境部署时非常有用，无需推送任何无关的代码。

2. 美化 git log 输出

使用 git log 命令来查看代码库的最新变动非常有效，但如果在一个包含众多分支的项目中使用，你很快就会感到眼花缭乱。这里有一个让 git log 命令更加生动有趣的 git 小技巧：通过增加颜色显示，帮助你更清晰地理解屏幕上的信息。

想要在不修改 Git 配置的情况下获得更易读的 git log，只需执行以下命令：

git log --pretty=oneline --graph --decorate --all 以下是你将看到的示例输出：

git log --pretty 命令在终端中以彩色和基本图形展示

你会看到通过颜色编码以及使用 | 和 \ 符号来清晰地标示分支。虽然这些选项在功能上并不改变日志的内容，但它们无疑让理解 git log 的输出变得更加直观和容易。

3. 清理本地分支

如果你和我一样，喜欢保持工作环境井然有序，包括你的电脑桌面。

软件开发很容易让你的代码库变得杂乱无章，尤其是当你在多个项目中工作时。而使用 Git 时，这种情况会变得更加严重，因为即使分支已经没有用处了，它们仍然会长时间存在于每个代码库中。

随着时间的积累，你可能会在 Git 配置中添加一些个性化设置。我特别喜欢一个 Git 配置选项，它能够在执行 fetch 或 pull 操作时自动删除那些已经从远程仓库中移除的本地分支。你可以通过执行以下命令来启用这个功能：

git config --global fetch.prune true 除了调整 Git 配置之外，还有一个更进一步的 Git 使用技巧：通过执行一条命令来删除那些已经合并到 master 分支的本地分支，这样可以避免不必要的分支堆积。这个命令如下：

git branch --merged master | grep -v "master" | xargs -n 1 git branch -d

4. 恢复已删除的提交

git rebase 的使用非常宝贵，特别是当你启用 --interactive 选项时。但是，变基操作存在风险。如果你在本地执行变基，你可能需要强制推送来覆盖远程仓库的更改。如果你频繁地进行变基，你可能会不小心丢失一些提交。

如果你像我一样不走运（或缺乏了解），你甚至可能不小心删除了一周的工作成果。我最喜欢的 Git 小技巧是使用 git reflog 来恢复那些丢失的提交。

只要你的工作已经提交，不管你对 git rebase 做了哪些操作，它都会保留在你的本地工作副本中。通过使用 git reflog，你可以找到你需要的 SHA1 哈希值。然后，执行 git checkout <SHA1> 来检出那个特定的提交，取出你需要的内容，接着执行 git checkout HEAD 回到本地分支的最新提交。这样，危机就被成功避免了！

5. 别名 git blame

有时，我们会遇到一些棘手的 bug，单凭自己的力量难以解决。在这种情况下，你可能想要联系那些编写了出现问题代码的同事。或许，你只是想与代码的原作者交流，以便更深入地理解代码背后的情境。

git blame 是一个常用的工具，帮助我们找出特定代码行的作者。它不仅告诉你谁写了这行代码，还能告诉你他们是什么时候写的，以及这行代码是在哪个提交中首次出现的。许多代码编辑器和集成开发环境（IDE）都内建了这一功能，能够在代码旁边显示作者的名字。

尽管这是一个实用的 Git 特性，但 git blame 这个名字听起来可能会让人感觉不太舒服。在软件开发团队中，培养一种无责任归咎的文化是非常重要的，而这个命令的命名可能会传递出错误的信息。

幸运的是，有一个好消息：你可以通过在 Git 配置中设置别名，来更改 Git 命令的调用方式，这可以说是最无私的 Git 使用技巧了。如果你想将 git blame 命令更名为 git investigate，以便更加温和地探索代码，你可以执行以下命令：

git config --global alias.investigate blame 你完全可以根据个人喜好，将 "investigate" 替换为任何其他词汇。此外，Git 配置文件还可以用来为其他命令设置别名，这样你就可以根据自己的需要，对 git blame 之外的命令进行个性化命名。

6. 交互式暂存提交

文章一开始，我就承诺我们会深入探讨 git add 命令之外的内容。

你或许已经了解，使用 git add 可以一次性将本地仓库的所有更改加入暂存区。

你也许还知道，通过运行 git status 查看哪些文件发生了变化，使用 git diff <filename> 来查看特定文件的详细更改，以及使用 git add <filename> 来逐个暂存文件，是一种更为详尽的操作方式。这在处理单个文件时是可行的，但当你面对大量本地更改时，这种方法很快就会变得繁琐。

这种详尽的选项虽然操作稍多，但它至关重要，因为它帮助你确认你加入暂存区的确实是你打算提交的本地更改。最糟糕的情况莫过于无意中提交了某些内容，尤其是当这些内容包含敏感信息，比如应用的密钥时。幸运的是，有一个更高效的方法来暂存你的更改！

你可以通过执行以下命令来分步暂存更改：

git add -p 这可能是本文中最能节省时间的 Git 使用技巧。这种方式会启动一个交互式界面，展示每个文件中被修改的部分，并让你选择是暂存、跳过还是进行其他操作。

这不仅让暂存过程更加容易，同时确保你能够逐个验证每个更改，而且当你只想提交文件中部分更改时，这个功能尤其有用。有时候，我可能会不小心做出太多更改，意识到这些更改中只有一部分适合一起提交。

小结一下

作为程序员，持续学习和充电非常重要，作为开发者，我们需要保持好奇心和学习热情，不断探索新的技术，只有这样，我们才能在这个快速发展的时代中立于不败之地。低代码也是一个值得我们深入探索的领域，让我们拭目以待，它将给前端世界带来怎样的变革。

介绍一款程序员都应该知道的软件JNPF快速开发平台，很多人都尝试用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。

JNPF 可以实现应用从创建、配置、开发、测试到发布、运维、升级等完整生命周期的管理。减少了传统应用程序的代码编写量，通过图形化、可视化的界面，以拖放组件的方式，即可快速生成应用程序的产品，大幅降低了开发企业管理类软件的难度。