在 Github 上分叉一个 Ruby/Rails gem 的正确协议/礼仪是什么，可以作为一个持续的并行分叉进行维护？答案

【问题标题】：What is the correct protocol/etiquette for forking a Ruby/Rails gem on Github that may be maintained as an ongoing, parallel fork?在 Github 上分叉一个 Ruby/Rails gem 的正确协议/礼仪是什么，可以作为一个持续的并行分叉进行维护？
【发布时间】：2013-02-12 04:03:15
【问题描述】：

最近我使用了一个由单个开发人员创建的不错的 gem，它托管在 Github 上。

在我的工作中，我不得不对它进行了一些实质性的修改，增加了一些改进。有些是特定于项目的，有些是特定于 gem 的，还有一些是独立改进的。

对于特定于 gem 的改进（例如，错误修复），我分叉了存储库，应用了修复，并提出了拉取请求。

然而，我注意到独立改进属于原始 gem 的并行、持续分支的类别。更清楚地说，你以前见过它；我重写了原始 gem 的视图以使用 Twitter Bootstrap 框架。所以，我也将它推送到了 Github，但是，当然，没有提出拉取请求——相反，我更新了 README 以解释不同之处，并感谢 gem 的原作者。

我的问题是，在这种情况下还应该做什么，假设 gem 是其他人想要使用的东西并且要在 rubygems 等上发布？我是否应该简单地编辑 .gemspec 并保持原作者的信息完整，但将我的信息添加到作者/电子邮件字段，并重写任何其他已更改的内容？还是应该完全重写 .gemspec？

另外，如果原始发行版有远程测试框架（如 travis.yml），这些是应该删除还是保留？

是否还有其他通常必须更改/重新创建的文件？

到目前为止我已经更新了

.gemspec
README.md
CHANGELOG.md
lib/libraryname/VERSION.rb #called as a constant in .gemspec

最后一个问题本身提出了一个单独的额外问题，版本控制如何在并行发行版中工作？

【问题讨论】：

我问过类似的问题：stackoverflow.com/questions/4753461/…
谢谢。但是，在这种情况下，仍会保留原始版本；分叉更多的是修改版本，而不是原始版本的更新或进步。
在这种情况下，您应该只维护 fork，而不是释放它，然后使用 git: 选项将其添加到您的 Gemfile 中。
我想你误会了；修改是对公众有价值的东西；类比是不同的 Linux 发行版等。不赞成投票。

标签： ruby-on-rails ruby github rubygems gem

【解决方案1】：

听起来您已经正确处理了错误修复/分叉。

根据 gem 的许可证，将其发布为 yourname-originalname。

您进行了整个社区可能感兴趣的重大更改，这是分叉和发布的公认标准。

它还解决了您的奖金问题。更改您想要发布的任何内容。它现在基本上是一个新项目。当然，还是要归功于原始开发人员:)

【讨论】：