-1

I have an 8 pointer Story. Let’s call it for example XX1234

I have created 4 subtasks based on the list of actions to follow to complete the whole story implementation:

 1. XX1235
 2. XX1236
 3. XX1237
 4. XX1238

I intend to create one branch for each task's implementation.

Do we need to create each branch with the Parent Jira number? Like:

review/release19/sprint2/gowthami/v1/XX1234
review/release19/sprint2/gowthami/v2/XX1234
review/release19/sprint2/gowthami/v3/XX1234
review/release19/sprint2/gowthami/v4/XX1234

Or should we use the subtasks?

review/release19/sprint2/gowthami/XX1235
review/release19/sprint2/gowthami/XX1236
review/release19/sprint2/gowthami/XX1237
review/release19/sprint2/gowthami/XX1238

Please help me in understanding the pros and cons of each approach, and which one is more suitable in the described context.

1
  • Answering as a comment, since this might be opinionated. No, only create a branch referencing the id of the subtask. The parent issue can be easily reached by going to the subtask and navigating through it. Same applies to potential commit identification - only identify the subtask in the commit message, if the subtask is what you're working on.
    – Andy
    Commented Sep 7, 2020 at 9:43

2 Answers 2

1

To what end or purpose?

In other words is this necessary? Would not a simple commit message with the jira link be a better solution?

Are you doing unnecessary work? Obligatory xkcd.

What has been agreed with your team?

It can be arcane and confusing to the rest of us, but it must be salient to your team. In short you are asking the wrong audience.

1

It depends on how you use issues and subtasks in Jira along with the working agreements of the team. Considerations such as traceability, visibility, and system architecture will have an impact.

When I'm working with teams using Jira, I encourage them to use top-level issues (and Story is a standard top-level issue) to represent units of work that are deliverable and to use subtasks as necessary for visibility and tracking. The cases where subtasks have been the most useful have been where multiple people will be working on different pieces of the top-level issue or where commits and pull requests will be spread across multiple repositories.

Generally, if you will be working on XX1234 by yourself, all of the work will be in a single repository, and all of the work will be integrated at once, then I'd encourage a branch for the top-level ticket and perhaps consider referencing the subtasks in commit messages. If you will be working on XX1234 with other people, the work will be split across multiple repositories, or the results of different subtasks will be delivered at different times or releases, I'd consider creating the subtasks based on these factors and branching based on the subtask.

Of course, these aren't hard rules. It does depend on what you are trying to achieve.

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.