Git workflow

Git workflow for any development, and further below extra steps required for merging into release branches.

Usual Git Workflow - targeted the master branch

When developing with the autoreduction code base, be sure to follow these steps:

1. Create a new issues, or find an existing issue, and assign yourself to it
2. git checkout master and git fetch -p then git pull recent changes to ensure your local is up to date.
3. Create a branch from master called <Jira-issue-number>-short-description-AR-<JIRA issue number> e.g. git checkout -b 1234-implement-validation-AR-1234
   • The AR is the project code in JIRA, and the syntax AR-<JIRA issue number> is recognised by Jira and associates the branch with the issue
   • You can also do just short-description-AR-<JIRA issue number> e.g. git checkout -b implement-validation-AR-1234, but having the issue number at the front allows for easier auto-completion
4. Push your work up regularly to your feature branch to ensure you don't lose any progress
5. Make use of git commit -a to amend commits when appropriate (this helps to keep the git history clean and understandable)
6. Once you are happy with your changes, create a pull request
7. Ensure that your pull request passes on GitHub Actions and code coverage builds
8. Resolve any review comments with a reviewer
9. Once the reviewer is happy they will merge your branch and close the issue

Git workflow with Release branches

For the full workflow we follow to prepare for releases see releases. Here concerned with the part of this workflow related to Git.

Very specific release branch changes can be committed directly to a release branch, such as changing the version number in setup.py to match the release, or some backport fix to an older release that no longer make sense to add to master.

For all other fixes that needs to be added to a release branch, follow the usual git workflow process, as described above, but where the following two differences

• The PR is based on the release branch

After the PR is merged into the release branch, we will merge the release branch back into master so that no work is lost.