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?
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.
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.
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.
We're looking for participants for a workshop at Atlassian! We need Jira admins who have interesting custom workflows, issue views, or boards. Think you have a story to sha...
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!
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