Git 技巧与窍门

原文 ↗ Hacker News 讨论 ↗

Git 的高级特性，尤其是面向大型仓库的功能、历史重写和 blame 管理，随着 Git、GitHub 以及第三方工具不断演进而再次受到关注。评论者一边交流实用技巧（别名、外部 diff 工具、`reflog`、`--force-with-lease`、blame ignore 文件），一边争论开发者应当拥抱 Git 的强大能力，还是躲在更简单的 GUI 和 porcelain 之后。其背后是更宏观的一个问题：易用性与能力之间的权衡。Git 的 plumbing 被赞赏为概念上优雅，但其用户界面被认为会“漏风”，因此人们呼吁更好的前端、替代 VCS，以及更易上手的文档。

对文章/演讲的总体反应

  • 许多评论者认为这些技巧以及相关演讲信息量很大、也很有趣，即使是有经验的 Git 用户也是如此。
  • 几位人士表示，作者之前的 Git 文档塑造了他们对 Git 的理解。
  • 有些人建议补充内容：提到 .git-blame-ignore-revs、--force-if-includes，以及更多关于历史简化和基于 diff/patch 的操作（例如 rebase）的细节。

Git 的复杂性、学习曲线与预期

  • 一个反复出现的主题是“我只想 push/pull”和“工程师应该多懂一些”之间的张力，尤其是 reflog 和基本的历史重写，以避免灾难。
  • 一些人认为 Git 天生复杂，因为它所解决的问题本身就复杂；另一些人则反驳说，Git 的 porcelain 设计很差，违背了 KISS 原则，并指出 Mercurial 或 pijul 的设计更清晰。
  • Git 常被描述为最初只是“plumbing”并且 UI 极少，这也解释了它粗糙的边角和会泄漏的抽象。

CLI 与 GUI，以及人们实际上如何使用 Git

  • 有些人自豪地坚持使用 CLI，因为它更快、可脚本化、且更便携（例如通过 SSH 登录服务器）。
  • 另一些人则强烈偏好可视化工具（GitKraken、SmartGit、TortoiseGit、IDE 集成），用于查看图形、diff、解决冲突和检查 reflog，只在特殊情况下才使用 CLI。
  • 一个折中方案：用 GUI 做可视化/diff，用 CLI 做核心操作和高级修复。

概念模型：快照 vs diff

  • 讨论集中在 rebase、cherry-pick 和 merge：人们强调，尽管 Git 存储的是快照，这些操作在概念上是围绕 diff/三方合并进行的。
  • 有些人表示，把 Git 教成“在快照存储之上进行基于 diff 的操作”会让 rebase 的行为更直观。

工具、别名与扩展

  • 分享了很多技巧：外部 diff 工具（difftastic、delta）、导航辅助（git root、zoxide）、分支清理（git gone）、模糊添加工作流，以及自定义的“sync/publish/PR”别名。
  • Git“通过脚本实现 porcelain”的模式：放在 PATH 中的 git-foo 脚本可通过 git foo 调用。
  • 其他受赞赏的实用工具包括：git-extras、git-absorb、“git attic”，以及一个会列出文件中所有提交 blame 的脚本。

大型仓库、性能与维护

  • 人们对大型仓库特性（fsmonitor、maintenance、Microsoft/GitHub 的贡献）以及 Git LFS 集成很感兴趣；但尚不清楚 LFS 是否会成为“核心”功能。
  • 关于 git maintenance、垃圾回收时机以及丢失 loose objects 的担忧，出现了一些问题和部分回答。
  • 围绕通过不稳定连接克隆超大 monorepo 的痛点；大家希望克隆/fetch 支持可恢复继续。