- Visit https://github.com/mailchain/mailchain
- Click
Forkbutton (top right) to establish a cloud-based fork.
Mailchain uses Go version 1.13 with module support, meaning it can be cloned into your folder of preference.
mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/mailchain.git
# or: git clone git@github.com:$user/mailchain.git
cd $working_dir/mailchain
git remote add upstream https://github.com/mailchain/mailchain.git
# or: git remote add upstream git@github.com:mailchain/mailchain.git
# Never push to upstream master
git remote set-url --push upstream no_push
# Confirm that your remotes make sense:
git remote -vGet your local master up to date:
cd $working_dir/mailchain
git fetch upstream
git checkout master
git rebase upstream/masterBranch from it:
git checkout -b myfeatureThen edit code on the myfeature branch.
# While on your myfeature branch
git fetch upstream
git rebase upstream/masterPlease don't use git pull instead of the above fetch / rebase. git pull does a merge, which leaves merge commits. These make the commit history messy and violate the principle that commits ought to be individually understandable and useful (see below).
You can also consider changing your .git/config file via git config branch.autoSetupRebase always to change the behavior of git pull.
Commit your changes.
git commitLikely you go back and edit/build/test some more then commit --amend
in a few cycles.
When ready to review (or just to establish an offsite backup of your work),
push your branch to your fork on github.com:
git push -f ${your_remote_name} myfeature- Visit your fork at
https://github.com/$user/mailchain - Click the
Compare & Pull Requestbutton next to yourmyfeaturebranch. - Open the pull request.
Once your pull request has been opened it will be assigned to one or more reviewers. Those reviewers will do a thorough code review, looking for correctness, bugs, opportunities for improvement, documentation and comments, and style.
Commit changes made in response to review comments to the same branch on your fork.
Very small PRs are easy to review. Very large PRs are very difficult to review.
Upon merge (by either you or your reviewer), all commits left on the review branch should represent meaningful milestones or units of work. Use commits to add clarity to the development and review process.
Before merging a PR, squash any fix review feedback, typo, merged, and rebased sorts of commits.
It is not imperative that every commit in a PR compile and pass tests independently, but it is worth striving for.
In particular, if you happened to have used git merge and have merge commits, please squash those away: they do not meet the above standard.
A nifty way to manage the commits in your PR is to do an interactive rebase, which will let you tell git what to do with every commit:
git fetch upstream
git rebase -i upstream/masterFor mass automated fixups (e.g. automated doc formatting), use one or more commits for the changes to tooling and a final commit to apply the fixup en masse. This makes reviews easier.
In case you wish to revert a commit, use the following instructions.
-
Create a branch and sync it with upstream.
# create a branch git checkout -b myrevert # sync the branch with upstream git fetch upstream git rebase upstream/master
-
If the commit you wish to revert is a:
-
merge commit:
# SHA is the hash of the merge commit you wish to revert git revert -m 1 SHA -
single commit:
# SHA is the hash of the single commit you wish to revert git revert SHA
-
-
This will create a new commit reverting the changes. Push this new commit to your remote.
git push ${your_remote_name} myrevertCreate a Pull Request using this branch.