ACRN作为开源项目，我们欢迎并鼓励社区贡献，直接向该项目提交补丁。在协作的开源环境中，制定提交补丁的规范和方式有助于减少在社区开发过程中可能出现的混乱。
本文档介绍了如何参与到项目沟通，记录错误和提交新的需求，以及向项目提交补丁，以便于补丁更快地被项目接受。
许可证
许可证对开源社区非常重要，它有助于确保软件在如作者所期望的条款下开发和使用。
ACRN项目使用BSD-3-Clause许可证，可以在GitHub ACRN 项目的license_header中找到。
许可证告诉，作为开发者您拥有的版权以及所有者提供的权利。贡献者全面理解许可权利并同意这些权利非常重要。有时版权所有人不是贡献者，比如当贡献者代表公司工作时。
开发者原始证书（DCO）
为了确保符合许可标准流程，ACRN项目制定了开发者需要遵守的原始证书流程(DCO)。
DCO是每个开发者贡献的证明。在贡献者提供的确认信息中（稍后的文章会做详细描述），开发者简单添加 一个Signed-off-by 声明，即意味着同意DCO。
当开发者提交补丁时，我们承诺贡献者有权利根据许可提交补丁。DCO协议如下所示，请参照：.
开发者证书1.1
为了对本项目作出贡献，我承诺：
a：贡献的全部或者部分是由我个人完成，并且我有权根据项目的开源许可指导对其提交；或者
b：据我所知，贡献是基于以前的具有合适的开源许可下的工作，无论我创建全部或者部分，我有权利在此同样的开源许可下提交工作修改（除非我被允许在不同的许可证下提交）；或者
C：贡献由其他人直接提供给我，并且他们认证了a、b、c条款，并且我对此没有进行修改。
d：我理解并同意这个项目和贡献是公开的，并且贡献记录（包括所有我提交的个人信息，包括我的信息签署）无期限地保持，并且会随着本项目或者所涉及的开源许可证重新分配。
DCO签署方式
DCO要求签署信息以如下格式，出现在每个提交请求中：
Signed-off-by: Acrnus Jones
可以将DCO文本手动添加到提交主体中，也可以将 -s 或者 --signoff 添加到常用Git提交命令中。如果您忘记添加签名信息，也可以运行 git commit --amend -s修改以前的签名提交。如果您已经将修改提交到GitHub，需要使用 git push -f.强制覆盖您的分支。
预备条件
作为一个贡献者，您需要熟悉ACRN项目，如：在ACRN项目网站（https://projectacrn.org）上介绍了如何配置、安装、使用ACRN项目；ACRN的入门指南（）介绍了如何设置开发环境。
您应该熟悉常用的开发者工具，如：Git和CMake，以及像GitHub这样的平台。
如果您还没这样做，您需要在上创建一个GitHub账户（免费），并且在开发系统中安装Git工具。
存储库布局
为了下载ACRN hypervisor 存储库，请使用：
git clone
为了下载ACRN devic-model存储库，请使用：
git clone
为了下载ACRN文档存储库，请使用：
git clone
Hypervisor Primer文档中描述了ACRN项目的目录结构。除了ACRN hypervisor和device model，您也会在ACRN文档网站找到技术文档的来源，所有这些开发者可以参与并加强。
提交问题
使用ACRN-dev邮件列表完成ACRN问题追踪。在开始修正问题前，请先阅读ACRN-dev邮件列表中的讨论，了解你想解决的问题报告。在ACRN-dev邮件列表中进行交流，看看别人如何看待您的问题（以及建议的解决方案）。您可能也会看到其他人遇到了与您类似的问题，或者对于更改和添加有类似的方案。向ACRN-dev邮件列表发送邮件，并和社区的开发者讨论您的想法。
在提交自己的问题之前，一个良好的习惯就是先搜索现有或者相关问题。当您提交了一个问题（错误或者功能请求时）后，ACRN项目团队通常会在几个工作日内对提交的问题进行审核和评论。
贡献工具和Git 安装程序
签名信息
在 Signed-off-by: 行上的姓名和你的邮件必须匹配并正确反映了作者信息。为了确保您的 .gitconfig 设置正确，请使用：
git config --global user.name "David Developer"
git config --global user.email david.developer@company.com
编码风格
使用统一的编码准则，以确保您的开发编译符合项目制定的风格和命名约定。
一般来说，需要遵从Linux内核编码风格，以下例外：
·为每一个 if 和 else 主体添加大括号，甚至单行编码模块也是如此。使用 --ignore BRACES 标识让checkpatch工具停止报错；
·根据需要，使用空格而不是制表符在声明之后对齐注释；
·用C89风格的单行注释 /* */， C99风格的单行注释 //是不允许的。
·使用 /** */ 作为需要出现在文档中的doxygen注释。
贡献工作流程
我们推荐的做法是提交小型的、可控制的更改。这种做法简化了审查、并使合并和重组更容易，保持变更历史清晰明了。
当您为ACRN项目做贡献时，很重要的一点就是您要提供尽可能多的关于更改的信息，升级合适的文档，并且在提交之前做足够的测试。
ACRN开发者使用的GitHub工作流程使用了命令行Git命令以及浏览器与GitHub交互。像Git一样，完成任务有多种方式。我们将在这里描述一种acrn-hypervisor项目中的典型工作流程，当然此方法也可以应用于acrn-devicemodel和acrn-documentation ：
1 在您的Github个人账户中建立一个个人的acrn-hypervisor （点击GitHub项目的acrn-hypervisor repo页面的右上角的fork按钮）；
2 在您的开发计算机中，复制您刚刚创建的fork；
3 git clone https://github.com//acrn-hypervisor
同时也有必要Git知道主acrn-hypervisor repo上的变化：
git remote add upstream https://github.com/projectacrn/acrn-hypervisor.git
并验证远程repo：
git remote -v
4为您的工作创建一个主题分支（如果您正在解决某个问题，我们建议在分支名字中包括问题编号）：
5git checkout master
6git checkout -b fix_comment_typo
7 作出更改、本地测试、更改、测试、再测试…
8 当问题解决并符合要求时，检查未存档的文体尚，并开始提交的流程过程：
9 git status
然后添加更改文件：
git add [file(s) that changed, add -p if you want to be more specific]
（使用git add 添加更改的文件）：
git add -A
10检查提交的修改是否与预期的一致：
11 git diff -cached
12 提交您的更改到本机代码仓库：
13 git commit -s
-s 选项自动将 Signed-off-by: 添加到您的提交信息中。如果没有signe-off-by行来表明您遵守与DCO的协议，您的提交将被拒绝。关于编写提交的具体指导，请参照以下的提交指南。
14将您的带有相应修改的话题分支提交到到您的个人GitHub账户的私有fork中：
15git push origin fix_comment_typo
16 在您的网页浏览器中，进入您的个人forked repo，并且点击分支的比较&推送请求按钮，选择刚刚提交的分支以及您想提交到的主repo分支。
17 检查相应的推送请求更改，并且确认你在为合适的分支创建推送请求。您提交信息的标题和信息也会出现。
18 GitHub将分配一个或者多个建议评审者（基于报告中的CODEOWNERS文件）。如果您是项目成员，您也可以选择其它的审阅者。
19 点击提交按钮，您的推送请求就会被创建，然后等待其他人的评阅。Gihub会把评论意见以邮件方式发送，或者您可以通过 查看对应的评审意见。
20当您等待推送请求被接受及合并时，您可以创建另外的分支来解决工作中遇到的其它问题（请确保您的新分支不是以前的分支）。
21git checkout master
22git checkout -b fix_another_issue
并且使用以上相同的流程来处理工作中遇到的新主题分支。
23 如果审阅者要求您对您的补丁不修改，您需要修复评审中的问题并添加对应的修改。在您的个人开发repo中，在您首次提交的分支上进行必要的更改：
git checkout fix-comment-typo
then:
git fetch --all
git rebase --ignore-whitespace upstream/master
24 --ignore-whitespace 选项来让git避免添加带有空格的修改。（称为重新定义）。继续：
git rebase -i
在交互式的编辑器中，用edit替代pick来选择特殊提交（如果您的推送请求中有多个提交），或者删除行来完全删除提交。然后编辑文件以修复评审中的问题。
像以前一样，检查并测试您的更改。准备就绪以后，继续补丁提交：
git add [file(s)]
git rebase --continue
如果需要，更新提交注释，并继续：
git push --force origin fix_comment_typo
通过强制推送更新，您的原始推送请求将随着您的更改而升级，因此您无需重新提交推送请求。
你可以在acrn-devicemodel 或者acrn-documentation 报告中使用相同的工作流程作贡献。
提交指南
更改将使用Git commits的形式提交，每个提交信息必须包含：
·一个少于72个字符的简短描述性的主题行，后跟一个空行。主题行必须包含一个描述被更改的subsystem前缀标识，后面跟着一个冒号和一个简短的标题，如： doc: update commit guidelines instructions.（如果您正在更新现有的文件，可以使用 git log 查看开发者在该文件以前的补丁中的所使用前缀标识）。
·一个关于更改逻辑的描述或者是修改的原因介，后面是一个空行。
·一般使用 git commit -s自动添加 Signed-off-by: 签名行；
·如果更改解决了一个问题，包含一行格式：
·Fixes #.
如上描述，发送到GitHub的所有更改和主题必须格式良好。
提交信息主体
当编辑提交信息时，请简单地解释您的更改内容，以及为什么需要更改。仅仅包含 "Fixes stuff" 总结的有可能会被拒绝。
注意：
不允许出现空白主题的修改。即使很小的更改，请提交信息中包含总结摘要主体。
提交信息的描述主题必须包含：
·更改做了什么；
·为什么选择这种方式；
·做了什么假设，以及
·你如何知道可以工作，比如：你运行了哪些测试；
关于已经接收提交信息的示例，你可以参考acrn-hypervisor GitHub更新日志。
其它提交预期
·当提交在顶部应用后必需可以进行编译，因此避免破坏分叉；
·每个commit必须解决单个可识别的问题，并且必须在逻辑上独立。无关的更改应该作为独立提交而提交；
·您可以提交推送请求RFC（请求注释）来发送工作提议，工作进展，或者提前获得关于可能影响代码库中多个部分的功能或更改的反馈。
识别贡献来源
当增加新文件时，重点要说明文件的原始来源，提供归属，并详细说明预期用途。当文件是首次添加到acrn-hypervisor的情况下，提交信息应该包含以下内容（如果没有原始标记，则假定是原始）：
Origin: Original
在外部项目导入文件的情况下，提交信息应该包含原始项目、项目位置、文件原始提交的SHA-id、预期用途，以及文件是否由acrn-hypervisor维护（不管ACRN项目是否包含本地化分支，或者是否是下游副本）。
例如：本地维护的导入副本：
Origin: Contiki OS
License: BSD 3-Clause
URL: http://www.contiki-os.org/
commit: 853207acfdc6549b10eb3e44504b1a75ae1ad63a
Purpose: Introduction of networking stack.
Maintained-by: acrn-hypervisor
例如：本地维护的导入副本：
Origin: Tiny Crypt
License: BSD 3-Clause
URL: https://github.com/01org/tinycrypt
commit: 08ded7f21529c39e5133688ffb93a9d0c94e5c6e
Purpose: Introduction of TinyCrypt
Maintained-by: External
--End--
第四十一届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：fanwei
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
