Kleros
Kleros.ioGithub
  • Introduction to Kleros
  • Kleros FAQ
  • Governance
  • PNK Token
  • They talk about Kleros
  • Products
    • Court
      • Kleros Juror Tutorial
      • Famous Kleros Cases
      • What happens during a dispute?
      • Kleros & Credible Neutrality
    • Court V2
    • Proof of Humanity
      • Proof of Humanity 2.0 Tutorial: (Register & Vouch)
      • Proof of Humanity 2.0 Tutorial (Remove & Challenge)
      • Proof of Humanity 2.0 Tutorial (Transferring a Profile)
      • Proof of Humanity 2.0 Integration Guide
      • Proof of Humanity FAQ
        • Proof of Humanity 2.0 launch FAQ
    • Curate
      • Kleros Curate Tutorial
      • Kleros Scout
        • Tutorial
        • Earn With Kleros Scout
        • Partnerships
        • Kleros Scout - Metamask Snaps
          • Knowledge Base
        • FAQs
    • Oracle
    • Governor
    • Escrow
      • Kleros Escrow Tutorial
      • Kleros Escrow Specifications
    • Linguo
      • Kleros Linguo Tutorial
      • Step-by-step Tutorial
        • Requesting translations
        • Working as a translator
        • Reviewing translations
      • F.A.Q
      • High-level Overview
    • Moderate
      • Susie
        • Getting Started
          • Add Susie
          • Start Susie
        • Basics
          • Welcome
          • Language
          • Notifications
        • Rules
        • Reports
        • Evidence
        • Federations
  • INTEGRATIONS
    • Overview
    • Industry use cases
    • Types of Integrations
      • 1. Dispute resolution integration plan
        • Smart contract integration with Kleros Court (Arbitrator)
        • Use Cases
          • DeFi Insurance
          • Gaming
          • Recognition of Jurisdiction Integration
            • Integración por Reconocimiento de Jurisdicción
        • Channel partners
          • How to use Reality.eth + Kleros as an oracle
          • Safe Zodiac integration
          • Kleros Reality Module
        • Integration Tools
          • Centralized Arbitrator
          • Dispute Resolver
      • 2. Curated-data integration plan
        • Retrieving information from Kleros Dapps
    • Policy writing guide
    • Live & Upcoming Integrations
    • Kleros Analytics
    • Scalability & Cross-chain
      • Using Kleros arbitration for Dapps on xDai/Gnosis
    • Integrations FAQ
  • Developers
    • Arbitration Development
      • ERC-792: Arbitration Standard
      • ERC 1497: Evidence Standard
      • Arbitrable Proxy
    • Arbitration by Example
      • ArbitrableDeposit.sol
      • TwoPartyArbitrable.sol
      • Rental.sol
      • ArbitrableTransaction.sol
      • MultipleArbitrableTransaction.sol
      • MultipleArbitrableTokenTransaction.sol
    • Deployment Addresses
    • Curate Classic: Integration for Devs
    • Light Curate: Integration for Devs
    • Guide for Preparing Transactions
  • Contribution Guidelines
    • Overview
    • General Dev. Workflow
      • Task Tracking & Lifecycle
      • Releases
    • Smart Contract Workflow
      • Task Tracking & Lifecycle
      • RAB - Review, Audit, Bounty
      • RABd (+ Deploy)
      • Reporting Vulnerabilities
    • Code Style and Guidelines
      • Git
      • Solidity
      • Web Languages
    • License & Code of Conduct
      • License
      • Code of Conduct
  • Additional Resources
    • Discord
    • Telegram
    • Governance Forum
    • Twitter
    • Blog
    • Reddit
    • Github
    • Slack
Powered by GitBook
On this page
  • Branches
  • Commits
  • When to Commit
  • Messages
  • Merging
  • Misc. Tips

Was this helpful?

Edit on GitHub
  1. Contribution Guidelines
  2. Code Style and Guidelines

Git

Controlling version control.

PreviousCode Style and GuidelinesNextSolidity

Last updated 3 years ago

Was this helpful?

We use Git for version control and use for branch names and commit messages to enforce consistency and enjoy automatic changelog generation.

Branches

Use short and descriptive, kebab-cased names with a conventional commits type prefix separated by a slash, like so:

  • feat/implement-arbitrator

  • fix/invalid-rulings-from-arbitrator

When several people are working on a branch, you may create personal branches that can be merged before merging the main branch to develop. For example:

  • feat/implement-arbitrator/alice

  • feat/implement-arbitrator/bob

Always delete merged branches, locally and remotely. You can use the following command to list them, git branch --merged | grep -v "\*".

Commits

It's important for commits to follow a standard to allow efficient navigation of change history in the case of regressions and to make reviewers' lives easier.

When to Commit

As a general guideline, each commit should be a single logical change. Don't make several logical changes in one commit. For example, if a commit fixes a bug and optimizes the performance of a feature, split it. Here are some useful tips:

  • Use git add -p to interactively stage specific portions of modified files.

  • Commit early and often. Small, self-contained commits are easier to understand and revert when something goes wrong.

  • Order commits logically.

When working locally, it's OK if your branch history is not perfect, but that should be cleaned up before pushing upstream.

Messages

Note that all the words in a commit message are in present tense except for the first word in the footer, e.g. Closes, Fixes, etc.

Merging

Branches that are used by CI/CD processes, like develop and master should never have their history rewritten.

Before merging:

Always alert other people who are working on a branch when you are about to rewrite its history.

Misc. Tips

Test before you push. Do not push half-done work.

Use lightweight tags to bookmark commits for future reference.

Keep repos in good shape by performing maintenance tasks from time to time:

  • git-gc

  • git-prune

  • git-fsck

Follow . If the repo uses , you can just run yarn run cz and follow the prompts to craft a valid message.

Conventional Commits
Conventional Commits
Kathari