多年来，我发现一些对 docrails 确切含义以及它与 Ruby on Rails 文档的关系感到迷惑。
这篇文章解释了你想要了解的这个项目的所有内容。
docrails 是 Ruby on Rails 的一个分支，拥有公共写入权限，任何人都可以推送文档修订。
如果你发现一个错别字，你想纠正事实性错误，补充一些现有文档，添加一个有用的示例……在 docrails 存在之前，你必须打开一个提交请求（或那时的情况），并按照常规工作流才能获得接受。docrails 允许你克隆存储库、编辑和推送。完成！
在代码库中的更改需要审核，方可推送。每个单独的新功能或错误修复需要核心团队成员的观点和责任来做出决定。
然而，文档修订很可能本来就很好了。因此，docrails 有一个公共写入策略，以简化贡献者的工作流程。
无论如何都必须审查所有提交，所以 docrails 需要 Rails 提交者与通过提交请求一样的努力，请所有人都对 Vijay Dev 表示感谢，他如今负责这个费时的任务。
docrails 的目的是提供一种为 Rails 文档做出贡献的方式，这对贡献者而言既快速又简单。
docrails 是一个单独的分支，因为它有不同的访问策略，但是你正在编辑实际的 Ruby on Rails 文档。
每隔几天，一旦所有新提交都得到审核，docrails 就会与主分支合并，主分支也会与 docrails 合并。另外，非常重要的编辑可能会根据合并人的判断，樱桃挑选到稳定分支。
你可以自由推送对任何 RDoc、指南和自述文件所做的更改。
任何代码都不能被触及。这是条硬性规定。无论多么微不足道，即使字符串遍历中出现一个字符的错别字。
CHANGELOG 也不可以编辑。
不是，Ruby on Rails 没有文档项目。将文档作为项目的独立部分对待与将测试作为项目的外部部分对待类似。
文档是 Ruby on Rails 开发的一个组成部分。贡献一个功能或错误修复意味着贡献它的代码、测试覆盖率和文档。
不，docrails 仅用于快速文档修订。
请求合并应包含有代码、测试和文档。 如果在请求合并中缺少这些元素，那么它不会被直接接受。
此外，更新文档并不意味着您将 RDoc 编辑到您正在修改的代码旁边。通常，要更新示例、修改因您的更改而受到影响的说明或编写新的文档，需要搜索项目树查找与请求合并相关的内容实例。
小技巧：运行 ack -a 以将指南包含在搜索中。
Rails 发布是一个完整集合。文档本身是该版本的一部分。当包含修复程序的分支发布时，该修复程序将通过 稳定 API 或 指南 网站上线。
合并到 master 中的编辑始终在 边际 API 和 边际指南 中在线，这些指南会在每次推送至 master 后重新生成。因此，在 docrails/master 交叉合并之后，通过 docrails 执行的编辑会在边际文档网站上线。
当然。特别是如果您不确定修复程序时。但是，如果您信心十足，只要将它推送至 docrails 即可。
请勿在 docrails 中提交合并请求。
请注意，docrails 没有问题标签。原因正是如上所述， docrails 不是一个项目，而只是绕过合并请求的一种方式。文档问题是 Ruby on Rails 中的问题，与任何其他类型的问题一样，也属于 Ruby on Rails 项目。
没有，文档随每次推送至 master 而提供。每个人都在编写 Rails 文档。
唯一的例外是指南作者。指南作者承担起编写某个主题的全新指南的任务，而且为了方便起见，允许他们将早期草稿推送到 docrails 中（公开索引中只有指南会被认为已发布）。
这是新的指南。一旦发布，指南维护中发生的一切都与其他内容一样。