Pull Request Links Too Many Issues

Here is my situation

1. Two JIRA issues are created around the same time (ISSUE-1, ISSUE-2)

2. Respective branches are created (feature/ISSUE-1 and feature/ISSUE-2)

3. Work begins on feature/ISSUE-1

4. A little while later, work begins on feature/ISSUE-2

5. feature/ISSUE-2 merges from feature/ISSUE-1, the commit message says "Merged branch 'feature/ISSUE-1"

6. When the Pull Request is created, Stash mentions that two issues are related, namely ISSUE-1 and ISSUE-2.

I understand that Stash is likely searching through the commit messages and finding references to the two issues, but what can I do to avoid having Stash identify ISSUE-1 as related?

1 answer

1 accepted

1 votes
Chris Fuller Atlassian Team Jun 19, 2014

The pull request to master is going to pick up everything that is different between your source branch and the target. If that includes partial work from ISSUE-1 that you've merged in, then what the pull request reports is correct.

The whole point of topic branches branches is that they should be developed independently of one another. Your feature/ISSUE-2 should be merging from master of it needs to, never from feature/ISSUE-1.

Chris Fuller Atlassian Team Jun 19, 2014

Further, if ISSUE-2 actually *depends* upon ISSUE-1, then you should be targeting feature/ISSUE-1 for your pull request instead of master. It is broken to bring partial work from ISSUE-1 onto the master before that feature is itself ready to be merged. If that feature is ready to be merged, then merge it first -- then your branch won't have ISSUE-1 commits that aren't also on master, there will be no difference, and ISSUE-1 won't be associated with your PR.

understood, I will try to enforce that workflow in the future... if this does come up- is there an easy way of resolving it through Stash without rebasing?

Chris Fuller Atlassian Team Jun 19, 2014

Once the merge has been introduced, the only "undo" button is either to rewrite the history of that branch or abandon it and start a new one. Within atlassian, we've adopted the convention of putting a short descriptive name after the issue, which makes this less annoying. For example:

feature/ISSUE-1-new-widget-stuff
feature/ISSUE-2-something-else

If it is only later that you realize somebody inappropriately merged ISSUE-1's work in, then you could make a new

feature/ISSUE-2-something-else-pr

You can either start from master and cherry-pick what you really need or pick across the commits that really belong or (equivalently but more easily) start from the existing ISSUE-2 branch and rebase against origin/master, dropping the merges. This has the nice side-benefit of keeping your history a bit more readable as well. Of course, this is really just a way to get away with doing a rebase without actually doing one and having to deal with the resulting chaos if other people are sharing that branch with you.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,006 views 12 18
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot