Thanks for your interest in contributing to OpenDevin! We welcome and appreciate contributions. To report bugs, create a GitHub issue.
Fork OpenDevin repository into your own account. Clone your own forked repository into your local environment.
git clone git@github.com:<YOUR-USERNAME>/OpenDevin.git
Set the official repository as your upstream to synchronize with the latest update in the official repository. Add the original repository as upstream
cd OpenDevin
git remote add upstream git@github.com:OpenDevin/OpenDevin.git
Verify that the remote is set.
git remote -v
You should see both origin
and upstream
in the output.
Synchronize latest commit with offical repository before coding.
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
After you finish implementation, open forked repository. The source branch is your new branch, and the target branch is OpenDevin/OpenDevin
main
branch. Then PR should appears in OpenDevin PRs.
Then OpenDevin team will review your code.
As described in here, a valid PR title should begin with one of the following prefixes:
feat
: A new featurefix
: A bug fixdoc
: Documentation only changesrefactor
: A code change that neither fixes a bug nor adds a featurestyle
: A refactoring that improves code styleperf
: A code change that improves performancetest
: Adding missing tests or correcting existing testsci
: Changes to CI configuration files and scripts (example scopes:.github
,ci
(Buildkite))chore
: Other changes that don't modify src or test filesrevert
: Reverts a previous commit
For example, a PR title could be:
refactor: modify package path
feat(frontend): xxxx
, where(frontend)
means that this PR mainly focuses on the frontend component.
You may also check out previous PRs in the PR list.
As described in here, we create several labels. Every PR should better tag with corresponding labels.
- If your PR is small (such as a typo fix), you can go brief.
- If it is large and you have changed a lot, it's better to write more details.
Please check the details in each parts: frontend, agenthub, evaluation, server.
TODO: make sure code pass the test before submit.