I've seen this answered for Stash but not using bitbucket:
Since the migration from FishEye/Crucible, developers can now check in without an issue key, and of course that means that they are :)
First to double check that this is intended functionality, and I haven't missed an option somwhere?
Assuming that's the case...
I see you can add hooks on a per repository basis (currently one is defined, presumably the connection to JIRA)
I saw from the stash question that using hooks is problematic because it can reject the push but not the original commit ... but honestly I don't care, if someone tries to check in without an issue key then it's their problem to sort out the mess!
Any ideas? If you can add extensions to egit to enforce it there, that would work too (but I couldn't see anyway to accomplish this)
You can't easily set up hooks to prevent this sort of behaviour, unfortunately.
When you can do is restrict who can merge into master, which can impose a review process that you can use in conjunction with, say, pull requests to ensure that all merges include an issue number. Commits can always be amended after-the-fact to include an issue number (this is usually okay to do on a branch, even if you've pushed it up for review, but you don't want to do it once it's merged to master)
After some further investigation:
I think my preferred option is going to be to move everyone to Mylyn, which makes it easy enough for people to tie in their code changes to issues that it might just happen :)
Adding git hooks would have been nice, except egit doesn't support them (there's a patch in their issue list that lets you use the rhino js scripting engine to support commit hooks, so that will be plan B)
As an SVN dinosaur, I'm not (yet!) quite on board with the "branch then remerge" process for all the 1-line bug fixes that comprise a high % of our commits - but Robert's suggestion above will form part of our process if/when we move to that.
It's part of the nature of a distributed repository - because the commits are local, you need to have the hooks locally. But hook scripts are a pain to set up locally, which is why Git doesn't bother replicating them.
If you have your own server, you can put these in - but it cause problems, because people can't push if there are conflicts. They can rewrite their history, but if they've done merges instead of rebases then this will cause more problems.
The only solution that works - that I know of, anyway - is to restrict the ability to push to master, and use a code review process (such as the pull requests described above) to ensure that the commits have JIRA issue numbers on them before merging.
Code reviews are a more painful process than a stick that simply slaps the developer's knuckles when they stuff up, but if your team doesn't have the discipline to put an issue tag in, then maybe they'll benefit from a review process?
Okay - there is one other alternative. When you install Git on the developers box, you can set up a commit hook for them in their git templates. Depending on your process for doing developer setups, this may be easy or it may be really annoying.
I personally haven't tested this, but it does look like it would work. Here's some info on using templates to manage hooks: http://stackoverflow.com/questions/2293498/git-commit-hooks-global-settings
and a tool that can make it easy to do as well: https://github.com/icefox/git-hooks
I must emphasise that this is applied to the developer's machine, NOT to the central server.
Re: Robert's alternative - be aware that egit (as I noted in my answer) uses its own implementation of Java that does not support git hooks. So if you're using the integrated eclipse this is not a solution.
"SynSupport" - Assuming you're using eclipse: I've moved everyone over to Mylyn + the Atlassian connector. It basically gives you a list of JIRA issues in an eclipse perspective, you can just activate an issue to start working on it and it then fills in the commit tab for you according to a template of your choosing. It's useful and low profile enough that it will get probably get used.
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs