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:
Visit the pgAdmin 4 project on GitHub, and click the Fork button to create your own development repository in your GitHub account.
Checkout a local copy of the source code with a command like:
$ git clone https://github.com/<your GitHub username>/pgadmin4.git
Develop and test your change in your local development environment.
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.
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.
Push your changes to your fork of the repository.
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.
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.