Git Workflow

Branches

When developing, you should create a new branch from the develop branch (don't develop in master).

Naming

• Use branch prefixes to specify what type of change you are working on, e.g. bugfix/, feature/, or refactoring/.
• If working on a Jira issues, make sure you use the issue code in the branch, e.g. COLAB-1234.
• Use a short description of what you are doing in the branch name

Examples:

• feature/COLAB-2200-view-only-role
• bugfix/COLAB-2202-roles-displayed-incorrectly

Committing

What should go in a commit

Make sure you don't pack too many things in one commit. If possible, you should only ever pack code changes for a single issue in a commit. If there are severally logically distinct changes, consider splitting them into distinct commits even if they are part of the same issue. If there are lots of larger code changes (refactoring, style changes) make sure you split these from functional changes, as they might otherwise be drowned out. It is preferred for large refactoring and style changes to be in a separate pull request (not just a separate commit) if possible.

Commit messages

In your commits, make sure you include a short summary of the changes in the first line. If you are working on a JIRA issue (which you should be almost always!), you must include the issue code in the beginning of the commit between square brackets, e.g. [COLAB-1234]. Your commit message must always describe the changes you made - don't use generic commit messages.

For more details on how to write a good commit message, see How to Write a Git Commit Message.

Merging

Before merging the changes, they will go through a review process. Once you've finished your changes, open a new pull request against the develop branch. Make sure you don't try to merge into the master branch as all changes need to go through internal testing before.

Exceptions

If you're a contributor and are only making minor changes (e.g. small code style improvements), you can also merge directly to develop.