Your first commit: Creating a pull request

May 19, 2026 · View on GitHub

Your first pull request

At this point you've experienced the basic dev flow for the rad CLI.

It's time to pick an issue to work on! You can find a query here.

If you find an issue you want to help with, then please comment on that issue and ask for one of the maintainers to assign it to you. If you have questions or anything you want to discuss, use the issue to communicate about it.

Now you've got something to work on. Once you've developed and tested your change resume this guide.

One last check

Before proceeding, make sure your changes pass all the unit tests as well as golint.

make build lint test

It is best if you can resolve problems identified here before submitting.

Writing a good commit message

To make it easier for us to track history, write a good commit message.

The format preferred for the project is formatted like:

<a one line summary of the fix or change>

Fixes: #<issue number>

<a more detailed description of the root cause and fix - may be long if necessary>

Signed-off-by: Random J Developer <random@developer.example.org>

Here's an example.

Include a level of detail that makes sense based on the complexity of problem and solution.

Radius leverages the Developer Certificate of Origin to certify that you have the right to submit the code you are contributing to the project. Make sure to include the Signed-off-by line in your commit message, or use the -s flag when committing.

Visual Studio Code has a setting, git.alwaysSignOff to automatically add a Signed-off-by line to commit messages. Search for "sign-off" in VS Code settings to find it and enable it.

Signing your commits

💡 Commit signing is separate from the DCO Signed-off-by line described above. The Signed-off-by line is a textual attestation, while commit signing proves that the commit was signed with the private key corresponding to your configured public key. Both are recommended.

We require all contributors to cryptographically sign their commits so that they show as Verified on GitHub. On GitHub, Verified means GitHub could validate the signature and that the signing key is associated with the account. This gives reviewers and the community additional confidence in the integrity and provenance of commits, which is an important supply-chain safeguard.

GitHub supports three types of commit signatures: GPG, SSH, and S/MIME. Pick whichever is easiest for you — SSH signing is usually the simplest if you already use an SSH key with GitHub.

Follow the official GitHub documentation to set this up:

Once configured, you can have Git sign every commit automatically by setting:

git config --global commit.gpgsign true

(Use the same setting for SSH or S/MIME signing — Git will use whichever signing format you have configured.)

After pushing, your commits should display a Verified badge next to them on GitHub.

Creating the pull request

Please ensure you are contributing from a fork of the repository. If you have not set this up, please refer to the forking guide.

Push your changes to your forked repo and then open a pull request.

If you formatted your commit message correctly then everything should be good to go.

Go ahead and create your PR.

The PR process

At this point you should review the PR checks and make sure they pass. Failing PR checks will prevent your change from being merged.

If you have any failing checks try to investigate the details and solve them if possible. If you get stuck and need to know the reason for failure, ask a maintainer.

At this point one or more core team members will review your code changes.

Reviewers will leave their feedback via comments. Discuss as needed and resolve the feedback when both you and the reviewers are happy.

Once you've resolved all the feedback, your reviewers will make the pull request as approved.

From this point on you don't need to do anything. The maintainers will merge your pull request.