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 vote
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:


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


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
Alexey Matveev
Published Saturday in Jira

How to run Jira in a docker container

Everything below is tested on Ubuntu 17.10. I prefer to use Jira in a docker container because: 1. I can install Jira with a couple of commands. 2. I can start and stop Jira just by starting and s...

118 views 2 5
Read article

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