Developer workflow

When working with large binary files (like maps or texture packages), it is good to get as many fixes in as possible to minimize the number of commits. To help you with that, reporters will start the issue subject line with the map name. This will let you easily search to get the all the issues for a particular map. Check the subject line for both the map name itself like 01_NYC_UnatcoHQ and for the multiple instance form xx_NYC_UnatcoHQ. It's also good to check if an issue reported for one instance of a multi-instance map is present in any of the other instances; if it is, you should fix it in all affected instances. It is typically most productive to address a batch of multi-instance maps (like all of the Unatco HQ variants) in a single session and a single commit. See the GitLab wiki for info about committing.

Starting to work on an issue

When you are looking through the issues to pick something to do, it is recommended that you open issue listings in separate tabs to help keep track of what you are doing. Once you have set an issue aside to work on, set the assignee to yourself so it will show up on your page and set the status to "In-Progress". The commit message will close the issue automatically later on (see below).

Commit message integration

When typing your commit messages, instead of describing what bug/suggestion you are fixing/implementing you can simply refer to it by its number here in the issue tracker. This will also close the bug/suggestion automatically. Which is kind of neat.

An example of a commit message could be "Fixes #5, #6 and implements #1"

For this project keywords are: "fixes", "closes" and "implements". They are not case sensitive and as long as there is a space or a colon after the keyword and the issue ID it's fine. When using several issue ID's you must separate them by a space, comma or &.

The terms "fixes" and "closes" should be used when fixing bugs while "implements" should be used when implementing suggestions. The three keywords all do the same thing, it just seems to make more sense to say that a suggestion has been implemented rather then fixed/closed.

If you don't want to close an issue but you like to refer to it (if you are working on something, not done with it but want to refer to it in the commit so it shows up in the issue history) you can use "refs", "references" or "IssueID" as the keywords followed by the ID.

For more in-depth information refer to: http://www.redmine.org/projects/redmine/wiki/RedmineSettings#Referencing-issues-in-commit-messages