Option to reject commits without an issue key in their message (BB-2415)

Issue #5658 resolved
Peter Meyer
created an issue


We recently went from Jira OnDemand SVN to Git on BitBucket.

One thing we miss alot, is the ability to demand users entering a Jira issue key, when checking in code.

I know that Git is distributed, and a lot of the checkin/commit stuff is handled locally. But if i Jira issue check was done by BitBucket, no code could be added to "final destination" without an Jira issue key defined in the commit description.

So this feature request is, that you possibly come up with a clever idea for this :o)

Best regards Peter Meyer

Official response

Comments (171)

  1. Doron Gill

    ultra important enhancement. For on-demand customers especially it is unacceptable that Atlassian is pushing us towards bitbucket (e.g. end-of-lifing Crucible) and on the other hand not being able to maintain functionality

  2. Brett Cave

    +1 - this is the primary reason for us holding back as long as possible on SVN to Bitbucket migration. It's critical for large development teams, as a control for ensuring quality and auditable code!

  3. Andreja Milenkovic

    +1. This is very important feature that everyone expect from Atlassian integration team. Everybody sometimes forget or mistype issue key and that commit is not properly linked to JIRA.

  4. Brett Cave


    looks like the most popular issue for bitbucket right now, and there's a reason for it. Any feedback on when this will be added to bitbucket? Less than 3 months left until Atlassian shuts down Subversion and we need to migrate. This is currently the only solution that would cater for many companies' requirements, by the looks of it.

  5. Rich Mayfield

    Kind people of Atlassian, please make this a part of your product roadmap.

    Or... at least tell us why you will not include this on your roadmap. When a vendor removes functionality it's typically either for a good reason, or they are plain blind to the fact that people really, really need it.

  6. Martin Geisler

    To @Avichay Eyal @Ofer Buhnik @Yuval Pemper @Eyal Zach @Jernej Tonejc et al: your "+1" comment was sent by mail to all 67 watchers of this issue. Please just use the new vote functionality instead to show your interest in the issue.

    Have the people asking for this thought about setting up a local mirror instead and simply checking the commits there?

    In my company, we employ a local mirror for our repositories to speed things up (0.5 sec vs 3 sec) and this would also be the ideal place for us to install any hooks we might want: since it is a local server we have control over it and can do any checks we want.

    Unless you want a very simple regexp check for the commit messages, I feel that a local mirror is the best way to go since Bitbucket might not implement exactly what you want anyway:

    • Do you need an issue for merge commits too?
    • What about commits by the release manager?
    • Bugfix commits on a stable branch?
    • Commits that only touch the /contrib directory?

    Unless Bitbucket makes this very flexible, I think a fair amount of you will have to implement the hooks yourself.

  7. Martin Geisler

    To @Carrie Jenkins @Julie Ricci @Joe Jongue @Lee Trevena @acorbino and all the others who add "+1" comments on this ticket: please stop!

    Your unhelpful comment is sent to the 101 others who are currently watching this ticket. We don't need to see five mails per day saying just "+1", we want to see an interesting discussion about the ticket. You should instead use the vote feature Bitbucket implemented a while ago. That will show your interest in the topic without spamming everybody else.


    To make this a little relevant, have anybody thought about the issues I brought up above?

    This feature seems like one that is better implemented in your local mirror. Otherwise the Bitbucket team will have to build in controls to let you say if you want merges to be considered too, if it should apply on all branches, for all users, etc. That is, a one-size fits all solution might not really fit all — people who want to lock their repository down like this clearly have non-standard requirements and so it is not certain that a standard solution can work for them.

    Also, this is a problem that you can solve on a technical level (with custom code) or on a social level: simply sending a mail to your developers once per week with the names of the offenders can do wonders.

  8. Ivan Sopov

    For all who is bothered with "+1" comments - you can vote for the https://bitbucket.org/site/master/issue/7794/dont-allow-people-to-post-1-on-an-issue issue to forbid them.

    If we wanted to use a local mirror - we would not use bitbucket. We'd use our own git server instead. Personally I don't need really custom pre-recieve hooks - some amount of reasonable non-configurable basic options will make me happy. (Actually there are already some in "branch management")

  9. Nicolas Cadou

    It's pretty funny that the ticket requesting pre-receive support to filter out crap commits ends up being so popular that there has to be another ticket requesting a pre-receive hook of sorts for comments, to filter out crap "+1" comments.

    Funny and ironic. :)

    It just shows that when you face uncontrollable behavior, pre-receive hooks are pretty damn useful, and having bitbucket support that would be awesome.

    So, +1 here. I would myself use it to enforce a no-merge-commits policy for selected branches, to ensure merged branches were properly rebased beforehand. I'm obsessive about clean straight history lines as you can tell. :)

  10. Nicolas Cadou

    @Martin Geisler the whole point of using bitbucket/github/whatnot is to not have to set it up yourself. There may be other advantages but for most small teams I suspect that's pretty much it. Even though installing a public gitlab service is not that hard (and gitlab is loaded with features, so it would probably not be a step down from bitbucket for most people,) I'm pretty happy to just use bitbucket as the no-hassle central repo I can point everyone to. If I have to set up an intermediate repo so that I can use pre-receive hooks, then accounting for bitbucket would become as much a hassle as it would become entirely unnecessary.

  11. Stephen Coetzee

    @Martin Geisler Very much what the others are saying. If I wanted to self manage a git backend, I wouldn't have needed bitbucket. But with having small development teams in several countries, that would have necessitated a VPN setup into the works too, with accompanying firewalling and training for using the several additional layers of systems.

  12. Justen Stepka

    Official update:

    Internally at Atlassian we've expressed in interest in developing this feature as it would greatly help our teams develop software. That said, our focus for the short to medium term, will be to provide SSO and better user management with our OnDemand JIRA and Confluence products. This project will take us into the early part of 2014 -- that said, if we can find an extra development cycle I will be sure to keep this item on my short list of potential quick wins.

    Cheers, Justen -- Bitbucket product manager

  13. Dan Fabulich

    I filed issue #8286 (Block commits by regular expression) as a fork of this bug. I understand that supporting arbitrary pre-receive hooks might be expensive, but all we need is the ability to block commits that do/don't match a regular expression, which should deliver 80% of the value at 20% of the cost.

  14. Nikita Gupta

    It is creating a lot of confusion for the teams that have moved from jira on demand svn to git. Now the team adds a jira issue and it always goes through without checking if the issue is open or not.

    Teams like us, who have the release workflow depending on this are facing unforeseen issues due to this. Should have been fixed yesterday!!!

  15. Mike Schinkel

    If people keep posting +1 instead of (or in addition to) voting then obviously it is the UX on this page that is to fault and/or simple voting does not offer people what they are interested in.

    Being the 3rd or 4th person to admonish existing posters about posting +1 won't cause new people to stop doing it, especially if they are doing so others can see their name associated with their "vote" vs. just voting.

    The only way the +1s will stop is if Atlasssian reworks their interface to provide an alternate solution to address why people keep posting +1s.

    FYI, it's very non-obvious that voting is even possible; it's a tiny link buried in a sidebar box with several other non-descript links. If this is an issue that Atlasssian cares about (vs. people who are complaining about it )they should change to a BIG VOTE BUTTON at the top and also next to the comment button, and they should display a list of all avatars of people who voted so they will "feel" like their vote actually got counted.


    P.S. Also it's an easy fix for us. If the +1s annoy you too much, just click the "Stop watching" link.

  16. Brett Cave

    I agree with you Mike - I stand to be corrected, but I remember looking for a Vote link when I initially wanted to vote for it in June 2013 and not seeing it. Not sure if the Vote feature was added since then, or whether it was oversight.

    New voters are now following the old pattern - is it not possible for the original issue to be modified to include a note on how to vote? There's been a handful of comments asking people to stop +1'ing in the comments, but it doesn't seem to be effective.


  17. Abdul Ismail

    yes, also; it's so hard to find that vote button once it appears there, could we please get a nice big, green .ico on issues to be voted on so it can attract enough attention to it that noobs don't have to go on a wild goose chase for it. thanks.

    I also commented '+1' first, also if I have to login/watch the issue to vote, make that obvious as well please

  18. Sam Kellett

    Maybe this is a good real-life scenario to push for a feature request that if a user comments with just a '+1' then instead of adding a comment, bitbucket will add a vote. I think it's always a good thing to do to change the functionality of a system around how it is used rather than trying to force people to do something different.

  19. Wade Chia

    @Justen Falk It's now almost Q4 2014.

    Is this going to be moved to your " short to medium term" roadmap anytime soon?
    Are we really going to have to wait 2+ years for this? I guess if you wait long enough, it will become someone else's problem...

  20. Jörg Lehmeier

     Vielen Dank für Ihre Nachricht,

    ich bin bis einschließlich 03.04.2015 nicht im Büro. In dieser Zeit werden Mails, die an diese Adresse versendet wurden, nicht bearbeitet.

    Ab 06.04.2015 stehe ich Ihnen wieder zur Verfügung und werde Ihre Nachrichten beantworten.

    In dringenden Fällen wenden Sie sich bitte an unser Support-Team unter support@vepos.net oder telefonisch unter 0911 / 37 84 37 - 20.

    Bezüglich Vertrieb und Marketing vertritt mich Frau Zweschke vzweschke@vepos.net oder telefonisch unter 0911 / 37 84 37 - 0

    Vielen Dank für Ihr Verständnis.

    Jörg Lehmeier Dipl. Wirtschaftsinformatiker Geschäftsführer

    Unternehmenssoftware & innovative Betreuung

  21. Michael Bean

    I'd like the option to make this only a requirement of non-merge commits since we have some branches that don't have issues related to them because they correspond to which server uses the branch. I'd still like to push those branch or those commits to branches.

    Does that make sense?

  22. Benjamin Paz

    The ability to reject commits in the server side repository is essential. We need this capability for the update hook. Without this feature we will be obligated to use a non BitBucket approach. Please solve soon.

  23. Wade Chia

    @Jan Matějka don't be sorry, this issue is a massive #fail on bitbucket's part, IMO and I haven't heard the "s" word from them.

    can u share your experience here with regards to mirroring? Did you consider github instead for mirroring?

  24. Scott Carpenter

    This is a problem as our team grows, and given the existing Jira integration to link through issues it is the logical next step to include a hook to prevent commits without issue keys.

  25. Matt Cook

    I deal with this all day long with my overseas dev team. I can't monitor all their machines for local git hooks...server side is the way to go. I basically rebase every single feature branch once they create a pull request and amend the commit messages where they forgot the issue key. Such a waste of my time, but necessary for large projects.

  26. Wade Chia


    In 3 months, it will be the 3 year anniversary for this feature request (way to be agile, bitbucket!) .
    The lackadaisical accountability and lack of feedback from bb's product management is hugely disheartening.

    Today I came across this announcement in the ether: https://github.com/blog/2051-protected-branches-and-required-status-checks

    For my purposes, it should fit the bill perfectly, I am planning to protect all my branches (including master) with their "status check" API. I won't even have to waste any more of my time hosting Atlassian Stash just to have this feature.

    So unless bb announces something soon to match this, I will be saying adios to bb soon. It's been fun.

  27. vlad ko

    Wow ... Such lack of response is just unacceptable.

    I guess we'll be moving away from BB also.

    3 years to add a regex check, and yeah I know it's more complicated than that... But to ignore this for 3 years is a joke on all of your customers.

  28. Mark Rodrigues

    Am I right in understanding this is the 5th most up-voted open issue and the last Staff response on this thread was more than 2 years ago? I have a lot of respect for the folks at Atlassian so something doesn't quite add up here. What am I missing? Is it really hard? Is there a simple work-around?

  29. Daniel Bennett staff

    I can't speak to timelines as I'm the engineering manager not a product manager, however, I can at least say something.

    First, a couple of OT items:

    1. We don't have a lot of people on the Bitbucket team, all things considered, however, a lack of responses from product management on at least the top 20 issues is a problem we've been working to resolve. We're hopefully closer to fixing this now so keep an eye out for some more activity on these in the next few months. I've been trying to at least interact with users on the top five open items (which now includes this issue) to keep the conversation open but I'm not very good at this so I've limited my visibility. In short, we know communication is a problem.

    2. Here's a snippet with some thoughts on the value of age/rank as a proxy for prioritization: https://bitbucket.org/snippets/dbennett/bngMG -- tldr: we do pay attention to top-voted issues, but there are problems with the model.

    Back on topic:

    @vlad ko you hit the nail on the head. It's just like a regex, but not actually that simple. This is a big problem and it gets more complex as you start to work through the possible requirements for such a feature: commit comments, branch names, code linting (?), override permissions, etc. Surely, here's a solution here, but no code hosting service yet has sorted out how to do it*. I'm hoping that with Build Status and Connect Add-ons being released we can find a way to do what we need here with some Git trickery -- but we've only begun to talk about the potential solutions.


    Dan Bennett, Bitbucket Development Manager

    * Amazon, Microsoft or Google would be the first here as they have the infrastructure to charge you for the compute used to analyze your own code.

  30. Edward Lee

    Thanks for the reply, Dan. Don't boil the ocean. Do something simple to start. If you are not good at talking to your customers, then do it more often and get better at it :-)

  31. Michael Hofmockel


    With all due respect for a free (awesome) product, at this extremely late hour with no product to show, your communication is but hand waving.

    How about an ETA? Or provide some strategy/tactics for getting this done in my life time?

    Pointing out that no other service has not done this yet, only gives support to a potential point in which to differentiate yourselves as a service with.

  32. Ryan Roper


    While I applaud your effort in reopening communication channels, this still strikes me as a lot of excuse-making. A number of these issues had a significant response within weeks of their initial suggestion... so it's not simply a matter of "ballot stuffing". Also, I don't see this as a case of more feature requests than engineers, since the teeming masses are predominantly asking for the same (few) features.

    Look... we all get that these things can't be written overnight, and that you've got more workload than resources. We all face that equation in our daily life. But you can still prioritize the issues you want to tackle, create timelines (even if it takes years to deliver), and communicate it to stakeholders. That's where Bitbucket has really dropped the ball on this. If I told the shareholders of my company that requests haven't even been acknowledged because there are "more people requesting features than there are people implementing features", I'd find myself out of a job in a matter of minutes.


  33. Daniel Bennett staff

    @Ryan Roper @Michael Hofmockel sorry, I missed the important bit on my original post: To be clear, I cannot provide an ETA. I can speak for engineering only, not product management. As engineering, however, I can tell you that if I don't have anyone working on it right now it is not likely to be done in the next 6 months. When I do have someone start on it I'll be able to speak to it, or, in 6 months I will at least re-affirm that we're still not doing it.

    I apologize if it seemed like I did an information-free drive-by. A recognition that we need to improve our management of this issue tracker and a "not doing it right now" are all I have.

    @Edward Lee see, this is why I shouldn't be talking to people.

  34. Edward Lee

    Dan, would rather be talking with you than your PM :) Disclaimer: PMs, as well as engineering managers, are some of my favorite people in the world.

    Thanks for letting us know that this is unlikely to be implemented in the next six months.

  35. Ferenc Kiss [Midori]

    Hi everyone!

    Although I don't have a perfect and complete solution, here is something that may trigger some great ideas for this frustrating problem.

    So, for hosted JIRA / for hosted Git / for hosted Bitbucket Server, we do solve this problem. We built and support add-ons that do even more than this, as they can verify the commit message from multiple aspects (format, length, mentioned issues, etc.), the committer's identity (valid user account? included in a user group?), the changed files (are you modifying paths/files that you're supposed to modify?), etc.


    Even better, we will be releasing a new add-on for Bitbucket Server in the next few weeks that reduces installing this mechnanism to some clicks (no need to work with hook scripts in the filesystem). (Just email me at aron.gombas@midori-global to get a preview release from the add-on before the official release.)

    How is this related to Bitbucket Cloud?

    You could figure out some work-around along these ideas:

    1. You could start using a secondary remote called "verified-origin". You install the verification hook script to "verified-origin", and you push to "verified-origin", and only if that's successful, you push to Bitbucket. This requires some discipline, yes. Tip: Git allows pushing to multiple remotes in one go, but as far as I know, it isn't transactional yet (meaning that even the commit is rejected from one remote, the other remote may accept that). It may worth a try though.

    2. You could put a Bitbucket Server in front of your Bitbucket. You install the verification mechanism to Bitbucket Server, and push to this. Then, you automatically mirror the repo from Bitbucket Server to Bitbucket using the Repository Mirror Plugin.

    3. If you want to stay 100% in the cloud, please vote for this feature request so that we can see if there could be enough momentum behind an initiative behind this.


    Aron Gombas

  36. Erik Johnson

    This should not be an issue, git already supports this, you just need to provide us access to customize the pre-receive hook on the hosted repository and let us look up whether a given jire id is for an open ticket via e.g. curl. I'd drop BitBucket and just use OpenSSH to serve my hosted repository but my operations team is convinced that BitBucket is superior. Seems to me that an anti-feature like this is pretty darn inferior. I can do this in BitBucket server, too, since I have shell access and can edit .git/hooks/* as I like. Only hosted BitBucket prevents me safeguarding my development history in the most common and obvious of ways. What gives?

  37. Erik Johnson

    As a general note, enforcing this at commit time isn't really what you need. You need to enforce it at push time, on the hosted side, or you lose control and now you're herding cats (well, software engineers but same thing.) It's always possible to rewrite commit messages in your local in order to get your commit history in line for a push.

  38. Ferenc Kiss [Midori]

    @Erik Johnson Ideal is to enforce this both at commit time and push time. As you pointed out, only push-time gives you the 100% control and security, but commit-time makes it more convenient for the developer. He/she can to fix commit right away, no need to "rewrite" historical commits when the push gets rejected. Commit Policy Plugin already supports push-time, and the next version will also support commit-time checks!

    (Rewriting commit messages can sometimes be problematic, like in case of Mercurial if you need go before a merge commit.)

  39. Pradeep

    Hi Everyone,

    Do we have any update on this issue being fixed in BitBucket? if not so, why in the below link https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html#Usingrepositoryhooks-Creatingyourownhooks it is said that "Pre receive hook can be used to prevent force pushes to the repository or check whether all commits contain a valid JIRA application issue key". I am confused, Based on this, I have to decide to go with GIT LAB or Bit Bucket. Any suggestions please?

  40. Alastair Wilkes staff

    Hi everyone - Dan's last update above still stands as the status; this is something we'd like to do (at least as a basic implementation), but it's not slotted for delivery in the next few months.

  41. claudiofreire NA

    You know, a simple feature that could let us tackle this on our own, would be if webhooks could reject pushes/commits. In essence, making a webhook a filter - if the webhook fails, the push fails. In the UI, it would be a simple checkbox on webhooks ("is filter" or whatever), and on the server it would mean just not ignoring HTTP return codes on the underlying hook if the webhook is marked in this fashion.

  42. Wade Chia

    I was at the Atlasssian Summit conference a few months ago, and I got the distinct impression that bitbucket is a low priority product for them. I was desperately seeking a PM or somebody relevant to give a earful about all these feature requests which have been ignored for years.
    From all the sessions that were available, there was no attention allocated to BB at all. Zero.

    These are my personal conclusions, from speaking to various people:

    1. The BB team are not with the big development groups in Oz, they are a small group in California that were acquired by Atlasssian.
    2. The BB team are not an Atlassian "A" team. They are probably not the "B" team or even the "C" team.
    3. Don't hold your breath, just move on to other SaaS offerings in the market (github is OK for this) or just host your own servers.
  43. Anders Hedberg

    I also met the Atlassian representative at Websummit, and I got the impression that they did not know their products that well, so it turned into a pretty awkvard conversation... We just installed Gitlab community edition on our servers. It could use some GUI work but seems to work good enough for us and some customers. We will replace our Stash/JIRA instace with it as we never really got that to play in a nice way.

  44. Ferenc Kiss [Midori]

    Guys, you can actually validate your commits with JIRA and Bitbucket Cloud!

    The biggest release of our Commit Policy add-on was published some days ago, and it comes with a killer feature to verify the commits at commit-time locally (in addition to the push-time verifications on the server). This can be efficiently used with providers, where you are not allowed to configure the server-side hooks, like Bitbucket Cloud or GitHub.

    Make sure to give this a try.

  45. Joe Constant

    That's a nice plugin, but Atlassian's pricing model for plugins sucks. I don't need this plugin usable by all of my Jira users since only a small fraction of them actually have BitBucket accounts.

  46. Shawn Duncan

    Validation at commit time locally is something we all get for free from Git. The hook is a simple regex check. But local git hooks need to be installed by each developer. The feature request is for pre-receive because then we are not relying on each member remembering to set up their local properly.

  47. Thomas Kells staff

    Just wanted to give a quick update on this issue. We are currently moving into internal testing of a pre-receive hook that rejects pushes when any commit does not have a valid issue key in its message. The current implementation relies on the per-repository "Links" setting to determine what a valid issue key looks like. This gives us the ability to validate against Jira, Bitbucket Issues, Connect add-ons, and any configured custom Links.

    While this is not a true "custom hook" as the previous title suggests, this does strike a nice balance between customization and not placing potentially unbounded load on the Bitbucket infrastructure. I have updated the title to reflect the actual proposed solution. I will also be providing updates here over the coming weeks as we move through our internal QA process and into a public beta.


  48. Thomas Kells staff

    @Tim Burden JIRA/Custom Linkers only validate against a regex. However, the Bitbucket issues Linker does validate the existence of the ticket since the validation happens inside the context of Bitbucket and wouldn't require potentially expensive API calls.

  49. Alexander Amelkin

    Is this feature available in Bitbucket Server? I don't see any 'Links' at all in repository configuration pages. The only thing about links that I have in Bitbucket Server is 'Application Links' in global configuration.

    We really need a hook to validate commit messages against our policy or at least against JIRA for issue existense.

    We're using Bitbucket Server 5.0.1

  50. Alexander Amelkin

    Ferenc, thank you. I've recently been pointed to that plugin already just to find that despite it being free, it requires a significantly pain JIRA counterpart plugin to work. If anyone is interested, I have a maybe-not-so-elegant-and-integrated but completely free solution that I described here: https://stackoverflow.com/questions/16091516/git-server-side-update-hook-in-bitbucket/44966631#44966631

    In short, it's a real update hook for Bitbucket Server's backend git instance. The hook is written in shell and node.js and is completely open-source.

  51. Florin D

    @Thomas Kells Same question here, is this rolled out for the on premises server ? We use v5.4.1 and I don't see it.

    Surprised you don't have a good/transparent way to assign issues releases. That is your business after all.

  52. Log in to comment