我对我在工作中使用的一个相当大的开源项目上的拉取请求感到有点困惑。我不会透露该项目，但它包含大量用户提交的脚本，用于监视关键任务系统或应用程序的各个方面。我找到了一个用户提交的shell脚本，我需要将它用于我自己的工作，但它有几个主要的错误，并且在风格上是一个残骸。我修复了错误，并重构了几乎整个脚本，使其达到了一个相当干净的“bash形式”。我对脚本做了拉取请求，项目负责人拒绝了带引号的补丁：
“这主要是编码风格的变化。你的努力确实如此 赞赏，但如果我们开始接受那种，我们将无法到达任何地方 补丁。请尽量专注于这件事，即真正的东西 需要修理。谢谢！“
以下是我在整个脚本中进行的可读性的bash编码样式更改示例：
- start_time=`date +%s%N`
+ start_time=$(date +%s%N)
这在开源项目中是否常见？我承诺的大多数项目都是我自己的，我一直在重构风格错误的代码。如果代码将被其他人使用，如相关脚本，是否应该欢迎可用性重构？我只是有点困惑，因为该项目没有编码风格指南。
答案 0 :(得分：2)
您是否拆分了补丁，以便首先修复错误并在以后进行样式更改？如果没有，我也会拒绝补丁。改变逻辑的补丁应尽可能小且独立。没有人想要进行数十种样式更改，以确保在尝试理解您修复的内容时对逻辑没有任何影响。
答案 1 :(得分：1)
这在开源项目中绝对不是普遍的事情。我将从最近的拉动请求中给出一个反例：
https://github.com/djcb/mu/pull/65
我的拉请求与mu的Emacs组件有关，称为mu4e。我唯一的变化是通过M-x customize（Emacs相当于＆＃34;编辑 - ＆gt;首选项＆＃34;或者＆＃34;工具 - ＆gt;选项＆＃）从项目中创建更多变量34）。根本没有对任何程序逻辑进行任何更改。正如你所看到的，拉动请求在两小时后没有任何麻烦而合并。 （我以前从未为这个项目做过贡献，所以我没有根据我过去的贡献或类似的东西进行快速跟踪。）这就是拉动请求的一个例子在没有任何投诉的情况下愉快地接受了。
至于为什么有问题的项目拒绝了你的补丁，也许他们只是顽固或太骄傲，不能让别人在他们的代码或类似的东西中弄乱，但另一方面，有正当理由不要合并化妆品非面向用户的变化。如果他们接受您的代码并且他们至少负有最低限度的责任，他们必须至少查看您所做的所有更改，并确保您没有破坏某些内容，并确保您的代码更改与之匹配你的提交日志说你改变了什么。我猜你的拉请求改变了许多文件中的一大堆孤立的行或块，对吧？如果您使用$()进行全面搜索并替换反引号，那么这可能就是您最终的结果。这种补丁很难验证，因为你在线上看到相同的变化，你的眼睛茫然，你错过了一个缺少近距离的情况，导致整个项目中断。
关键在于，即使您免费提供代码，实际合并代码也不是免费的，并且将代码集成到项目中所涉及的工作必须通过以下方式完成：运行项目的人，否则他们将合并他们不能信任的代码。在某些情况下，拥有项目的人可能会查看您的更改声称要改进的内容，并做出合理的决定，即这些改进不能证明以负责任的方式合并代码所需的工作量。如果您不同意，您可以自由创建自己的分支（不是＆＃34;敌对＆＃34;分叉，只是普通的＆＃34;项目X与我的自定义＆＃34;分叉并将您的更改放在那里，并自己使用它们。如果您的更改真的值得拥有，那么人们可能会开始切换到您的分支，此时原始开发人员可能会重新考虑他们的位置并合并您的更改。
答案 2 :(得分：0)
每个项目都有自己的规则和指南。你被告知这个项目适用于你工作的规则。如果你想贡献，听起来你必须遵守他们的规则。 （我倾向于在辩论中站在你一边 - 但是当我不负责时，我遵守那些人的规则！）