如何贡献代码 Bitcoin 核心
Bitcoin 核心项目按照开放式贡献者模式运作，欢迎任何人以同行评价、测试和打补丁的形式为它的发展做出贡献。本文档说明了做出贡献的操作流程和指导。
首先，在结构方面，没有所谓的特权 “核心开发人员”的特殊概念。开源通常自然而然地围绕有才能的人展开，而长期贡献者会获得开发者社区更多的信任。 但是出于实用的角度某些层次是必不可少的。因此有知识库“维护者们”负责合并拉取请求以及一个“牵头维护者”负责发布周期、整体合并、模式化和任命维护人员。
贡献者工作流程
代码库通过“贡献者工作流程”维护，在这里所有人都无一例外地采用拉取请求贡献补丁提案。这有利于促进社区贡献、简单测试和同行评审。
贡献补丁的工作流程如下：
- 对版本库进行分叉
- 创建主题分支
- 提交补丁
必须遵守 开发手册 规定的项目代码规范。
通常情况下 提交应该是原子化的 并且差异应该容易阅读。 出于这个原因请不要将任何格式修正和代码移除与真正在的代码修改混在一起。
提交信息应当有详细描述， 默认是由一行简短的主题行（最多50个字）、一行空行加详细的说明文字组成的段落；除非标题已经是不言自明的 （如“更正 main.cpp 中的拼写错误”），那么一个标题行就足够了。提交的信息应该有助于将来其他人阅读您的代码，因此请您解释做此决定的理由。 进一步解释请 点击这里。
如果某个提交提及另外一个问题，请添加参考信息，例如关于＃1234，或修复＃4321。使用修复或关闭关键字将导致拉取请求合并过程中相应的问题被关闭。
关于 Git 的更多问题请参考 Git 操作手册。
- 将变更推送到你的分叉
- 创建拉取请求
拉取请求的标题应该将拉取请求所影响的组件或领域加为前缀。 范例：
共识: 为 BIP-XXXX OP_CHECKAWESOMESIG 添加新的 opcode
净: 自动生成隐藏服务，监听 Tor
Qt: 添加新的 bump 按钮
不重要的: 修改 main.cpp 的拼写错误
如果一个专门的拉入请求（尚且）不应被合并请使用 [WIP] 做为标题前缀或使用拉取请求主体中的 任务列表 来表示任务仍未完成。
拉取请求的主体应该就补丁的用途以及理由/原因给予足够的描述。您应该引用任何相关的讨论（例如其他问题单或邮件列表讨论）。
在这个阶段提交者应当预期收到其他贡献者的意见和评审。您可以通过本地提交的方式多次提交代码，然后将他们推到你的分叉上，直到满足所有反馈意见。
改写提交
如果您的拉取请求被接受予以合并，维护者可能要求您在合并前改写和／或 重新基线 您提交的代码。 基本的 squash 工作流程如下所示。
git 签出 your_branch_name
git 重新基线 -i HEAD~n
# n 通常代表一个拉取请求里提交的次数
# 将提交从 'pick' 设置成 'squash'，保存并推出
# 在下一个屏幕上，修改／润色提交信息
#保存并推出
git push -f # (强制推到 GitHub)
同行评审需要的时间不可预期并且每个拉取请求的评审时间都不尽相同。
拉取请求原则
补丁集应该有侧重点。例如，一个拉取请求可能添加一个功能、修复一个缺陷或者重构代码；但不能是是这些的混合。也请避免提交太多内容、 太大或太复杂的超级拉取请求，因为很难评审。
功能
在添加新功能时，必须要考虑到引入代码后的长期技术债务和对该功能的维护。在提议一个需要维护的新功能前， 请考虑一下你是否愿意对它进行维护（包括错误修复）。如果将来功能变成没人维护的孤儿，他们可能会被知识库维护者删除。
重构
重构是任何软件项目演进的必要组成部分。下列指导原则涵盖了项目的重构拉取请求。
共有三个类别的重构，只移动代码、代码风格修复和代码重构。一般来说，为了使重构拉入请求易于评审和无争议的，不应混用这三种活动。 在所有情况下，重构PR一定不能在拉取请求中改变代码的行为（错误必须原样保留）。
项目维护者的目标是重构拉取请求能快速周转，所以尽可能保持简短、不复杂和容易验证。
决策流程
以下适用于 比特币核心项目（以及相关的项目，如libsecp256k1）的代码更改，不要与整个比特币网络协议共识的变更相混淆。 一个拉取请求是否被合并到比特币核心取决于项目合并维护者，并最终取决于项目牵头人。
只要与项目的总体方针相符合的补丁维护者都会予以考虑；达到引入的最低条件；并判断贡献者的普遍共识。
总的来说，所有的拉取请求都必须：
- 有清晰的用例、修复一个可证明的错误或提高程序整体能力（例如为了模块化而重构）;
- 经过同行充分评审；
- 在适当情况下进行单元测试和功能测试；
- 遵守代码风格指南； -不破坏现有的测试套件；
- 只要进行了错误修复，在可能的情况下都应该进行单元测试来证明缺陷和修复。这有助于预防迭代。
改变比特币共识规则的补丁参与的人会显著增加，因为它们影响整个生态系统，因此事前必须进行大量的邮件列表讨论，并有BIP编号。 虽然每一个案例都会有所不同，但由于增加的同行评审和共识条件的建立，大家应当准备好投入比其他各类补丁更多的时间。
同行评审
任何人都可以通过发布拉取请求评审意见参与同行评审。通常评审人会评审代码中的明显错误，同时测试补丁组并对补丁的技术优点给出意见。 在确定是否存在共识合并拉取请求时（记住，讨论可能已经在github、邮件列表和IRC讨论区展开了），项目维护者会考虑同行评审的意见。拉取请求评论中会使用以下语言：
- ACK 指 “我已经测试过代码并且同意将其合并 “；
- NACK指”我不同意将其合并”，并必须提交合理的技术理由。不附带理由的NACKs将被忽略。
- utACK指”我还没有测试过代码，但我检查过代码并认为可行，我同意将其合并”；
- Concept ACK指”我原则上同意这个拉取请求 “；
- Nit 指小问题，通常不会造成阻碍的为题。
评审人应当将他们在评审意见里评审过的提交哈西表包括在哪 。
项目维护者保留使用常识判断来衡量评审人意见的权利，并也可能基于才能进行权衡：那些（长期以来） 已经展示了对项目更大的承诺和认识或有明确的专业领域知识的人自然会有更多的权重，正如人们在各行各业所预期的一样。
凡是影响关键共识代码的补丁集，讨论和同行评审要求的门槛就会高出很多，请牢记失误对更大范围的社区来说可能代价惨重。这也包括对核心共识代码的重构。
凡是提议更改比特币共识的补丁集，一定是已经在邮件列表和IRC上深入讨论过的，伴有大规模讨论过的BIP，并且是基于维护者的判断达成了普遍技术认同的， 被认为值得的一个改变。
版本发布政策
项目带头人是每个比特币核心版本发布的发布经理。