A pull request (PR) is the mechanism used to propose changes to the content of this project's repository.
If you are looking for ideas of what to work on, check the list of open issue reports. Pull requests addressing any of those bug reports and feature requests are welcome.
Each contribution travels through a formal process which allows it to be efficiently incorporated into the project.
Start by searching the repository for existing pull requests and issues related to your planned contribution so you can see any related conversations and proposals and avoid duplicate effort:
https://github.com/arduino/arduino-ide/issues?q=
It can sometimes be useful to get feedback from others during the planning process. There are a couple good options for discussing planned development work:
- Talk with the user community on the Arduino Forum.
- Talk with Arduino developers on the Arduino Developers Mailing List.
Forking a GitHub repository creates a copy of it under your account. You will stage contributions in your fork of this project.
More information about forking repositories
The repository is configured to run automated continuous integration (CI) checks and tests. It's a good idea to enable CI in your fork so you can make sure your work will pass the checks before you submit a pull request:
- Open the homepage of your fork in the browser.
- Click the "Actions" tab.
- Click the I understand my workflows, go ahead and enable them button.
- Some of the workflows will now need to be activated individually. Perform the following steps for each of the useful workflows listed on the left side of the page that have a "!" icon:
- Click on the workflow name.
- Click the Enable workflow button.
Cloning a repository creates a copy of it on your computer.
It is possible to make simple changes to your repository using the GitHub web interface without cloning the repository. However, the GitHub web interface is quite limiting so you will likely find the need to work with a clone (using Git directly or your choice of Git client software) for any significant development work.
More information about cloning repositories
Create a branch in your fork to contain the changes for your contribution. You must make a separate branch in your fork for each pull request you submit.
More information about branches
Some things to keep in mind:
- Make sure your change complies with the project's established style conventions.
- Remember to also update the documentation content in the repository if required by your changes.
- If the project contains a test suite, update or add tests according to your change as appropriate.
See the development guide for more information.
Test your change carefully to make sure it works correctly and did not break other components of the project.
As a supplement for general testing, the project is set up with automated checks and tests to facilitate development.
See the development guide for instructions.
Once the work on your change is complete, add it to the revision history of the Git repository by making a commit.
Make sure to follow the Commit Guidelines.
More information about commits
If you're working from a clone, you will need to push your commit to your fork on GitHub.
More information about pushing commits
If you have enabled CI in your repository, GitHub will run the relevant checks automatically every time you push a commit to your fork.
You can see the results of these checks by doing either of the following:
- Clicking the status icon (✔️ or ❌) shown to the right of a commit.
- Opening the repository's "Actions" tab.
A pull request (PR) is a proposal to make a change in a repository. The repository maintainer is able to accept the changes you propose in a pull request by simply clicking a button.
More information about pull requests
Each pull request should address a single bug fix or enhancement. If you have multiple unrelated fixes or enhancements to contribute, submit them as separate pull requests.
Pull request title and description should follow the same guidelines as commit messages.
If your pull request fixes an issue in the issue tracker, use a closing keyword in the body to indicate this.
In some cases, it might make sense to request feedback on a proposal before it is ready to be merged. You can indicate this by starting the pull request title with [WIP] (work in progress). Once the pull request is ready to be merged, edit the title and remove the "[WIP]".
Some proposals may require changes to multiple repositories. Pull requests should be submitted in parallel to each repository.
Clearly note any dependencies on other PRs in the description so that these can be evaluated by the reviewer and the merges coordinated.
Please check whether any changes are required to the related documentation content hosted in the separate dedicated repositories:
Relevant checks will run automatically once you have submitted the pull request. Once these checks are finished, you can see a summary of the results near the bottom of the pull request page:
Failed checks will be indicated with an ❌. If any checks failed, please fix whatever caused it to fail. Click the "Details" link to the right of the check name to open the logs, which provide details about the failure.
ⓘ In some rare cases, a CI failure may be unrelated to the changes made in your pull request. So if the information in the logs doesn't seem relevant, please comment on the pull request to ask a maintainer to take a look.
When you push to the branch of your fork the pull request was submitted from, the commit is automatically added to the pull request. Don't create a new pull request to fix problems; update the existing pull request.
Interested parties may review your pull request and suggest improvements.
To act on general review suggestions, you can add commits to the branch you submitted the pull request from, which will automatically be added to the pull request. Don't create a new pull request to act on review suggestions; update the existing pull request.
Reviewers may suggest specific changes, which can be applied by clicking the Commit suggestion button.
More information about pull request reviews
One of the repository maintainers can now choose to accept your proposed change. Once the pull request is merged, you can delete the branch you created in your fork for the pull request and delete the fork as well if you like.
Thanks so much for your contribution!
It is possible that the maintainers may decide a pull request doesn't align with Arduino's goals for the project and close it rather than merging. A record of the proposed changes will always be available on GitHub for future reference. If you think your modifications will be of use to others, you are welcome to maintain your own fork of the repository.
The commit history of a repository is an important resource for developers. Repositories may accumulate thousands of commits over the course of decades. Each individual commit contributes either to the commit history being pleasant and efficient to work with, or to it being a confusing mess. For this reason, it's essential for contributors to create clean, high quality commits.
Commits must be "atomic". This means that the commit completely accomplishes a single task. Each commit should result in fully functional code. Multiple tasks should not be combined in a single commit, but a single task should not be split over multiple commits (e.g., one commit per file modified is not a good practice).
More information about atomic commits
The commit message documents what the change was and why it was done. A little effort now writing a good commit message can save future developers from wasted time and frustration trying to understand the purpose of a poorly documented commit.
- Use the imperative mood in the title.
For example:Use LED_BUILTIN macro in LED pin definition
- Capitalize the title.
- Do not end the title with punctuation.
- Do not use GitHub's default commit titles (e.g., "Update examples/Foo/Foo.ino").
- Separate title from the body with a blank line. If you're committing via GitHub or GitHub Desktop this will be done automatically.
- Wrap body at 120 characters.
- Completely explain the purpose of the commit.
Include a rationale for the change, any caveats, side-effects, etc.