Skip to content

Latest commit

 

History

History
219 lines (146 loc) · 8.68 KB

contribute.md

File metadata and controls

219 lines (146 loc) · 8.68 KB
Raw

How to contribute

You are welcome to contribute to project PaddleGAN. Contributions can be:

  • documentation
  • source code and bug fixes
  • new features or models
  • solve existing issues

We sincerely appreciate your contribution. This document explains our workflow and work style.

The following guidiance tells you how to submit code.

Workflow

  1. Fork

    Transfer to the home page of Github PaddleGAN, and then click button Fork to generate the git under your own file directory, such as https://github.com/USERNAME/PaddleGAN.

  2. Clone

    Clone remote git to local:

    ➜  git clone https://github.com/USERNAME/PaddleGAN
➜  cd PaddleGAN

  3. Create local branch

    At present Git stream branch model is applied to PaddleGAN to undergo task of development, test, release and maintenance. All development tasks of feature and bug fix should be finished in a new branch which is extended from master branch.

    Create and switch to a new branch with command git checkout -b.

    ➜  git checkout -b my-cool-stuff

    It is worth noting that before the checkout, you need to keep the current branch directory clean, otherwise the untracked file will be brought to the new branch, which can be viewed by git status .

  4. Use pre-commit hook

    We use the pre-commit tool to manage Git pre-commit hooks. It helps us format the source code (C++, Python) and automatically check some basic things before committing (such as having only one EOL per file, not adding large files in Git, etc.).

    The pre-commit test is part of the unit test in Travis-CI. A PR that does not satisfy the hook cannot be submitted to Paddle. Install pre-commit first and then run it in current directory：

    ➜  pip install pre-commit
➜  pre-commit install

    Once installed, pre-commit checks the style of code and documentation in every commit. We will see something like the following when you run git commit:

    ➜  git commit
CRLF end-lines remover...............................(no files to check)Skipped
yapf.................................................(no files to check)Skipped
Check for added large files..............................................Passed
Check for merge conflicts................................................Passed
Check for broken symlinks................................................Passed
Detect Private Key...................................(no files to check)Skipped
Fix End of Files.....................................(no files to check)Skipped
clang-formater.......................................(no files to check)Skipped
[my-cool-stuff c703c041] add test file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 233

    NOTE: The yapf installed by pip install pre-commit and conda install -c conda-forge pre-commit is slightly different. We use pip install pre-commit.

  5. Start development

    I delete a line of README.md and create a new file in the case.

    View the current state via git status, which will prompt some changes to the current directory, and you can also view the file's specific changes via git diff.

    ➜  git status
On branch test
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified:   README.md
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    test
no changes added to commit (use "git add" and/or "git commit -a")

  6. Test

    Add unit testing if needed.

  7. Commit

    Next we cancel the modification of README.md, and submit new added test file.

    ➜  git checkout -- README.md
➜  git status
On branch test
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    test
nothing added to commit but untracked files present (use "git add" to track)
➜  git add test

    It's required that the commit message is also given on every Git commit, through which other developers will be notified of what changes have been made. Type git commit to realize it.

    ➜  git commit
CRLF end-lines remover...............................(no files to check)Skipped
yapf.................................................(no files to check)Skipped
Check for added large files..............................................Passed
Check for merge conflicts................................................Passed
Check for broken symlinks................................................Passed
Detect Private Key...................................(no files to check)Skipped
Fix End of Files.....................................(no files to check)Skipped
clang-formater.......................................(no files to check)Skipped
[my-cool-stuff c703c041] add test file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 233

  8. Keep pulling

    An experienced Git user pulls from the official repo often -- daily or even hourly, so they notice conflicts with others work early, and it's easier to resolve smaller conflicts.

    Check the name of current remote repository with git remote.

    ➜  git remote
origin
➜  git remote -v
origin    https://github.com/USERNAME/PaddleGAN (fetch)
origin    https://github.com/USERNAME/PaddleGAN (push)

    origin is the name of remote repository that we clone, we create a remote host of an original PaddleGAN and name it upstream.

    ➜  git remote add upstream https://github.com/PaddlePaddle/PaddleGAN
➜  git remote
origin
upstream

    Get the latest code of upstream and update current branch.

    ➜  git fetch upstream
➜  git pull upstream develop

  9. Push to remote repository

    Push local modification to GitHub (https://github.com/USERNAME/PaddleGAN).

    # submit it to remote git the branch my-cool-stuff of origin
➜  git push origin my-cool-stuff

    The push allows you to create a pull request, requesting owners of this official repo to pull your change into the official one.

    To create a pull request, please follow these steps.

    If your change is for fixing an issue, please write "Fixes " in the description section of your pull request. Github would close the issue when the owners merge your pull request.

    Please remember to specify some reviewers for your pull request. If you don't know who are the right ones, please follow Github's recommendation.

  10. Delete local and remote branches

    To keep your local workspace and your fork clean, you might want to remove merged branches:

    git push origin :my-cool-stuff
git checkout develop
git pull upstream develop
git branch -d my-cool-stuff

Code Review

  • Please feel free to ping your reviewers by sending them the URL of your pull request via IM or email. Please do this after your pull request passes the CI.

  • Please answer reviewers' every comment. If you are to follow the comment, please write "Done"; please give a reason otherwise.

  • If you don't want your reviewers to get overwhelmed by email notifications, you might reply their comments by in a batch.

  • Reduce the unnecessary commits. Some developers commit often. It is recommended to append a sequence of small changes into one commit by running git commit --amend instead of git commit.

Coding Standard

Code Style

Our C/C++ code follows the Google style guide.

Our Python code follows the PEP8 style guide.

Please install pre-commit, which automatically reformat the changes to C/C++ and Python code whenever we run git commit.

Unit Tests

Please remember to add related unit tests.