Skip to end of metadata
Go to start of metadata

You can configure Bitbucket to resolve tickets automatically when people push updates through to your Bitbucket repository.  Users specify commands and issues in a commit message, for example:

hg commit -m "fixes #6, resolve ticket #5 and see ticket #9 and ticket #5 in the tracker"

On Bitbucket, the commit message appears with links to each issue:

When you transition an issue with a commit message, the system cross-references the commit from the issue:

If you enabled an issue tracker on your repository after August 2012, Bitbucket adds the Issues hook automatically for you when you enable the Issue Tracker.  Older repositories with older issue trackers may or may not have this hook.  You can check if this hook exists for a repository by going to the Hooks tab in the repository settings:

Adding the Issue Hook Manually

You only need to perform this procedure if your repository has an issue tracker enabled but does not have an Issue issue on the repository. You must have administrative access on a repository to add this hook.

  1. Go to the repository's settings.
  2. Click Hooks in the left-hand navigation.
    The hook page appears.
  3. Select the Issues hook from the Hook dropdown.
  4. Click Add hook.
    A new section appears for the Issues hook.

  5. Press Save.
    The page remains unchanged but the hook is started.

Including Issues in a Commit Message

To link commit to an issue from a commit message, include an command-issue pair somewhere in your commit message. This pair takes the following format:

<command> <issue id>

You can link to a single issue or multiple issues.  The <issue id> can take an of the following forms:

issue #4711
bug #4711
ticket #4711

You should always include the # (pound sign or hash mark) if you to ensure that links back to the issue resolve.  If you omit the # (pound sign or hash mark), links from a changeset do not resolve.

Each action supports multiple <command> keywords. The following table lists the actions you can perform through a commit and the acceptable commands for that action.  All the keywords are case insensitive. So, for example, both close and Close work to close an issue.

ActionCommand KeywordExamples
resolve an issue
  • close
  • closes
  • closed
  • closing
  • fix
  • fixed
  • fixes
  • fixing
  • resolve
  • resolves
  • resolved
  • resolving

close #845

fix bug #89

fixes issue 746

resolving #3117
reopen an issue
  • reopen
  • reopens
  • reopening
reopen #746

reopening #78

mark an issue on hold
  • hold
  • holds
  • holding
holds #123
mark an issue wontfix
  • wontfix
wontfix #12
mark an issue invalid
  • invalidate
  • invalidates
  • invalidated
  • invalidating
invalidates #45
link to a changeset for the issue
  • addresses
  • re
  • references
  • ref
  • refs
  • see
re bug #55

see #34 and #456


  1. Anonymous

    cool feature

  2. Perhaps I'm doing something weird with my commits but resolving issues via commit seems incredibly unreliable.

    50% of the time, "close #" will function as intended but the other 50% it will just never close the item. Is there a time delay in how long it takes BB to register that I said to close the issue? If I open the commit, I can see the "close #" and can click on the issue number, but it will never close.

    The same goes for the accepted terminology - it's been a guessing game lately. "close" works but "closes" didn't, "resolve" worked once, but "Resolving" didn't. I'm one that likes to tack these at the end of my explanation (ie, "Changed all widths of module content to 270px, resolving #34") so is the extra text or the fact that I have multi-line commits causing issues? I'm trying to integrate the Issue Tracker into our every day dev but these unknowns (what terms work vs don't, is it finicky, do line breaks matter) make it hard to dive in fully.

    As an addendum, I use Tower for my Git - could this be a potential reason for the unreliability?

    1. Greg, It could be your Git.  I would suggest you file a support ticket next time you see this.  Apologies for the slow reply, I've had a ton of non-BB work to do lately.

      1. Perfectly alright - I've found (since then) that putting all of your "close, resolve, etc" terms as the first line of your commit changes the efficiency to 100%. It just seems to struggle if you try putting them further down in sentences, etc.

        I'll try and think of an intelligent way to make an issue as I haven't tested the exact details and no one else seems to suffer from this (tongue)

  3. Anonymous

    I'd like to create new JIRA issues from bitbucket commenting also. Could the same hook be applied against comments?

    1. You can file an enhancement request for this feature.

  4. I just made a commit fixing an issue (type=enhancement). I used the message "Fixes enhancement #18" for my commit, but the issue was not marked as resolved? All the other issues I have resolved had a commit message like "Fixes bug #9" and this works fine - marking the issue as resolved.

    1. Anonymous

      It only works if you have Fixes #… but with a word in between the parser doesn't recognize the 'Fixed' pattern.

      1. The table doesn't say what the parser recognizes or not. It simply says you can use one of the keywords (fx. "fixes" or "fixed") and then it gives a list of EXAMPLES. Given the different types of issues in BitBucket I would think the parser would recognize any of them, otherwise the table above should state excactly which issue types can be resolved using which commands.

  5. How often does it actually run? I use JIRA with bitbucket, and it seems that JIRA issues only get updated once a day.


    Or does JIRA perhaps only collect commits over a certain amount of time?

  6. Anonymous

    First time on git and code versioning ... Never thought of coding such an easy and organized way (smile) 
    I wish I could grab it when I learnt coding...! 

  7. Is there a keyword also to assign an issue to someone directly in the bitbucket comments or commits ?

    Something like "assign @Julien #issue 123"