Branches: set different default destination branch (BB-10403)

Issue #9368 open
Ben Tatham
created an issue

It seems that in a given repository, there is only one "main" branch. This of course makes sense in most cases.

However, when we want to have a long running "legacy" branch, it would be nice to still be able to use gitflow on that. While Bitbucket does not support gitflow directly, it does tell you that your branch is out of sync with the repo's main branch (when looking at the /{repo name}/branch/{branch name} page).

It would be nice to be able to specify a different "main" branch for a given branch (including specifying none for the legacy "develop" branch, in gitflow parlance).

In our example, we have a regular "develop" branch (and master of course), and then the "feature/foo" branches under it.

For legacy, I created a legacy/develop, legacy/master and use standard gitflow branches under the legacy/ prefix. So in other words, I want to have no main branch for "legacy/develop" and specify the main branch on the "legacy/feature/*" branches.

Official response

  • Alastair Wilkes staff

    Thanks for your feedback on this issue! It seems there are primarily two distinct (but related) feature requests in this thread, so I will address them separately if that's OK:

    Ability to specify a destination branch for any branch, defaulting to the branch I branched from.

    We could add this capability for branches created from the UI, since there'd be a place to explicitly state the destination branch. However, we wouldn't try to automatically set the destination for branches pushed from the command line because attempting to automatically determine the destination branch solely from Git can lead to unexpected results; you'd probably have to come to the UI to set the destination for those branches. Based on the feedback on this issue, I imagine this inconsistency would be OK.

    Ability to specify a default destination branch based on patterns in the source branch name.

    This would be useful for teams using more advanced workflows. In fact, it sounds like a very similar request to #12833. Since that issue already has a decent number of votes (and could be considered a more 'advanced' feature), let's refocus this issue on "ability to specify a destination branch from the UI" and use that issue to discuss pattern matching.

    As noted, these have move up the top-voted list as a result of us shipping several other highly-voted customer features (such as #2874, #5658, #7399, and #12790). We think these are both useful features, and we are reviewing all the workflow/code review feature requests similar to this one as part of a broader scope of work, but we don't have a timeline to share right now. We'll update this issue when we are closer to working on issues like these.

Comments (125)

  1. Michael Frauenholtz staff

    Hi Ben,

    This is something that we considered when we added the branch list, but did not have time to implement. We have a ticket in our backlog for this. I don't know that we can get to it soon, but we'll let you know here when we've got more to share.

    Cheers,
    Michael

  2. Derek Price

    Yes, I think simply choosing the base branch as the default destination (instead of master) when creating pull requests would simplify things immensely for my team and help avoid a lot of human error.

    branch base.png pull destination.png

  3. Keith Starsmeare

    I'd like this option too. I'd also like it if I didn't have to google and guess to discover what happens if I change the "Main branch" in the Repository details configuration page. Please, at the very least, document the implications of changing that value!

  4. Allen Luce

    It's hard to support large-team workflows with the notion of a single main branch. It would be handy to support both a non-default upstream branch and NO main branch at all.

    I've a PR from an orphan branch targeting a new (non-main) branch on the upstream repo. The PR main view says "Nothing to merge. The source or destination branch was deleted or these changes already exist in the destination repository." This is despite the fact that the commits tab shows the work.

  5. Kyle Odell

    Totally agree here, this would be a huge improvement. Any time we have parallel projects going on, our intention is not immediately to merge to master, there is usually an epic branch with a few interrelated stories coming off of it.

    When clicking a branch from the Branches page, the diff always defaults to a comparison against master, it doesn't remember changes made to the destination dropdown.

  6. James Wallace

    I support this. Would really love the feature to let us save a bit of time when creating pull requests. Seems like it would be a relatively minor addition... but who knows.

    Anyway, would love to see it added!

  7. Steven Gosseling

    I would really like if this was implemented, this could help us to maintain the gitflow a lot easier, without constantly manually change the destination branch. Which is prone to human error...

  8. Adam Braman

    +1 definitely. Was really happy when I saw that you guys supported changing the target of a PR, something github still fails to do, but not being able to set a default branch is a greater fail.

  9. Matt McCutchen

    I filed a support request that the "change destination" link on the branch page is misleading (it looks persistent but actually only affects the current page) and was told that the misleadingness would not be addressed separately from the actual persistence requested by this issue report. Adding a comment to help the next person find this issue report.

  10. Dan Abrey

    I was totally confused by the "Change destination" link in the manner that Matt McCutchen mentions above, and came here looking for the behaviour suggested here. Big ol' +1 from me, would reduce a lot of human error.

  11. Alex Setska

    Having an option to set default destination of pull request to parent branch (instead of one branch for the entire repo) would be very much appreciated. (Derek Price's solution)

  12. Derek Price

    Yes, my team has been waiting for this for a year and a half. It seems to me like the solution I suggested above should be extremely easy to implement and it would be extremely useful to a lot of people.

  13. Glyn Jones

    This issue really complicates having feature branches off a main branch. Ideally when developing bigger features you branch off main and then do multiple branches off the feature branch with pull reqs into the feature branch. C'mon guys, get this fixed!

  14. Oliver Polden

    Yes I agree. Normal process is to branch off master, pull request into a develop or feature branch. Then once tested to merge back into master. Being unable to set the main branch separate to the default pull request branch easily means that either people branch off the wrong branch, or pull request into the wrong branch. It's a major issue that could result in code being deployed that shouldn't be.

  15. SkyKickJenkins

    We ended up re-naming our "develop" branch to "master" and our "master" branch to "develop". It's confusing for newer (and sometimes old) employees, but hey, at least you don't have to select a different destination branch!

  16. Jacob McCarthy

    It basically comes down to 'setting the default value of an input field dynamically'. Doesn't even need to do anything new besides that.

    Would love to have this. It's been 3 years though, so it's probably never going to happen.

  17. Jon Haynes

    Yes please!

    Additionally I'd ask for a mechanism in this new functionality for specifying alternative pull request destinations based on patterns in the source branch name.

    For example, teams may have BUGFIX- branches or FEATURE- branches or CI- branches which all may want different long-running branch destinations.

  18. David Hempy

    Let's all join hands, sing a happy tune and wish ISSUE 9368 a HAPPY THIRD BIRTHDAY! Clap your hands as Atlassian blows out three smoking candles on this issue. While it's been fun, and there are SO many people at this party, let's all give Bit Bucket a little nudge to fix this glaring problem so we don't have to endure a fourth year of this bug.

    Cheers!

  19. Daniel Botelho

    Wow this has been requested for so long...

    All I'm asking is just use by default my previous PR repo and branch selected. I'm working in a forked repo and usually on a dev branch, and this is so tedious and repetitive task...

    Thanks!

  20. Alastair Wilkes staff

    Thanks for your feedback on this issue! It seems there are primarily two distinct (but related) feature requests in this thread, so I will address them separately if that's OK:

    Ability to specify a destination branch for any branch, defaulting to the branch I branched from.

    We could add this capability for branches created from the UI, since there'd be a place to explicitly state the destination branch. However, we wouldn't try to automatically set the destination for branches pushed from the command line because attempting to automatically determine the destination branch solely from Git can lead to unexpected results; you'd probably have to come to the UI to set the destination for those branches. Based on the feedback on this issue, I imagine this inconsistency would be OK.

    Ability to specify a default destination branch based on patterns in the source branch name.

    This would be useful for teams using more advanced workflows. In fact, it sounds like a very similar request to #12833. Since that issue already has a decent number of votes (and could be considered a more 'advanced' feature), let's refocus this issue on "ability to specify a destination branch from the UI" and use that issue to discuss pattern matching.

    As noted, these have move up the top-voted list as a result of us shipping several other highly-voted customer features (such as #2874, #5658, #7399, and #12790). We think these are both useful features, and we are reviewing all the workflow/code review feature requests similar to this one as part of a broader scope of work, but we don't have a timeline to share right now. We'll update this issue when we are closer to working on issues like these.

  21. Derek Price

    @Alastair Wilkes, Yes, I was only asking for what you describe as the UI feature, I think. You can see my branching & pull request screen shots in a very early comment, but I was only hoping that the BitBucket Web UI could default the merge destination in both the branch view and the pull request dialog to be the branch root instead of always defaulting to "master". When you say, "you'd probably have to come to the UI to set the destination for those branches", I hope you weren't suggesting that command line git behavior might change based on new settings in the web UI - I really just want to see better defaults for the "destination" drop-down on those two pages in BitBucket's web UI to support this very common workflow. If I am merging directly from the command line or another Git client, I don't think I would want to be surprised by branch-specific configuration imposed by BitBucket.

    branch-view.png

    Looking forward to finally seeing this feature! Thanks!

  22. Alastair Wilkes staff

    When you say, "you'd probably have to come to the UI to set the destination for those branches", I hope you weren't suggesting that command line git behavior might change based on new settings in the web UI

    Good to clarify. I meant that you'll only be able to set a custom default destination branch using the UI (and it'll only apply in the UI). We're saying the same thing. :)

  23. Joshua Austill

    I think you are making this WAY too complicated! I just want to set a default branch PERIOD. It shouldn't matter what branch you are on, it shouldn't matter whether the branch was created in the UI or at the command line. Just default to the branch I say every time it refreshes instead of master. GLOBAL setting, a dropdown box that defaults to master, and allow me to type any name I want, then that one gets used.

  24. Ryan Johnson

    I disagree about a global setting being desirable. I would very much like to see the branch UI changed to match the pull request UI: a branch's merge target defaults to whatever it was branched from (or whatever the PR UI does when things are complicated/unclear), and the user can change that to whatever she wants, in a persistent way.

    A global default that overrides whatever the pull request machinery would have chosen could be a nice secondary feature if people need that, tho.

  25. Joshua Austill

    I don't disagree that the default being what it was branched from would be "better". But they've already stated that was difficult. I'm saying I want something NOW, so I'll settle for a global setting. I'll settle for a global at the team level and not even the repo level! We use the same branch names for all our projects, so that alone would cut down on SO many bad PR's on my setup already.

    If they could give me a global default tomorrow, then allow setting it by branch down the road, I'd be tickled.

  26. Ryan Johnson

    I really don't understand why it would be difficult to match the current behavior of pull requests... all it needs is to reuse the pull request machinery for deciding what the default merge target should be, to populate the (already existing) drop-down in the UI, and to persist changes to the merge target for a given branch. The latter info can't be stored in the hg repo directly, but whatever persistence mechanism pull requests use should work just fine for the web interface.

  27. Alastair Wilkes staff

    I really don't understand why it would be difficult to match the current behavior of pull requests... all it needs is to reuse the pull request machinery for deciding what the default merge target should be, to populate the (already existing) drop-down in the UI, and to persist changes to the merge target for a given branch.

    Yes, this is more-or-less what we would do. It's not a huge project, but it's not a small one either, so it remains in the backlog for the minute.

    Joshua - as Phil mentioned, there is already a repo setting for the default target branch ("Main branch"). This issue is about letting that be overridden on a per branch basis.

  28. Joshua Austill

    @Alastair Wilkes Does changing the "Main Branch" have any other effect besides setting the dropdown for a new pull request? If so then that is what I'm looking for in the immediate future. I would very much like to see it expanded to be overridden per branch though. Also, I was REALLY frustrated by the time I found this bug looking for this, if setting the "main branch" works without side effects I'd say that could be documented much better.

    Thanks for the clarification!

  29. Alastair Wilkes staff

    Sure thing! Sorry for the confusion. It'll set the default destination for pull requests, plus set that branch as

    • the default destination branch for compare views,
    • the default branch you have checked out if you clone fresh,
    • the default branch shown when you view source view, and
    • the default branch for the pipelines indicator on the repo overview page.

    Also, when you view the commit list any commits on the main branch will not have a lozenge.

    We'll take another look at the docs to make sure this is crystal clear.

  30. Joshua Austill

    @Alastair Wilkes Thanks for taking the time to spell that out for me! I apologize for coming into this conversation from a super focused kinda ignorant perspective. I think I'm starting to catch up though and see where y'all are going with this, and it's a great direction!

    After this explanation I can actually say that the answer was right in front of me the entire time, I was just confused by the "main branch" terminology. Now that I have it explained it makes total sense and seems to work great. Thank you.

  31. Szymon Stankiewicz

    Any update on this?

    BTW If you are going to implement the default destination there is one more thing that I think could be very useful. Restriction of the pull requests to the specific branches.

    For example: If you restrict pull request to the staging to accept pulls from develop branch only then when you create the pull request from the feature branch you can not even see staging in the drop-down. Only develop and other future branches. If the flow is like this" furure_branch->develop->staging->master the pull request from furure_branch to master is a mistake and there should be an option to block it.

  32. Roger Moore

    Someone previously mentioned this work around we have been using for about 2 years now and it works great!

    Re-naming "develop" branch to "master" and "master" branch to "develop" can solve this problem. It's confusing for newer employees cause you just push straight onto master but hey, at least you don't have to select a different destination branch when making a PR. We do occasionally accidentally deploy "master" (which is really develop) to production which is always fun.

  33. Derek Price

    Roger's workaround doesn't work for us. We support three releases at a time - two released maintenance branches, plus the master branch for the upcoming release. We really need bitbucket to auto-detect the branch point and suggest it as the default merge destination. We've been manually working around this for so long now that we rarely make mistakes anymore, but it's still extra clicks we need to make with every feature or bugfix branch that we view and with every pull request that we create.

  34. Sonia Cook-Broen

    Why is this so hard to implement??? The branches should default to the parent branch they were created from! I agree with Derek, if you have only one small team the convoluted master <==> dev switch workaround would be fine (I guess) but in the case that you have multiple dev. streams, no way! Please fix this Atlasssian!!

  35. Phil Rittenhouse

    I think a large part of the problem lies with Git. It simply does not provide any mechanism to track what the parent of a branch was. We have scripts that need to find a branch's parent and have yet to find a good solution. If Atlassian tries to fix this on their own by adding parent info within their database it will only work for branches created within Bitbucket. That is better than nothing, but I would like to propose another solution.
    A branch in Git is really just a pointer to a commit, like a tag. But while we have annotated tags that store lots of good meta-data, branches have none. What if we extended the annotated tag idea to branches? It seems like a natural extension to Git so hopefully not too hard to get Linus to accept it, especially if we can get Atlassian and GitHub behind it. Once we have the annotation meta-data we can store the parent branch name right in the child branch when its first created. In addition you could have the name of the user who created the branch, the date it was created etc. Just like a tag. I think this would be a great feature for both Atlassian and GitHub so hopefully they will be willing to champion it.

  36. Hunter Horsman

    One would think the 4th highest voted issue would have I higher priority than "minor" and should probably be addressed before yet another UI refresh (which seem to be quite frequent and the focus of most development).

  37. Log in to comment