Introduction

The instructions for updating the PTS9 repository are very similar to those for the SKIRT9 repository, but many of the steps are not applicable.

The PTS9 repository follows the GitHub fork and pull workflow model. This means you should never push any changes directly to the PTS9 repository. Instead, contributors including administrators should push suggested changes to a topic branch (not the master branch) in their own fork and create a pull request, which is then handled by an administrator as described on this page below. For more information, see The GitHub workflow for the SKIRT project.

As an administrator, your local copy of the PTS code must be connected to both the main PTS9 repository and your own fork of this repository. For more information, see SKIRT project directory structure.

The GitHub Desktop application provides a nice graphical user interface on top of git. It facilitates many git workflow operations and is easy to learn. Moreover, GitHub Desktop operations can be mixed with raw git commands in a terminal at will. For more information, see Software tools for the administrator.

Handling a pull request

Handling a pull request for the PTS9 repository, created by yourself or by another user, involves the steps listed below.

Pull a copy of the pull request to your local computer (instructions can be found on the GitHub page for the pull request). This step is not applicable if you created the pull request.
Verify that the code conforms to the PTS coding style. If not, fix the issues or ask the pull request author to do so. In the latter case, pull the changes to your local copy before proceeding.
Verify that the code is properly documented, with special attention to Doxygen-interpreted portion of the documentation. If there were any changes to the latter, run the makeHTML.sh shell script and verify that it does not issue any warnings or errors. Open the relevant generated HTML pages to verify correctness. Fix any issues.
Perform manual tests to ensure that new or updated features work as intended.
Also attempty to verify that the proposed changes do not break any existing features. Because there are no formal regression tests for PTS, this is often hard to do.
Commit any changes made locally and push them to the pull request.
On the GitHub page for the pull request, "merge and squash" the pull request into the master branch of the main PTS9 repository. The squash option combines all changes of the pull request into a single commit, thereby simplifying the main repository's history.
If you created the pull request, remove the corresponding remote branch by clicking the button offered on the GitHub page for the pull request. (If the pull request was authored by someone else, you cannot remove their branch).
Back on your local computer, update your local copy of the code and your personal fork by executing the following commands (you can do this in GitHub Desktop as well, but it is often easier to copy/paste the raw git commands):
```
git fetch upstream
git checkout master
git merge upstream/master
git push
```
Remove your local branch corresponding to the pull request.
If the change affected by the pull request is relevant to users, accordingly adjust the list of recent changes which is published on the web site. Specifically, open the text file with path ~/SKIRT/Web9/git/root/text/31-InstallationGuide/RecentChanges.txt and add a line describing the change at the end of the PTS section. The line should include the date of the merge commit. Finally, commit and push the updated RecentChanges.txt file to the Web9 repository.
Publish the SKIRT web site as described in Publishing the web site. This step can be omitted if the change is trivial, or delayed to combine multiple changes in a single publish operation.