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 git 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，“the.图书馆目录jdk / jdk存储库大约有300 MB，包含Git和.hg目录大约1.2 GB(使用Mercurial)
• 令人印象深刻的性能指标和GitHub托管服务的受欢迎程度(截至2020年5月为5000万用户提供服务)
• GitHub提供的广泛API的可用性，改进了变更集的开发和审查过程(不再仅仅依靠邮件列表来与贡献者协作)

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

“…有机会接触到现有的大型开发人员和潜在贡献者社区。”

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

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

没有付出就没有收获

我不会说谎。在我的位置上，使用新开发工具的最初几周非常艰难。那时我已经有了足够长的职业生涯，用我最熟悉的工具开发了相当多的捷径和提高效率的技巧。你知道开别人的车时那种不舒服吗?-当你意识到刹车的反应与你习惯的不同时，你会感到焦虑吗?或者当你疯狂地寻找如何启动挡风玻璃刮水器时?这种感觉至少要增加十倍!我的肌肉记忆让我不停地键入键和使用不存在的快捷键，或者错误地使用SVN命令而不是Git命令。我记得我用新笔记本电脑的第一个晚上看了如何使用Mac的视频。美好的时光，完全值得!

当转到一个新的开发团队时，我也必须跟上他们正在使用的开发过程的速度。这是当我被介绍到GitHub拉取请求(PR)过程。OpenJDK的贡献者现在将经历同样的过程——通过PR审查提议的更改。

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

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