Java 16提交到Git和GitHub:个人反思

在记忆的小路上漫步

我是在2014年5月接触到Git和GitHub的——距离现在还不到10年Git创建于2005年．同一天，我还得到了一台MacBook Pro笔记本电脑和IntelliJ许可证，这是我在一家新公司的新职位上开始我作为开发人员的新角色的主要工具。这一切听起来都很美好，对吧?

在我的职业生涯中充满了激动人心的机遇和新的征程，我小心翼翼地不让恐惧扭曲了我表达感激之情的方式。你看，我并没有想到这些“新奇”。事实上，那一刻在我的脑海里，我想在第一天就大干一场的计划破灭了。有三个简单的原因。首先，我是一个忠实的Windows用户。有几次，我的目光游离在一位同事的Mac显示屏上，但仅此而已——仅此而已。第二个原因是我习惯于使用Eclipse作为我的主要IDE。IntelliJ对我来说是一个全新的动物。第三，当时我唯一熟悉的源代码控制管理系统是Apache Subversion(又名SVN)。

今天，我仍然在使用MacBook Pro、IntelliJ，当然还有Git和GitHub，我很感激能够接触到这个工具集。这并不是说这些工具比我以前使用的工具更好．在这种情况下，更多的是关于什么能让我在新岗位上更有效率．并且考虑到这些是我的新团队在我到来之前确定的开发工具，工具集中的一致性使得我的环境的建立变得轻而易举。有一步一步的，最新的指导来建立我将要从事的项目，如果有任何问题，我有同事的支持。使用这些工具成为了我的第二天性，从那时起，除了一个使用不同源代码控制系统的项目(这非常烦人)，没有人要求我使用任何不同的工具。

Java 16 Gits With The Program

当我读到新的Java 16版本的相关JDK增强建议时，我所分享的所有这些记忆都涌上了我的脑海。中357描述了将OpenJDK社区的源代码存储库从Mercurial迁移到Git的过程。中369描述了迁移到GitHub来托管这些存储库。

如果您不熟悉OpenJDK是如何开发的，或者没有参与过这个项目，那么在此期间，OpenJDK实际上是由Mercurial存储库支持的，这对您来说可能是个新闻!尽管版本控制系统在当时很流行，但时代已经发生了变化。

有人可能会说，考虑到Git在开发人员和其他开源社区中的流行和广泛使用，Java姗姗来迟。2004 - 2020年底谷歌趋势分析在这方面，Git的流行度迅速增长，在2011年左右超过了SVN的流行度，相比之下，Mercurial和并发版本系统(CVS)一直徘徊在较低的值。

来源:谷歌趋势

如果你建立了它，他们就会来

迁移到Git和GitHub背后有几个动机，包括但不限于:

• 在使用Git和Mercurial时，可以保留磁盘空间并提高克隆时间(根据JEP 357，.目录jdk / jdk存储库包含Git和.hg目录大约1.2 GB的Mercurial”)
• 令人印象深刻的性能指标和GitHub托管服务的受欢迎程度(截至2020年5月服务5000万用户)
• GitHub提供的广泛API的可用性，改进了变更集的开发和审查过程(不再单独依靠邮件列表与贡献者协作)

使用像GitHub这样的外部主机提供商的动机之一，对我来说最突出的是——直接来自中369：

“…这是利用现有开发者和潜在贡献者社区的机会。”

这不是仓促作出的决定，也不是凭空作出的决定。我们仔细考虑了这一举措将如何影响现有开发人员以及未来潜在贡献者的工作流程。为了尽可能多地保护现有的建筑，政府做出了深思熟虑的决定尽可能使用工作流，以保持有经验的贡献者的生产力，同时启用未来开发人员更喜欢的其他工作流。以前可能被OpenJDK特定工具集阻碍的开发人员，现在可以更容易地使用他们熟悉和熟悉的工具成为潜在的贡献者。

考虑到今天我们所拥有的与Git和GitHub集成的所有工具——最流行的文本编辑器，最流行的ide，以及许多桌面客户端——这是有意义的!

没有付出就没有收获

我不会撒谎。我在新开发工具岗位上的头几周非常艰难。那时我已经在我的职业生涯中度过了足够长的时间，用我最熟悉的工具开发了相当多的捷径和提高效率的技巧。你知道开别人的车带来的不适吗?——当你意识到刹车的反应与你习惯的不同时的焦虑时刻?或者当你疯狂地寻找如何启动雨刷时?这种感觉至少要增加十倍!我的肌肉记忆让我不停地输入键和使用不存在的快捷键，或者错误地使用SVN命令而不是Git命令。我记得我用这台新笔记本电脑的第一个晚上是看如何使用Mac电脑的视频的。

作为一个典型的转移到一个新的开发团队时，我还必须跟上他们正在使用的开发流程。这是当我被介绍到GitHub Pull Request (PR)过程时。OpenJDK的贡献者现在将经历同样的过程——通过PR审查提议的更改。

在完成自动检查以验证更改的有效性，并自动向适当的邮件列表生成电子邮件以表明PR已准备好进行审查之后，GitHub API功能使贡献者可以以几种不同的方式与PR进行交互。审阅者可以在打开浏览器的情况下使用审阅工具https://github.com/；通过他们最喜欢的文本编辑器、IDE或桌面应用程序的GitHub集成工具;或者通过命令行使用开发的工具项目Skara．一个用户实际上甚至不需要一个GitHub帐户，通过相关的邮件列表与公关互动!-来自邮件列表的评论被添加到PR中，并反映在所有其他工作流中。

我们投入了大量的时间和精力来让这个过程尽可能轻松，希望鼓励贡献者之间更多的合作，甚至吸引已经享受GitHub提供的便利的巨大开发者社区的更多贡献和合作。鉴于我过去改变开发工具和工作流的经验，我完全理解保持过程尽可能顺利是多么重要。我也理解为什么这一举动花了这么长时间——这是一个不可思议的壮举。

结论——选择的力量

我期待看到Java 16发布的成功，OpenJDK使用托管在GitHub上的Git存储库。我确信，在增加OpenJDK贡献者基础的背景下，这将会成功的主要原因之一是，许多与工具相关的障碍已经被移除。由于Git和GitHub的流行，许多开发人员已经有了一个帐户，并熟悉如何使用它。他们不再需要设置任何特定于OpenJDK的工具，也不再需要承担学习使用他们不经常使用的东西(抱歉，是Mercurial)的认知负荷。

在GitHub取得成功以及决定使用GitHub作为OpenJDK的外部托管提供商的过程中，与开发人员已经使用的工具进行的开发集成发挥了巨大的作用，这一点也不能夸大。

这种“开放”的心态让我想起了JFrog与DevOps团队已经在使用的工具集成的努力。例如,JFrog管道可以利用现有的GitHub集成使用GitHub中的存储库触发CI/CD管道的构建，以及JFrog Artifactory支持将大型源文件管理为二进制文件Git大文件存储(LFS)存储库。

我们将时间和精力投入到我们的开发和运营工作流中，当这些已经基于最佳实践时，最好的改进是无缝地适合我们现有的流程，而不会给每个相关的人带来麻烦。时间会证明这一举措是否实现了JEP 357和JEP 369所希望实现的目标。与此同时，为Java 16的发布以及它与Git和GitHub的新关系干杯!

在这篇博客文章中阅读更多关于Java 16发行版如何改进Java工件打包的信息：
在Java 16 Release中，jpackage是生产就绪的

Java^®是Oracle和/或其关联公司的注册商标。