Git 如何重新定义了开源软件开发

还没有读者喜欢这篇文章。
words saying developing possibilities

Opensource.com

不难想出十几个不同的理由来解释为什么开源开发的兴起一直是软件和硬件行业的分水岭事件。我们所有人都可以借助 jQuery、Bootstrap 和 Apache 的力量,更快地构建新的 Web 应用程序。像 Ruby、PHP 和 Python 这样的语言为互联网提供动力,而像 Linux 和 FreeBSD 这样的操作系统为成千上万的公司和服务奠定了基础。

但是,开源不仅仅关乎我们可以免费使用的工具,还关乎开发者社区,他们将帮助支持疯狂的新想法,并给它们一个蓬勃发展、成长和改变世界的机会;这些想法在闭源世界中永远不会出现。

我最喜欢的例子是一个与我息息相关的工具,因为它让我在开发世界中的小众领域再次感到兴奋:Git。在 Git 之前,版本控制领域已经变得陈旧;动荡的 90 年代让位于 21 世纪版本控制超级大国之间的冷战。Git 带回了关于版本控制工作流程的辩论! 甚至仅仅是人们再次关心版本控制工具就很有趣了。对于版本控制爱好者来说,这简直是天堂。

Git 是一款出色的软件,它重新定义了我们进行开源开发以及更广泛的软件开发的方式。当然,在此之前已经有其他分布式版本控制工具,但在我在这个行业工作期间,没有什么能像它这样戏剧性地改变我们版本控制和共享工作的方式。

但这有点疯狂。其大部分功能和灵活性都由一个核心的版本化文件系统提供,该文件系统可以以多种不同的方式使用。在核心引擎之上构建了数十个命令,每个命令都有数十个标志,所有这些命令都以有用(如果偶尔不可预测)的方式操作该系统。其中许多命令是独立演变的,由不同的开发人员编写。因此,它们可能对类似问题采取非常不同的方法。

Git 也是由一个非常习惯使用命令行的社区编写的。他们习惯于在没有护栏的环境中工作:任何曾经不小心在错误的地方运行过“rm -rf *”的人都会告诉你,这是一个你只会犯一次的错误。 这样做的一个副作用是,Git 的护栏不如用户可能从版本控制系统期望的那么多。

我个人最喜欢的一个例子是 reflog。如果您不熟悉 Git,它可以大致描述为更改了您的版本化文件的版本控制操作的本地日志。当您运行错误的命令并且表面上丢失了所有工作时,reflog 是您的救星。Git 最棒的地方在于它永远不会消失,您只需要知道在哪里查找。

现在想象一下,Git 是在一个典型的闭源公司中创建的世界。想象一下董事会会议,会上揭示了

董事会: “这是一项了不起的技术!这将改变一切。您看到任何挑战吗?”

开发人员: “嗯,我们确实发现有时我们会不小心删除当前分支并丢失所有工作……”

董事会: “嗯,这当然只是一个 bug?我想您会添加一个护栏来防止数据丢失吧?”

开发人员: “这真的不是一个 bug。我们只需要学习如何更好地使用该工具。但是,我们有一个解决方案可以缓解意外数据丢失。”

董事会: “谢天谢地!那是什么?”

开发人员: “我们采用了更通用的解决方案。我们放入了一个名为 reflog 的单独版本控制系统,这样我们就可以对您的版本控制操作进行版本控制。如果您删除了分支,您只需扫描 reflog 以查找相应的 SHA 并恢复它即可!”

董事会慢慢地退出了房间。

正如 Steve Losh 的 Git Koans 等文章所展示的那样,Git 有很多古怪之处。我个人很难想象一家公司会构建和销售像今天这样设计的 Git。对于新用户来说,不一致之处和陷阱太多了。 但是,这些不一致之处和陷阱是作为强大而灵活的工具的自然副作用。没有这些粗糙边缘的 Git 不一定是我们都认识和喜爱的 Git。

好消息是,开源开发社区在那里培育和支持它,添加了很棒的功能(如 bisect),并提供了大量的优秀文档和教程来教新手入门。这种支持帮助一块璞玉几乎成为世界上最流行的版本控制系统。

我们都有一些疯狂的想法,我们一直在思考,但不确定该如何处理。将这些想法变为现实可能很可怕——失败很糟糕。花你的周末构建一些最终没有人关注的东西可能会令人沮丧。好消息是,如果您的想法具有一些潜力,那么会有一个社区愿意帮助您让您疯狂的钻石闪耀光芒。谁知道呢,您一直在脑海中盘旋的周末项目也可能彻底改变软件开发。

 

标签
User profile image.
Matt Attaway 是一位多面手,也是一些领域的专家,曾担任测试员、开发人员、研究员、设计师、经理、DevOps 工程师和大象训练师。他目前在 Perforce Software 管理开源开发团队,但在那之前,他领导一个测试团队,负责 Perforce 最受瞩目的项目。

4 条评论

Git 是一个很棒的工具,我经常使用它。

但是它的“不一致”、“陷阱”和“粗糙边缘”根本不是必需的。它们是纯粹的 bug。“它按设计工作,不可能是 bug”对于 UI 问题根本不是一个有效的论点。第一步:承认存在问题。

好消息是,其中许多问题相对容易修复。首先确定关键问题;页面 http://stevelosh.com/blog/2013/04/git-koans/ 是一个不错的开始。然后找出改进的语法以支持*除了*旧语法之外,并修改文档以鼓励使用新语法。

我同意语法不一致可以而且应该修复,但对我来说,缺乏护栏、对 reflog 的依赖以及 Losh 在他的 Git Koans 中谈到的历史的短暂性不太可能改变。它们也让我觉得是 Git 被认为非常强大和灵活的部分原因;它几乎不会阻止您做任何事情。

我真的很想花更多时间学习 Mercurial;到目前为止,我所花费的时间让我相信它几乎拥有所有功能,但界面更加一致。

我认为说分布式版本控制系统改变了我们的开发方式更准确。而不是 git。人们常常将 DVCS 的好处完全归功于 git,并以此为理由将其置于集中式版本控制系统之上。

许多项目仍然使用 SVN,并且他们运行良好。Bazaar 和 Mercurial 都优于 Git。这些都是分布式版本控制的例子,不必那么难用。最好的工具就是不碍事。

这绝对更准确;Git 恰好是大多数人知道的系统。随着 GitHub 的普及以及 Git 在 Android 和 iOS 开发世界中的使用,DVCS 很容易与 Git 混淆,但还有其他很棒的开源工具不应被遗忘。

Linus 编写 Git 为 Git 提供了一个其他工具难以匹敌的平台。如果他编写了 Hg,我怀疑我们都会谈论 Hg 和 MercHub。

话虽如此,我对 Hg 正在做的一些工作感到非常兴奋;他们正在谈论的安全重写已发布历史记录的能力可能会改变游戏规则,并真正推动我们对版本控制系统的期望。为竞争欢呼!

© . All rights reserved.