Skip to content
This repository has been archived by the owner on Feb 1, 2019. It is now read-only.

Contributing guidelines

James Ray edited this page May 29, 2018 · 20 revisions

Contributor License Agreement

By contributing to this repository, you are giving permission for your contributions to have the same copyright license used by the repository, which is the Unlicense since the creation of the repo. Please state in your first commit that you agree to this CLA.

Learn to use Git proficiently

Install dependencies

Aim for test-driven development and/or 100% test coverage

https://doc.rust-lang.org/stable/book/second-edition/ch12-04-testing-the-librarys-functionality.html

Includes unit tests and integration test. Write a test, make it fail, then write some code to get it to pass, then iterate.

Aim for 100% documentation coverage of every public module, trait, struct, enum, function, method, macro, and type definition

Clone a fork of the repository

  • Fork the repository https://github.com/Drops-of-Diamond/diamond_drops

  • Clone your fork of the repository (replace below with your Github username):

    git clone https://github.com/<USERNAME>/diamond_drops;
    cd diamond_drops
  • Add the "upstream" repository to your remotes and show your list of remotes verbosely

    git remote add upstream https://github.com/Drops-of-Diamond/diamond_drops;
    git remote --verbose
  • Change from the "master" branch to the "develop" branch to see the latest features that are being integrated but are not officially ready for production. The develop branch is the default branch, there is no need to checkout to it.

Run and Test the code

  • Build and run the code and provide arguments that it accepts from the CLI

    cargo run -- -mode b
    • Note: CLI Options available may include:
      • Proposer Mode: cargo run -- -mode p
      • Collator Mode: cargo run -- -mode c
      • Both Proposer and Collator Mode: cargo run -- -mode b
  • Run tests

    cargo test

Contribute changes to an existing remote branch by others

  • Change to the "develop" branch from "master". The develop branch is the default branch, when you cd to the folder, the branch will be the default branch.

    git checkout develop
  • Fetch latest changes from all "upstream" repos. Reference: https://stackoverflow.com/a/21189710/3208553

    for b in `git branch -r | grep -v -- '->'`; do git branch --track ${b##origin/} $b; done && git fetch --all && git pull --all
  • Fetch the latest changes from an "upstream" branch that is in progress. Let's assume the remote branch is called 'upstream/basic_cli', and map it to your local machine. This is an outdated example, the basic_cli branch has since been merged into develop.

    git fetch upstream basic_cli:basic_cli
  • Show branches that now include the branch called 'basic_cli' locally

    git branch
  • Change to the basic_cli branch

    git checkout basic_cli
  • Make changes to the basic_cli branch

  • Prior to pushing changes update the local 'develop' branch and the 'basic_cli' branch with the latest changes from upstream develop

    • Change to the 'develop' branch and fetch the latest changes from upstream using rebase

      git checkout develop
    • Fetch the latest changes from 'develop' branch

      git pull --rebase upstream develop
    • Switch back into the 'basic_cli' branch and rebase it interactively with the latest changes from the 'develop' branch

      git checkout basic_cli;
      git rebase -i develop
      • Important Note: If you prefer not to use Git Rebase then use Git Merge (i.e. git merge develop instead or a similar equivalent.
  • Push the changes that you made to a remote branch called 'basic_cli' on "origin", which is your fork of the "upstream".

    git push origin basic_cli
  • Create a Pull Request from your remote branch of the "origin" fork into the 'basic_cli' branch of the "upstream" for another user to accept your proposed changes

Contribute new changes in a new branch that you author

  • Change to your local 'develop' branch (integration branch for features). If it does not yet exist then create it with git checkout -b develop

    git checkout develop
  • Fetch latest changes from the "upstream" repository that is in progress

    git fetch upstream
  • Create a new branch for your feature or bug fix

    git checkout -b <INSERT_YOUR_BRANCH_NAME>
  • Make changes to your branch

  • Add and commit changes. Use this Git Styleguide for your messages

    git add .;
    git commit -m "<INSERT_YOUR_MESSAGE>"
  • Prior to pushing changes update the local 'develop' branch and your current branch with the latest changes from upstream 'develop' branch

    • Change to 'develop' branch and fetch the latest changes from upstream using rebase

      git checkout develop
    • Fetch the latest changes from the remote develop branch

      git pull --rebase upstream develop
    • Switch back into your branch and rebase it interactively with the latest changes from the 'develop' branch

      git checkout basic_cli;
      git rebase -i master
      • Important Note: If you prefer not to use Git Rebase then use Git Merge instead or a similar equivalent
  • Push the changes that you made to a remote branch on "origin" with a name matching the branch you created, where "origin" is your fork of the "upstream" repository

    git push origin <INSERT_YOUR_BRANCH_NAME>
  • Create a Pull Request from your remote branch of the "origin" fork into the 'develop' branch of the "upstream" for another user to accept your proposed changes

Review or contribute changes to a Pull Request in the upstream repo

git fetch upstream pull/ID/head:BRANCHNAME
git checkout BRANCHNAME

See for details: https://help.github.com/articles/checking-out-pull-requests-locally/

If you need to change your local branch to be the same as a remote (e.g. origin or upstream) branch

See https://stackoverflow.com/a/1628334/7438857.

Specifically, for resetting local origin develop to remote upstream develop and then resetting remote origin develop, see here.

Merging changes from another branch, e.g. develop, while if there are any conflicts, favouring changes from that branch

git merge -s recursive -X theirs develop Use git merge -s recursive -X ours develop to preserve any conflicting changes in the checked out branch.