Github Best Practices
An ongoing list of Github best practices for Index Coop repos
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.
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 masterIf 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 --forceIn general branches are named
<contributor-name>/<feature-name>
Examples: modene/wei-refactor or dylan/otc-deploymentAny 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.Work-in-progress code does not enter master. Only once a feature is fully completed does it get merged into master
- 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.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.Cut a branch from master, named
uniswap-v3-master - 2.Feature work is spread out across multiple PRs against
uniswap-v3-master - 3.The feature owner (@modene) is responsible for keeping the
uniswap-v3-masterbranch up-to-date. - 4.The feature owner and pull request reviewer (@modene) ensures any merges into
uniswap-v3-masterare rebased offuniswap-v3-master& squashed upon merge. - 5.
uniswap-v3-mastercan be deployed to staging mainnet for testing. - 6.Once
uniswap-v3-masteris production ready, it is merged into master and deployed.
Last modified 1yr ago