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

    Hi y'all,

    Time for another update - we are still working on improving the pull request UI (which you can test out soon!). As Aneita said, this feature is not at the top of the list right now, but it may be in the future.

    There have been a few questions about this in recent comments, so I do want to restate one thing: there is already a repo setting for the default target branch ("Main branch"). So for example, most of your PRs are going to be merging into develop, we recommend changing the "Main branch" of your repo to develop.

    This issue is about letting that be overridden (or auto-detected) on a per branch basis, to enable more flexible workflows.

    Thanks,
    Alastair

Comments (191)

  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. Chris Pittillo

    Please add this! I'd also like the diff on a branch to use the base branch as the default destination (instead of master).

  4. Elliot Blackburn

    This would be great to have, it would also be good if the branch page could reflect this some how with the ahead/behind figures.

  5. 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!

  6. Elliot Blackburn

    @Keith Starsmeare I was actually thinking this as well the other day when I came to make the switch. It would be good if there was some documentation available next to the button!

  7. 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.

  8. 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.

  9. 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!

  10. Stefan Schlanderer

    HI there, is there a chance of getting this feature sometime in the near future? Would really love and need it

  11. 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...

  12. Michael Kerrigan

    +1 for myself and the 10 devs where I work. Its very common for us to have to cancel then change pull requests that are made from Master.

  13. 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.

  14. 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.

  15. 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.

  16. AlexS

    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)

  17. 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.

  18. Joshua Austill

    +4 from my team as well. Sane defaults is all we are asking for so junior devs quit accidentally pull requesting to master :(

  19. 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!

  20. 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.

  21. Doug Eveland

    You and others are emailing the wrong person. I am not associated with this project.

    Doug Eveland
    doug.eveland@gmail.com
    760-415-0105 (Cell)

  22. Brandon Patrick

    Doug, I don't think anyone is emailing you directly. You are getting emails because you are watching the issue, most likely because you voted for it at some point.

  23. Håkan Nylén

    +1 waiting too long for this - this is very important for me. I really hope this can come soon!

  24. 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!

  25. Dan Abrey

    We ended up re-naming our "develop" branch to "master" and our "master" branch to "develop".

    C'mon, Atlassian. This ain't no solution.

  26. 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.

  27. 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.

  28. Damon Muma

    Yeah this would be awesome!

    I think it would make sense if by default a branch would compare with/merge to the branch it was branched from

  29. 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!

  30. 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!

  31. 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.

  32. 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!

  33. 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. :)

  34. 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.

  35. 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.

  36. 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.

  37. 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.

  38. Phil Rittenhouse

    Joshua, don't you get what you are looking for by going to the repo settings and selecting a different branch for "Main branch"?

  39. 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.

  40. 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!

  41. 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.

  42. 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.

  43. 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.

  44. Hunter Horsman

    I would like to see Derek Price's described solution implemented, this would save myself and my team a lot of time.

  45. 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.

  46. 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.

  47. 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!!

  48. 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.

  49. Alastair Wilkes staff

    Hi Ben, this is still in the backlog - sorry, but I do not have a timeframe to share right now. This is still something we think would be useful.

  50. 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).

  51. Achin Sharma

    Count me in as well. Pulling out a branch from develop and defaulting it to merge in master is just asking for trouble.

  52. Pablo Sanchez

    So, people, just go to Repository settings and change your main branch to be develop. :-) This solves all your problems.

  53. ben@kolyanet.com

    Pablo, that doesn't work as this thread is to be able to pull from a separate branch to the one you merge into. In the branching model I use in my work, we make branches from master, but feature branches are merged into develop for QA.

  54. Eric Anderson

    For PRs, please allow for there to be a different default branch to merge to, for example DEV.

  55. Renaldas Kerpe

    +1. This would be super useful, and help avoid accidental merges to and from wrong branches.

  56. Kevin Brogan

    Throwing my +1 in there. I don't merge using bitbucket, I use sourcetree or command line git, but still. The default being master is beyond broken.

  57. Wynn Slater

    Importance level is determined by the number of votes minus the number of comments that could have just been votes.
    This issue is currently at -9000.

  58. Jacob McCarthy

    140 comments (and this 1), 379 votes, and some comments are making legitimate points.... that's some bad math there Slater.

  59. Aneita Yang staff

    Hi everyone,

    Thanks for your feedback on this ticket and continued interest in Bitbucket. We review our highest voted issues regularly.

    Given Alastair's comment, I'm going to update this ticket title and description to reflect the request to allow specifying a different default destination branch, defaulting to what you branched from. If you're more interested in the ability to specify a default destination branch based on branch patterns, I encourage you to vote for and watch issue #12833 for updates instead.

    Unfortunately, this specific request hasn't made our list of top priorities for improving workflow/code review experiences, so we don't have any plans to work on this ticket in the foreseeable future. The team is working on higher priority projects including:

    • improving the pull requests experience
    • implementing code search
    • pipelines & deployments
    • improving design and user experience.

    Please continue to follow this ticket and add comments describing any use cases that are important to your team that are not already covered above. If you are interested in seeing this functionality in Bitbucket, please make sure you vote for this issue instead of commenting "+1". We'll review this request again in a couple month's time and keep you updated on the status via this issue.

    Thanks,

    Aneita

  60. Alvaro Del Valle

    Ditto Daniel. This is probably lower on their priority because they are working on bugs in pipelines.

  61. Pablo Diaz-Gutierrez

    My team keeps forgetting to change the destination branch to 'develop' and this has caused a few bugs to be accidentally deployed to production. A simple settings switch would be so beneficial for so many users, as seen here. Preventing human error is the whole point of automation.

    I get that working on pipelines is sexier, and it probably brings in new revenue, but this the reward/cost here is so high!

  62. Phil Symonds

    When you have a project forked from another, this is a huge issue. It's very easy to accidentally merge a PR into master of the original repo.

    Given a priority to "improving user experience", I'd say this ranks pretty high - it's a daily poor (and dangerous) user experience for us. Add fancy stuff when the basics are nailed.

  63. Leo Lei

    We rely on "master" as our CI branch, and therefore merging into there by accident can have real & fatal consequences.

    CI has become main stream nowadays, and thus this issue has probably become more significant than in the past. I'm not sure if it's still correct to prioritize it as "minor" since the significance of the issue has changed.

  64. Daniel Botelho

    This feature can be fixed with only frontend code, just remember last user selection! You'r making it hard to enforce best practices in my company...

  65. smws

    Your company is committed to use in the enterprise field. I think that if that is the case, you should consider the actual situation of organizations that are involved in complex branch operations.

    20180328-mercurial-1-.png
    20180328-TortoiseHg-1-.png

  66. Shawn Talbot

    While I appreciate the work that has gone into the Pull Request experience...This feature is long overdue. This would go a LONG way to reducing development friction (including accidental targets to the wrong repository since you do not support detaching forks and cannot re-target the repository).

  67. Alastair Wilkes staff

    Hi y'all,

    Time for another update - we are still working on improving the pull request UI (which you can test out soon!). As Aneita said, this feature is not at the top of the list right now, but it may be in the future.

    There have been a few questions about this in recent comments, so I do want to restate one thing: there is already a repo setting for the default target branch ("Main branch"). So for example, most of your PRs are going to be merging into develop, we recommend changing the "Main branch" of your repo to develop.

    This issue is about letting that be overridden (or auto-detected) on a per branch basis, to enable more flexible workflows.

    Thanks,
    Alastair

  68. Jason Weakley

    Why would the "main" branch be called "develop"? We follow Driessen's "A Successful Git Branching Model" and calling it develop would be extremely confusing. We've put legacy apps in a different repo, but could and would probably like to have a "Legacy" branch, with a master for the newer branch, and dev, stage, prod branches to match up with our dev, stage, and prod servers.

  69. Jacob McCarthy

    @Aneita Yang and @Alistar, I don't believe I understand. when you say
    " [...] The team is working on higher priority projects including:

    • improving the pull requests experience
    • improving design and user experience.

    How is it that this topic can be omitted from one or both of these 'high priority' topics?

    Also we forgot this issues fourth birthday. We're all bad parents.

  70. Marat Giliazov

    +1, would be handy to have default branch for PR configurable and being not the same as repo's def branch.

  71. Data Mafia

    For 4 year old issue of required parity with a leading competitor where the lack of feature is causing time and money to be lost for dev teams shows a tone deafness underscoring why my only use of Atlassian products because of existing client dependencies. My experience in the Atlassian suite for over a decade is exemplified by threads such as this one. I am in a bind currently where this EXACT setting just cost hundreds of dollars for a team who is accustomed to GitHub's "pro-developer" operation. Considering recent ownership changes at GitHub it would only make sense to be sensitive to issues of this nature to onboard people departing because of Microsoft ownership. But alas, Atlassian again shows a commitment to the ecosystem best described as ignorant and offensive. I am closing in on 20 years in development personally and I am repeatedly shocked at the poor quality put forward. As a successful business man once said to me "the people who walk away quietly do the most damage to your business".

  72. Dan Abrey

    This issue predates me becoming a full-time developer. It will be a strange day when it's finally resolved, it feels like a child to me at this point.

  73. Daniel Delaney

    Our repository started as a fork of a repo, but has never needed to merge anything back into the original repo, as it was just a template. Now every time I go to create a new pull request, it defaults to updating the original repo, and practically breaks the page every time because there are too many changes for it to compute.

    Please fix this!

  74. John Szakmeister

    I'd like to echo my support for the ability to set a default branch for pull requests separate than the default branch of the Git repo too.

  75. Richard Chen

    Or save the "branch from" option in each branch. Don't let this request slide, it'll saves so many users so much time & frustration.

  76. Robert Gonzalez

    Can we just get access to the post-receive hook to generate the url ourselves? When you 'push' you get back a URL to create the PR. In the URL if you set the GET parameter 'dest' with your desired destination branch it already works. We just need to be able to modify how that url is generated. I can't find a way to do that anywhere.

  77. Julian Depetris Chauvin

    +1. When creating Pull Request, default target branch should be the one the new branch was branched off.

  78. Daniel Delaney

    The branching model stuff is great, and that helps when creating a pull request directly from a branch, but there’s still the issue of the underlying main branch & repository.

    When I go to the Pull Requests page and click the “Create pull request” button on the top right corner, it defaults to the master branch of the repository I originally forked. I forked a base template of my framework setup and have no intention of ever merging these new changes back into it, because this is a completely separate project. Image attached for reference. When this starts loading the diff/commits for the PR by default, it ends up breaking/crashing the page because it’s trying to compare way too many changes. Any fixes coming for this ever?

  79. Ryan Tanay

    At least for cloud, you can put in a support request and they can re-point the default PR target. We eventually had to do that for our app as the same thing was happening, the giant unneeded diff was crashing the page.

    This could and should still be changed to be user configurable, at the very least retaining the last-selected target in the UI.

  80. Evgeny Morozov

    It’s not enough to set one default branch. I want the target branch to be, by default, the one from which the source branch was branched. The use case is that we have release branches (v1.1, v1.2, etc.) and to make a hotfix we create feature branches off those. We then want those to be merged back into the release branch from which they were created.

  81. Vinicius Totti

    Hi @Daniel Delaney,

    In the same page, Branching model, in the top of the page, you can select the Development branch and Production branch.

    I set up Developement brach as Develop and Production branch as Master an it works for me.

    After creating PR from a feature branch, it’s selecting auto the Dev branch.

  82. Daniel Delaney

    Right, that works if you come from the Feature Branch page, but I’m talking about the Pull Request page

  83. Dave DeCaprio

    If you email Bitbucket support they will happily change the base repo for you. They usually have done it for me in a few hours.

    Dave

  84. Yonatan Miller

    I came here to support @Matt McCutchen with exact same issue. This made me waste time looking for the PR, because depending on source destination the associated PR will show.

    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.

  85. Log in to comment