如何贡献代码

我们真诚地感谢您的贡献，欢迎通过 GitHub 的 fork 和 pull request 流程来提交代码。

教程

VisualDL 目前使用Git流分支模型进行开发，测试，发行和维护，以下教程将指导您提交代码。

  • Fork

跳转到VisualDL GitHub首页，然后单击 Fork 按钮，生成自己目录下的仓库，比如 https://github.com/USERNAME/VisualDL。

  • 克隆（Clone）

将远程仓库 clone 到本地：

  1. git clone https://github.com/your-github-account/VisualDL
  2. cd VisualDL
  • 创建本地分支

所有的 feature 和 bug fix 的开发工作都应该在一个新的分支上完成，一般从 develop 分支上创建新分支。

使用 git checkout -b 创建并切换到新分支。

  1. git checkout -b my-cool-stuff
  • Virtualenv

virtualenv是一个独立的Python虚拟环境。我们强烈建议您使用virtualenv来保持你的Python环境清洁。要创建虚拟环境并激活它，请使用以下命令。

  1. pip install --upgrade virtualenv
  2. virtualenv YOUR_VIRTUAL_EVN_FOLDER
  3. source YOUR_VIRTUAL_EVN_FOLDER/bin/activate

完成此工作后，可以通过操作来解除虚拟环境。

  1. deactivate

要了解更多关于virtualenv，点击[这里]（https://virtualenv.pypa.io/en/stable/）

  • commit

在进行你的第一次之前，请先安装必要的工具，像是flake8, yapf 与 pre-commit 工具。VisualDL 开发人员使用 pre-commit, flake8, yapf 工具来管理 Git 预提交钩子。 它可以帮助我们格式化源代码（C++，Python），在提交（commit）前自动检查一些基本事宜。不满足钩子的 PR 不能被提交到 VisualDL，首先安装并在当前目录运行它：

  1. pip install -r requirements.txt
  2. pre-commit install

VisualDL 使用 clang-format 来调整 C/C++ 源代码格式，请确保 clang-format 3.8 版本在 3.8 以上。请下载且安装在 path上. 例如 /usr/local/bin

  1. # For example, install clang-format on Mac
  2.  
  3. tar xvfJ clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz -C ./clang_mac_install/
  4. cd clang_mac_install/clang+llvm-3.8.0-x86_64-apple-darwin/bin/
  5. ln -s $(pwd)/$(find clang-format | grep bin/clang-format$) /usr/local/bin/clang-format
  6.  
  7. # or directly mv clang-format binary to there
  8. # mv clang-format /usr/local/bin/

Git 每次提交代码，都需要写提交说明，这可以让其他人知道这次提交做了哪些改变，这可以通过git commit 完成。

  1. git commit
  2. yapf.................................................(no files to check)Skipped
  3. Check for merge conflicts................................................Passed
  4. Check for broken symlinks................................................Passed
  5. Fix End of Files.........................................................Passed
  6. Trim Trailing Whitespace.................................................Passed
  7. Detect Private Key.......................................................Passed
  8. Check for broken symlinks................................................Passed
  9. Check for added large files..............................................Passed
  10. clang-format.........................................(no files to check)Skipped
  11. python-format-checker................................(no files to check)Skipped
  12. [my-cool-stuff c703c041] add test file
  13. 1 file changed, 0 insertions(+), 0 deletions(-)
  14. create mode 100644 233
  • 构建和测试

Users can build VisualDL natively on Linux and Mac OS X.

  • 保持本地仓库最新

在准备发起 Pull Request 之前，需要同步原仓库（https://github.com/PaddlePaddle/VisualDL）最新的代码。

  1. git remote add upstream https://github.com/PaddlePaddle/VisualDL
  2. git pull upstream develop
  • Push 到远程仓库

将本地的修改推送到 GitHub 上，也就是 https://github.com/USERNAME/VisualDL。

  1. # 推送到远程仓库 origin 的 my-cool-stuff 分支上
  2. git push origin my-cool-stuff
  • 建立 Issue 并完成 Pull Request

建立一个 Issue 描述问题，并记录它的编号。

切换到所建分支，然后点击 New pull request。选择目标分支：

screen shot 2017-04-26 at 9 09 28 pm

在 PR 的描述说明中，填写 fix #Issue编号 可以在这个 PR 被 merge 后，自动关闭对应的 Issue，具体请见 https://help.github.com/articles/closing-issues-via-commit-messages/。

接下来等待 review，如果有需要修改的地方，参照上述步骤更新 origin 中的对应分支即可。

  • 删除远程分支

在 PR 被 merge 进主仓库后，我们可以在 PR 的页面删除远程仓库的分支。

screen shot 2017-04-26 at 9 18 24 pm

也可以使用 git push origin :分支名 删除远程分支，如：

  1. git push origin :my-cool-stuff
  • 删除本地分支

最后，删除本地分支。

  1. # 切换到 develop 分支
  2. git checkout develop
  3. # 删除 my-cool-stuff 分支
  4. git branch -d my-cool-stuff

至此，我们就完成了一次代码贡献的过程。

提交代码的一些约定

为了使评审人在评审代码时更好地专注于代码本身，请您每次提交代码时，遵守以下约定：

  • 请保证Travis-CI 中单元测试能顺利通过。如果没过，说明提交的代码存在问题，评审人一般不做评审。
  • 提交PUll Request前：
    • 请注意commit的数量：
      • 原因：如果仅仅修改一个文件但提交了十几个commit，每个commit只做了少量的修改，这会给评审人带来很大困扰。评审人需要逐一查看每个commit才能知道做了哪些修改，且不排除commit之间的修改存在相互覆盖的情况。
      • 建议：每次提交时，保持尽量少的commit，可以通过git commit —amend补充上次的commit。对已经Push到远程仓库的多个commit，可以参考squash commits after push。
    • 请注意每个commit的名称：应能反映当前commit的内容，不能太随意。

  • 如果解决了某个Issue的问题，请在该PUll Request的第一个评论框中加上：fix #issue_number，这样当该PUll Request被合并后，会自动关闭对应的Issue。关键词包括：close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved，请选择合适的词汇。详细可参考Closing issues via commit messages。此外，在回复评审人意见时，请您遵守以下约定：

  • 评审人的每个意见都必须回复（这是开源社区的基本礼貌，别人帮了忙，应该说谢谢）：

    • 对评审意见同意且按其修改完的，给个简单的Done即可；
    • 对评审意见不同意的，请给出您自己的反驳理由。
  • 如果评审意见比较多：
    • 请给出总体的修改情况。
    • 请采用start a review进行回复，而非直接回复的方式。原因是每个回复都会发送一封邮件，会造成邮件灾难。