Index Coop Community Handbook
Search…
Welcome to the Index Coop!
Our Guiding Principles
New Owl Quest
Meeting Calendar - Join us!
Essential Resources
Products
DeFi Pulse Index (DPI)
Metaverse Index (MVI)
Flexible Leverage Indices (FLI)
Market Neutral Yield Tokens
Bankless BED Index (BED)
Data Economy Index (DATA)
Bankless DeFi Innovation Index (GMI)
JPG NFT Index (JPG)
Interest Compounding ETH Index (icETH)
Product Launch Process
Governance
$INDEX - Governance Token
Index Improvement Proposals (IIP) Overview
Meta-Governance
Delegation
Community
Working Groups 101
Treasury Basics
POAP
Resources
Engineering
About Us
Getting Started
Smart Contract and Solidity Basics
Setting Up Your Blockchain Developing Environment
Writing Smart Contracts
Deploying Smart Contracts
Github Best Practices
Contract Addresses
RAPID Decision Making
Press Kit
Index Coop Glossary
Archived
Powered By GitBook
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.
​
Previous
Deploying Smart Contracts
Next
Contract Addresses
Last modified 7mo ago
Copy link
Contents
Squashing Commits
Rebasing Commits
Naming Branches
Large Feature Branches