Project: BFE (Orchestration & Management / Service Proxy)
File: submit_pr_guide.md

Create an Issue to describe your problem and keep its number. Switch to the branch you have created and click `New pull request`. Switch to targeted branch. A note of `resolve #Issue number` in PR description results in automatic close of corresponding Issue after the merge of PR. More details can be viewed . Then please wait for review. If there is any need to make a modification, you can update corresponding branch in origin following the steps above. Every new commit in your Pull Request will trigger CI unit tests, so please make sure that necessary comments have been included in your commit message. Please refer to Please note the procedure of CI unit tests in your Pull Request which will be finished in several hours. You only need to focus on CI projects associated with your submitted branch. For example, there is no need to check whether release/1.1 pass test or not if you submit code to develop branch. Green ticks after all tests means that your commit has passed all unit tests. Red cross after the tests means your commit hasn't passed certain unit test. Please click detail to view bug details and make a screenshot of bug, then add it as a comment in your Pull Request. Our stuff will help you check it. We can delete branches of remote repository in PR page after your PR is successfully merged into master repository. We can also delete the branch of remote repository with `git push origin :thebranchname`, such as: ```bash $ git push origin :my-cool-stuff ``` Finally,we delete local branch ```bash $ git checkout develop # switch to develop branch $ git branch -D

# delete my-cool-stuff branch ``` And now we finish a full process of code contribution In order that reviewers focus on code in the code review, please follow these rules every time you submit your code: 1Make sure that unit tests in Travis-CI pass through successfully.If it fails,it means problems have been found in submitted code which will not be reviewed by reviewer. 2Before the submit of PUll Request: Please note the number of commit: ReasonIt will bother reviewers a lot if a dozen of commits are submitted after modification of only one file and only a few modifications are updated in every commit. Reviewers have to check commit one by one to figure out the modification. And sometimes it needs to take the overlap among commits into consideration. SuggestionKeep commit concise as much as possible at every submit. You can make a supplyment to the previous commit with `git commit --amend`. About several commits having been pushed to remote repository, you can refer to Pay attention to the name of every commit: It would be better to abstract the content of present commit and be not too arbitrary. 3If you have tackled with problems of an Issue, please add `fix #issue_number` to the first comment area of PULL Request.Then the corresponding Issue will be closed automatically after the merge of PULL Request. Keywords are including:close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved. Please select appropriate word. Please refer to for more details. In addition, please follow the following regulations in response to the suggestion of reviewers: 1A reply to every comment of reviewersIt's a fundamental complimentary conduct in open source community.An expression of appreciation is a need for help from others): If you adopt the suggestion of reviewer and make a modification accordingly, it's courteous to reply with a simple `Done` . Please clarify your reason to the disagreenment 2If there are many suggestions Please show general modification Please follow to give your reply,instead of directly replying for that every comment will result in sending an email causing email disaster.