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
Accepted answer
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 Sign up to answer
Community showcase
Published Feb 13, 2019 in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

697 views 0 12
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