Say that you work on a feature described by a single JIRA ticket and during the work, you:

  1. Create feature-specific code like the GUI or specific use-case behavior.
  2. Some of the code was generic so you placed this infrastructure code in a shared library.

As an example (deliberately simple), say that the ticket is about changing a message somewhere in the application and that the message should contain the current year somewhere in it. So you first amend your PHP code where the message is and also create a helper function getCurrrentYear() in your DateUtils library.

What is the best practice now to store these changes to a source code repository and assign those code changes to JIRA ticket(s)? (Assigning commit to a JIRA ticket means in our case adding a tag to a commit message, for instance "Implemented feature #123".)

As I see it, there are these main options:

  1. Create one commit and assign in to the given JIRA ticket.
  2. Create two commits (one for the use-case logic and one for the infrastructure code). Assign both of them to the single JIRA ticket.
  3. Assign only the feature-specific commit to the JIRA issue and leave the other unassigned (when viewing the ticket in JIRA, only the first commit will be visible in the "source code" tab).
  4. Similar to 3 but you have a generic ticket like "Infrastructure improvements".

Is there a best practice / recommended way? What are some of the benefits and problems of the various possibilities?

  • 1
    personally id create a jira subtask for the two subtasks and commit appropriately
    – jk.
    Commented Jul 18, 2013 at 14:18

2 Answers 2


In my experience the best way is to assign the commit(s) to the one Jira-Ticket that caused the change. The reason for that lies in the way I use the repo-history: whenever I'm not sure about a piece of code I consult the repo-history to find out why this change was made (commit comment), or who was responsible (author) to ask him/her f2f. In your example it would be clear from the repo-history and the Jira-ticket alone why it was necessary to introduce the year.

I wrote 'commit(s)' because for me it is totally admissible to do several commits according to one ticket. For that reason I use the ticket-number as a prefix of the commit-comment.

Besides, for me the overhead of creating new subtasks and do the whole Jira-lifecycle with them would be too big.

  • Great point. BTW we also typically do multiple commits per one JIRA issue, I just wanted to keep the example simple. Commented Jul 18, 2013 at 23:47

Since you're using JIRA, consider authoritative guidance provided in its documentation.

Use case you describe is intended to be addressed by sub-tasks, which purpose is described as follows:

Sub-task issues are useful for splitting up a parent issue into a number of smaller tasks that can be assigned and tracked separately. This can provide a better picture of the progress on the issue, and allows each person involved in resolving the issue to better understand what part of the process they are responsible for...

I used this feature a lot, for the purposes like you described (code targeting different aspects related to some bugfix / feature request) and in my experience, these were working very well.

One relatively minor complication I often encounter, and that you might also find worth keeping in mind, is also pointed in the documentation of JIRA sub-tasks, along with guidance on how to handle it:

Sub-tasks cannot have sub-tasks of their own. However, if you need to break up a sub-task into smaller sub-tasks, you could achieve this by first converting the sub-task to a standard issue. You would then be able to create sub-tasks for it.

Regarding commits, when using sub-tasks you rather need to find out which way feels more convenient by trial and error. There's no one size fits all approach here. Such experimenting with various approaches could be rather painless if your VCS / JIRA integration allow to edit commit message and re-upload repository.

  • Side note any decent VCS / JIRA plugin should allow you that. If your doesn't, consider switching to better one, because with it you would have much harder problems than optimal assignment, any typo in commit message (feature #12 instead of #123, or missing #) would break things badly.

In my experience "natural mapping" of commits to respective sub-tasks has been typically convenient.

If your integration supports having more than one issue ID in commit message, this gives you additional options to experiment with. Eg to me, in some issues it was more convenient to supply parent/sub-task pair of IDs in commit messages (I've been using Fisheye), like

  • commits for first subtask go as
    parent #123 sub-task #124
  • commits for second subtask go as
    parent #123 sub-task #125
  • etc...

That way, subtask-specific commits are visible in subtasks, while parent issue displays all commits. This was useful infrequently though, in most issues I dealt with, straightforward mapping to sub-tasks was sufficient.

  • Thanks for such a long reply, however, our issue schemes don't support subtasks. Even if they were, I didn't especially like how JIRA treated hierarchies (they are limited as you pointed out, parent issues cannot display subtask commits etc.). But it's some good information there, thanks. Commented Jul 18, 2013 at 19:53
  • well, you asked for "best practice / recommended way" didn't you? If you're interested in fine-tuning particular deviation from recommended way, that would be a different question, consider posting it separately.
    – gnat
    Commented Jul 18, 2013 at 19:59
  • ...oh, and in that different question, you better add a good explanation of why it's necessary to deviate, if you want to avoid being dragged into cumbersome circular clarifications. "- We have no subtasks. - Reconfigure to JIRA with sub-tasks. - But boss prohibited. - Come to boss and make them know that this is bad practice. - Oh but they say they know that and it's necessary for us. - Come to boss an learn why it's necessary..." and so on, and so forth. If you want to proceed straight, make sure to cover these questions to make it go out of your way
    – gnat
    Commented Jul 18, 2013 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.