...
- Fork the repository. Make sure you also add an upstream to be able to update your fork.
- Clone your fork to your computer.
- Create a topic branch and name it appropriately. Starting the branch name with the issue number is a good practice and a reminder to fix only one issue in a Pull-Request (PR).
- Make your changes adhering to the coding conventions described below. In general a commit serves a single purpose and diffs should be easily comprehensible. For this reason do not mix any formatting fixes or code moves with actual code changes.
- Commit your changes see How to Write a Git Commit Message article by Chris Beams.
- Make sure to add DCO message to each commit (for example in the command line: git commit -s -m "..."), more information here
- Test your changes locally before pushing to ensure that what you are proposing is not breaking another part of the software. Running the
./gradlew clean check test
command locally will help you to be confident that your changes will pass CI tests once pushed as a Pull Request. - Push your changes to your remote fork (usually labeled as
origin
). - Create a pull-request (PR) on the Besu repository. If it's not ready to review, make it a `Draft` PR. If the PR addresses an existing issue, include the issue number in the PR title in square brackets (for example,
[#2374]
). - Add labels to identify the type of your PR. For example, if your PR fixes a bug, add the "bug" label.
- If the PR address an existing issue, comment in the issue with the PR number.
- Ensure your changes are reviewed. Let us know using Besu chat channels that your PR is ready for review. If you are a maintainer, you can choose reviewers, otherwise this will be done by one of the maintainers.
- Make any required changes on your contribution from the reviewers feedback. Make the changes, commit to your branch, and push to your remote fork.
- When your PR is approved, validated, all tests pass and your branch has no conflicts, it can be merged. Again, this action needs to be done by a maintainer - usually the same person who approves will also merge it.
...