# Git 不够吗？

* 原文链接：[Can’t Git Enough?](https://freebsdfoundation.org/wp-content/uploads/2021/05/Practical-Ports-Cant-Git-Enough.pdf)
* 作者：**BENEDICT REUSCHLING**

你可能已经知道，FreeBSD 13.0 是第一个从 Git 而非 Subversion 切换的主要版本发布。这一变更历经了长时间的筹备，处理 FreeBSD 源代码的方式非常谨慎，因为这正是 FreeBSD 之所以宝贵的原因。我清楚地记得很多年前在荷兰马尔森举行的一次 FreeBSD 开发者峰会，当时 FreeBSD 项目决定最终采用 Subversion。作为曾经使用过 CVS（可能还有更早的 rcs，问问那些在我之前就已经参与的开发者们）的开发者，切换版本控制系统显然不是一件容易的事。尤其是当你的历史可以追溯到加州大学伯克利分校那些最初的日子时，每一次的变更都非常珍贵。你永远不知道什么时候你需要翻出某个晦涩的历史事实，因为某个设备驱动程序发生了异常，或者某个开发者需要了解为何接口是以某种方式实现的。但切换版本控制系统不仅仅是个技术任务，它还是个社会性任务。这需要说服并吸引那些在切换后会使用它的人们。关于 Git 的争议颇多，很多人对 Git 的行为有所疑虑。重新学习一些版本控制系统的概念以及 Git 是如何处理这些问题的，可能是应对它的最佳方法，当然，还要保持开放的心态。

当然，在切换之前，Git 就已经在 Ports 中存在，许多开发者已经用它来处理自己的个人项目或工作中的项目（有时甚至没有选择）。那些怀念 Subversion 等系统中的“中央真实来源”方式的人，可以通过使用 www/gitlab-ce 设置一个 Gitlab 系统。在一个雨天的封锁日，系统的额外 Port 能让你忙得不亦乐乎。图形用户界面将 Git 的许多“缺陷”隐藏在一个用户友好的界面背后。从通过上传更改版本的文件替换它，并将其转变为一次提交并推送到读取版本历史记录，所有这些都无需了解任何 Git 命令。这些类似的用户界面，如 www/gitea、devel/cgit、devel/git-cola，使得非开发者也能轻松在办公室环境中跟踪文档，无论这些文档是否与 IT 相关。这个小小的“文件时间机器”对任何需要旧版本文件的人都非常有用，尤其是当你的猫不仅在键盘上走来走去，还顺便把文档保存了的时候。特别值得一提的是，当你当时正在使用 vi 时，它帮助你避免了文件被错误保存的尴尬。

软件开发似乎从来都不是一项简单的任务，因此任何可以获得的帮助都备受欢迎。我一直在想，开发者是如何开始的：他们是先为自己的软件想个名字，还是立刻开始编写代码？如果你想不出一个好名字，而 asdf、qwerty 等类似的名字已经被占用了（我们在这里不讨论这些名字，保证），那不妨试试老式的反向命名方法？这肯定启发了 devel/tig 的作者，他写了一个基于 ncurses 的 Git 终端界面。为什么不呢？通过这种方式浏览你版本控制的树结构很快，暂存下一个更改、查看历史记录、写下那个简短的、糟糕的提交信息（不过不建议这样做——给历史学家提供一些更多的信息，告诉他们为什么你在凌晨 4:20 做了这个更改）都可以做到。

在我的 Unix 课堂上，我不止一次告诉学生，Unix 开发者们其实很懒，但是一种好的懒惰。我的意思是，他们坐下来，弄清楚如何让同事的计算机做得更好，并投入了大量的精力。一旦完成，他们就可以懒惰，因为硅芯片做了所有艰苦的工作。这种懒惰并不是为了懒惰本身，那可能是最高级的拖延症。但无论如何，如果你也在这个阵营中，可以看看 devel/lazygit。这个用 Go 写的终端 UI 在它的项目页面上开始了一段有趣的抱怨：

“抱怨时间：你听说过，Git 很强大，但当一切都这么难做时，这种力量有什么用？交互式变基要求你在编辑器里编辑一个该死的待办事项文件？你在开玩笑吧？要暂存文件的一部分，你需要使用命令行程序逐个浏览每个修改块，如果某个修改块不能再分割，且其中包含你不想暂存的代码，你必须手动编辑一个晦涩的补丁文件？你在搞笑吧？！有时，你被要求在切换分支时将更改暂存，结果你切换并取消暂存后，才意识到根本没有冲突，直接切换分支其实没问题？你简直是在开玩笑！”

但是，在抱怨之后，开发者坐下来让每个人的生活变得更好。看吧，每个人都可以做到。这个界面足够好，可以试试。另一个供命令行爱好者使用的类似工具是 devel/glab。这个为 Gitlab 编写的工具让你离开熟悉的网页 UI，留在终端中，那才是进行真正有趣操作的地方。

源代码的编写往往需要与他人协作。我的代码在有另一个人审查后，确实变得更好了。在他们从头到尾浏览过后，大家毫不避讳地指出我可以改进的地方，并在此过程中分享了他们的智慧。当然，也有偶尔的赞扬，这让我没有一开始就从事腊肠走私的职业。GitHub 上的代码审查（现在不仅是酷孩子的聚集地，几乎任何需要为文件提供仓库的人都会使用）通常是通过 Gerrit 代码审查工具进行的。如果你在那儿花了很多时间，考虑安装 devel/git-review 来支持你的编码工作流并与他人一起进行审查。

初学者可以看看 devel/easygit，以便让体验变得不那么痛苦或让人不知所措。对于那些使用 Git 很长时间并且想炫耀自己仅仅因为频繁提交而修改了多少行代码的人，devel/gitinspector 可能会有所帮助。只要装饰好你的办公室（而不是食堂）——否则人们很快会提醒你，质量才是最重要的，而不是数量。

Git 不是唯一的版本控制工具，过去有，将来也会有其他工具。它的流行无疑不容忽视，而且肯定是因为它包含了一些人们所需要的功能。如果你想要版本控制，但不想用 Git，最简单的方法是什么呢？你可以在电子邮件中保存多个草稿，附件中是你正在处理的文件，或者直接将内容粘贴到邮件正文里。如果你选择通过 Webmail 在另一台计算机上继续工作，这种方式甚至是分布式的。当然，这也有它的缺点，如果你给别人访问你的“仓库”的权限，这将是一个安全噩梦。但或许这种体验会足够让你决定给 Git 一个第一次、第二次甚至第三次的机会。不妨拿起一本书，做一个在线教程。毕竟，传统的“通过实践学习”也是非常有效的。毕竟，参与开源项目的人永远都不够。全身心投入其中，别忘了在过程中摘取一些“樱桃”。

***

**BENEDICT REUSCHLING** 是 FreeBSD 项目的文档提交者，也是文档工程团队的成员。他是 FreeBSD 基金会董事会的副主席，曾两次担任 FreeBSD 核心团队成员。他在德国达姆施塔特应用科技大学管理一个大数据集群，还为本科生开设“Unix 开发者课程”。他与 Allan Jude 一起主持每周的 bsdnow\.tv 播客。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://book.bsdcn.org/qi-kan/2021-0304-freebsd-13.0/git.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.