User Guide 5.4.x

Force a rebase of the source branch before a integration merge can be done. If a rebase is possible and makes sense, the merge is not allowed without rebasing the branch first. In result this check enforces the "The Rebase Option" in the following tutorial: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview

Attention

It is recommended to use this option on private forks only. The rebase strategy can be used with the force push only, which could have influence to other team members. Use this strategy carefully in a public repository. See also pros and cons in this Atlassian article

https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase/

If the option is set, and the following regular expression is given,

^\[([A-Z]+)-(\d+)\](.|\n)+

then each commit message must start with a issue key, which is in brackets. Additionally after the key there must be a further description (e.g. "[TEST-1] further text" will be accepted. Only "[TEST-1]" as commit message will not be accepted. Also "TEST-1 and some further text" will not be accepted, because of the missing brackets. If the commit message do not match, the push or merge is blocked.

If this option is enabled, the related text field should contain a regular expression, which will define the valid status of issue key references.

Attention

In version previous 2.x, the status list was not based on regular expression. It was just a comma separated field.

If the option is set, and the following regular expression is given,

Reviewed|Integration Request

then a merge or a push can be done only, if the issue status is "Reviewed" or "Integration Request". (Of course also a more complex regular expression is possible.)

Attention

If you have a international company and if you will support different languages, then you have to respect this in the regular expression. For example the regular expression

To Do|Aufgabe

will support the german and english version of the related status.

If the option is set, and the following JQL is given,

(assignee=benni and fixVersion is not EMPTY)

then a given issue reference will be checked with this JQL. So a merge or push is only possible, if the assignee is the user "benni" and the fix version is set to any version.

(assignee=$currentUser)

You can also use the keyword "$currentUser", which will be replaced with the user wich will execute the merge or push. So the JQL ensure that the merge/push can only be done by the assignee of the issue.

This is a push example, but the behavior regarding the merge hook is the same. (e.g. TEST-10000 does not exist)

git checkout -b my-branch/something
git commit -m 'TEST-1 TEST-10000 this is a example'
git push

git checkout -b my-branch/something
git commit -m 'TEST-1 TEST-10000 This is a example'
git commit -m 'This is a example'
git push

git checkout -b my-branch/TEST-1
git commit -m 'This is a example'
git push

git checkout -b my-branch/something
git commit -m 'TEST-1 This is a example'
git commit -m 'This is a example'
git push

This is a push example, but the behavior regarding the merge hook is the same. (e.g. TEST-10000 does not exist and the escape character is "!")

git checkout -b my-branch/something
git commit -m 'TEST-1 !TEST-10000 This is a example'
git commit -m 'This is a example'
git push

A Push and a Commit will be successfully, because the issue TEST-1 does exist and the issue key TEST-10000 is escaped.

If the option is set, and the following regular expression is given,

master|develop

then the checks will be validate only if:

• you will push commits in the master or develop branch
• you will merge pull requests in the master or develop branch

If you will push or merge change-sets in a branch with a other name, then the checks will not be evaluated and the merge/push is always allowed.

This is a push example, but the behavior regarding the merge hook is the same.

If the option is set, and the group admin is configured. Additionally there are several commits which would block a push or merge (e.g. no issue key reference is available), then the behaviour is:

git commit -m 'this is a example'
git push

git commit -m 'this is a example'
git push

Example: The keyword <skip-merge-check>

git merge -m "Merge message with keyword <skip-merge-check>" branch-name
git push

If the option is set, and the following regular expression is given,

branches\\/[bug|feature]+\\/.*

then each new branch needs to match this regular expression.