Index Coop Docs
Comment on page

Github Best Practices

An ongoing list of Github best practices for Index Coop repos

Squashing Commits

All pull requests to Index Coop repos should be squashed upon merging into master. This helps keep our commit history clean & readable. This is handled by the PR reviewer, and not the implementor.

Rebasing Commits

As per the above, we do not use merge commits anywhere in Index Coop repos. Rebasing commits helps keep our commit history clean & readable. Before making a PR, make sure your local branch has been rebased off of the latest on master.
You can do this by running: git pull --rebase origin master
If any other PRs are merged while your PR is under review, you will likely be asked to rebase your branch on master and push again.
To do this, run the above command: git pull --rebase origin master And force push your branch git push my-fork my-branch-name --force

Naming Branches

In general branches are named <contributor-name>/<feature-name> Examples: modene/wei-refactor or dylan/otc-deployment

Large Feature Branches

Any large feature work should be split into multiple PRs. Any work that requires more than 1 PR for completion should be done against master-feature branches. The master-feature branch should be maintained/kept up-to-date with master by the owner or lead for that feature. All feature related PRs should be made into the master feature branch.
This model accomplishes a couple things:
  1. 1.
    Work-in-progress code does not enter master. Only once a feature is fully completed does it get merged into master
  2. 2.
    Breaking up large feature work into smaller PRs makes the lives of reviewers easier. PRs diffs remain small and focused. Turn around time is faster for implementors.
  3. 3.
    The responsibility of keeping the master-feature branch up-to-date with the latest master commit is clearly defined & separated from the feature work being done.
As an example, if EWG wants to launch Uniswap V3 staking we would:
  1. 1.
    Cut a branch from master, named uniswap-v3-master
  2. 2.
    Feature work is spread out across multiple PRs against uniswap-v3-master
  3. 3.
    The feature owner (@modene) is responsible for keeping the uniswap-v3-master branch up-to-date.
  4. 4.
    The feature owner and pull request reviewer (@modene) ensures any merges into uniswap-v3-master are rebased off uniswap-v3-master & squashed upon merge.
  5. 5.
    uniswap-v3-master can be deployed to staging mainnet for testing.
  6. 6.
    Once uniswap-v3-master is production ready, it is merged into master and deployed.