Fork me on GitHub

Quick Links


Download


FAQ


Latest Docs


Get Help


Screenshots

This page in other versions: Latest (8.14) | 8.13 | 8.12 | 7.8 | 6.21 | Development

Navigation

Warning: This documentation is for a pre-release version of pgAdmin 4

Contents

Submitting Pull Requests

Before developing a feature or bug fix for pgAdmin you should always contact the developers on the mailing list pgadmin-hackers@postgresql.org to discuss your plans. This ensures that others know what you are doing and can then avoid duplicating your work, and in the case of large changes, gives the community the chance to discuss and refine your ideas before investing too much time writing code that may later be rejected.

You should always develop changes against a checkout of the source code from the GIT source code repository, and not a release tarball. This ensures that you’re working with the latest code on the branch and makes it easier to generate Pull Requests correctly.

As of September 2022, the pgAdmin source repository can found at https://github.com/pgadmin-org/pgadmin4. A typical workflow for a relatively simple change might look as follows:

  1. Visit the pgAdmin 4 project on GitHub, and click the Fork button to create your own development repository in your GitHub account.

  2. Checkout a local copy of the source code with a command like:

$ git clone https://github.com/<your GitHub username>/pgadmin4.git

  1. Develop and test your change in your local development environment.

  2. Review your changes and check them thoroughly to ensure they meet the pgAdmin Coding Standards, and review them against the Code Review Notes to minimise the chances of them being rejected.

  3. Once you’re happy with your change, commit it with a suitable message. Include a one-line summary at the top, and if appropriate, further paragraphs following a blank line after the summary.

  4. Push your changes to your fork of the repository.

  5. Back in GitHub, create a new Pull Request against the pgadmin-org/pgadmin4 master branch.

    Note

    Each Pull Request should encompass a single bug fix or feature as a single commit. If necessary, you should squash multiple commits for larger changes or features into a single commit before submitting.

  6. Your Pull Request will be reviewed by one or more members of the development team and either accepted or sent back with requested changes. In some cases it may be rejected if the change is not considered appropriate - this is why it’s important to discuss your work with the team before spending any significant time on it.

For more complex changes, you may wish to use a Feature Branch in your fork of the pgAdmin repository, and use that to create the Pull Request.

Note

This is a simple example of a workflow. You may choose to use other tools such as the GitHub CLI instead; documenting such tools and workflows is outside the scope of the pgAdmin documentation however.