Pull Request Links Too Many Issues

[Mike Kessler]

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?

[crf · Accepted solution]

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.

[crf]

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.

[Mike Kessler]

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?

[crf]

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.