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