-
Suggestion
-
Resolution: Unresolved
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.
- is related to
-
- Closed
-
- Under Consideration
- mentioned in
-
Page Failed to load
[BCLOUD-9368] Branches: set different default destination branch (BB-10403)
Attachment 1198483264-Screen%20Shot%202019-04-30%20at%2010.32.28%20AM.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
Attachment 562409127-branch-view.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
Attachment 1289014065-pull%20destination.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
Attachment 918744398-branch%20base.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
Attachment 2149422320-20180328-TortoiseHg-1-.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
Attachment 1891202837-20180328-mercurial-1-.png has been added with description: Originally embedded in Bitbucket issue #9368 in site/master
I came here to support @mattmccutchen 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.
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
Right, that works if you come from the Feature Branch page, but I’m talking about the Pull Request page
Hi @dandelaney8,
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.
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.
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.
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?
Hey guys,
It was already implemented.
You can see here
https://bitbucket.org/blog/introducing-bitbucket-branching-model-support
Here it’s possible to configure it. We’re using right now in the company.
+1. When creating Pull Request, default target branch should be the one the new branch was branched off.
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.
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.
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.
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!
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.
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".
+1, would be handy to have default branch for PR configurable and being not the same as repo's def branch.
@aneita 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.
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.
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
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).
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.
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...
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.
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.
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!
Ditto Daniel. This is probably lower on their priority because they are working on bugs in pipelines.
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 BCLOUD-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
140 comments (and this 1), 379 votes, and some comments are making legitimate points.... that's some bad math there 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.
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.
The defect is a major issue. Please, update the priority accordingly. Thank you!
+1. This would be super useful, and help avoid accidental merges to and from wrong branches.
+1. this is really annoying. I hate to merge to master instead of develop branch by accident.
For PRs, please allow for there to be a different default branch to merge to, for example DEV.
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.
So, people, just go to Repository settings and change your main branch to be develop. 
This solves all your problems.
Count me in as well. Pulling out a branch from develop and defaulting it to merge in master is just asking for trouble.
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).
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.
I would also love this feature, as we work with a continuous development model which branches off master and back into develop. Any update @awbb? Thanks!
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.
+1