- In general, we follow effective_go
- Code must adhere to the official Go formatting guidelines (i.e. uses goimports).
- Code must be documented adhering to the official Go commentary guidelines.
This github document provides some guidance on how to create a pull request in github.
To pursue engineering excellence, we have insisted on the highest stardard on the quality of each PR.
- For each PR, please run golint, goimports, to fix the basic issues/warnings.
- Make sure you understand How to Write a Git Commit Message.
- Add a [Test] section in every PR detailing on your test process and results. If the test log is too long, please include a link to gist and add the link to the PR.
The best practice is to reorder and squash your local commits before the PR submission to create an atomic and self-contained PR. This book chapter provides detailed explanation and guidance on how to rewrite the local git history.
For exampple, a typical workflow is like the following.
# assuming you are working on a fix of bug1, and use a local branch called "fixes_of_bug1".
git clone https://github.com/harmony-one/harmony
cd harmony
# create a local branch to keep track of the origin/master
git branch fixes_of_bug1 origin/master
git checkout fixes_of_bug_1
# make changes, build, test locally, commit changes locally
# don't forget to squash or rearrange your commits using "git rebase -i"
git rebase -i origin/master
# rebase your change on the top of the tree
git pull --rebase
# push your branch and create a PR
git push origin fixes_of_bug_1:pr_fixes_of_bug_1Please see our Fiduciary License Agreement. By your submission of your contribution to us, you and we mutually agree to the terms and conditions of the agreement.