给开源项目贡献代码_我的第一个开源贡献：保持代码相关-优快云博客

给开源项目贡献代码

先前，我解释了分叉存储库的重要性。一旦完成了发出第一个开源请求请求的实际“编写代码”部分，我就会感觉很棒。似乎困难的部分终于结束了。而且，我对编写的代码感到很满意。

我决定要做的一件事（事实证明这是一个不错的选择）是使用测试驱动开发（TDD）编写代码。使用TDD很有帮助，因为它为我提供了一个起点，并提供了一种方法来了解我的工作是否真正有效。因为我的背景是构建Web应用程序，所以我很少遇到编写没有明显可见输出代码的问题。测试优先的方法帮助我快速开发了一种无法手动评估进度的工具。我编写了明确的测试的事实也帮助我最终使我的请求请求被接受。审阅者在对我的代码的评论中突出了测试。

我感到非常高兴的另一件事是，我用大约20行代码完成了整个过程。我从经验中知道，较短的请求请求更容易检查。这样的短篇幅通常会花费较少的时间，并且审阅者只能专注于少数几行更改。我希望这会增加我的机会，让其中一位维护者看我的工作并对它充满信心。

令我惊讶的是，当我最终将分支推送到GitHub时，差异表明我已经更改了多行代码。我在这里遇到了麻烦，因为我对惯常的开发设置感到太自在了。因为我通常只从事一个项目，所以我几乎不会考虑在后台使用的一些工具可以使我的生活更轻松。罪魁祸首是prettier的代码格式化程序，它可以在我保存编辑后的文件时自动修复我所有的较小间距和语法差异。在我通常的工作流程中，此工具非常有用。与我合作的大多数开发人员都安装了prettier ，因此我们编写的所有代码都遵循相同的样式规则。

prettier永远不会忽略规则。在我工作时，它主动将我更改的每个文件中的每个双引号都转换为单引号，从而导致数百次无意更改。

我花了几分钟时间删除了这些更改，但是由于它们在我工作时一直在发生，因此它们嵌入了我的所有提交中。然后，我身上的B型车接管了，并决定保留这些更改。“也许这没什么大不了的，”我想。 “毕竟他们说他们想要单引号。”

我的错误是在PR中包含了这些无关的更改。从技术上我认为这不是什么大不了的事情，但是查看我的代码的维护人员要求我还原所做的更改。我最初的直觉是将我的拉取请求保持在很小的范围内，这是正确的。

这里的教训是，您应将更改保持在最小限度并尽可能地切合实际。请注意您拥有的可能适用于正常工作流程的任何工具，但是如果您在处理新项目，则没有那么有用。

自由的想法：如果您正在寻找一种无需编写任何代码即可获得开源PR的方法，请选择一个不遵循其样式指南的项目，对其进行prettier处理，然后将结果作为您的全部请求。不能保证每个项目社区都会对此表示赞赏，但是值得一试。