GoodGitPractices

This is a brief cheat sheet for good practices as we use Github for QUDT. For general guidance on contributing to public projects on Github, please see this guidance, and in particular the section on submitting a pull request. There are essentially three stages:

Making changes to file(s)

Ensure you are up to date on your fork of the repo:

    git checkout main
    git pull

Create a new branch for your work. Please name your branch beginning with your initials, a hyphen, then some topical name:

    git checkout -b srr-mynewbranch

Do all your changes and additions and testing on this branch (srr-mynewbranch in above example). This might last for days or more.
Check that all the changed files are the ones you intended using the 'git status' command below.

    git status

If so, add them for tracking (you can also add individual files or files satisfying regular expressions):

    git add -A

Frequently commit, so that each change can be tracked and rolled back if needed.

    git commit -m 'Descriptive message about the change'

Bring in the latest changes in main before you push by merging:

    git checkout main
    git pull
    git checkout srr-mynewbranch
    git merge main

If you have Maven installed locally, re-serialize the files with Maven (see the README). If you don't do this step, you must do step 10 below.

   mvn spotless:apply install

Push your branch to the remote. The first time, you'll need to create the branch on your remote fork:

    git push --set-upstream origin srr-mynewbranch

Later, when you are on your branch, you can just say

    git push

If you did not re-serialize the files locally using Maven, do it now on the GitHub website:

a. Go to the GitHub website for your fork after you pushed your changes.
b. Select the Actions tab at the top and press the "Format sources and commit to branch" workflow.
c. Click on the "Run Workflow" button at the right, and choose your branch name from the list presented.
d. The workflow will re-serialize the files and commit the changes to the branch you chose. (If you want a copy of the changed files locally, you should execute 'git pull' back on your local machine).

If you want feedback but are not done yet

Submit a 'Draft' PR. Such a PR cannot be merged. You're safe.

Before Submitting a pull request

Each PR will be squashed (all commits will be aggregated into one). The admins will try to create a good commit message from your commit history, but if you squash your commits before submitting the PR, you have more control over that message.

Please use this checklist:

I have built the project locally with mvn install and it succeeded, or I re-serialized my branch on the GitHub website as described above
I have added an entry to the CHANGELOG.md

Submitting a pull request for review

Go to the Github website once you have pushed your branch.
Navigate to the code -> branches tab.
Click "New pull request". Pay attention to what the pull-downs say about what repository and branch is being merged into what other repository and branch.
Select your own fork/branch as source and the qudt/qudt-public-repo main branch as target.
Give the qudt admins access to your branch, so they can fix minor things without having to get back to you (speeds things up)
Submit the pull request
Wait until the results of the server-side build is displayed. If there is a problem, have a look at the details and try to fix it. If you cannot, the admins will look into it.