> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/2021-0304-freebsd-13.0/git.md). # Git 不够吗？ * 原文链接：[Can’t Git Enough?](https://freebsdfoundation.org/wp-content/uploads/2021/05/Practical-Ports-Cant-Git-Enough.pdf) * 作者：BENEDICT REUSCHLING 本专栏介绍 FreeBSD 的 Ports 和软件包，它们在某些方面有用，或者奇特，或者值得了解。Ports 扩展了基本系统的功能，确保你能完成某些工作，或者仅仅是让你会心一笑。一起来看看吧，也许你会发现新东西。 你可能已经知道，FreeBSD 13.0 是第一个从 Git 而非 Subversion 仓库构建的主要版本发布。这一变更历经了长时间的筹备，对让 FreeBSD 如此宝贵的源代码的处理非常谨慎。我清楚地记得很多年前在荷兰马尔森举行的一次 FreeBSD 开发者峰会，当时 FreeBSD 项目决定最终采用 Subversion。从 CVS（可能还有更早的 rcs，问问那些比我更早参与的开发者们）转过来，切换版本控制系统显然不是容易的事。尤其是当你的历史可以追溯到加州大学伯克利分校那些最初的日子时，每一次的变更都非常珍贵。你永远不知道什么时候会需要翻出某个晦涩的历史事实，因为某个设备驱动程序出现异常，或者某个开发者需要了解为什么接口以某种方式实现。但切换版本控制系统不仅仅是技术任务，也是社会性任务。这需要说服并吸引那些在切换后会使用它的人。关于 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 for Developers”课程。与 Allan Jude 一起，他是每周 bsdnow\.tv 播客的主持人。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/2021-0304-freebsd-13.0/git.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.