0

I have an issue with merging and branching changes to BitBucket repos using Visual Studio 2017.

After a quick search I came across this post here.

However my situation is slightly different from the one encountered in the aforementioned post.

I have a branch (lets call V1.0) which was released. From there I used the New branch from local... option in Visual Studio 2017 which created V2.0.

I did this thinking they would be completely separate when it came to pushing changes on each respective branch however V2.0 is now listed in VS as V2.0 origin/V1.0.

I wanted to be able to switch between the branch making changes where necessary however if I make a change on V2.0 and then try to push, I get the error -

Error encountered while pushing to the remote repository: rejected Updates were rejected because a pushed branch tip is behind its remote counterpart. Check out this branch and integrate the remote changes before pushing again.

Essentially what I want is to have 2 completely separate branches now that are unaffiliated, is there a way I can dethatch V2.0 from V1.0 so there is no origin association.

I looked at the rebase option but this meant that everything that is different with V1.0 was getting pulled down and merged into V2.0 which is exactly NOT what I wanted.

Ebikeneser
  • 2,582
  • 13
  • 57
  • 111

1 Answers1

0

You could try to set the upstream branch to v2.0.

git push -u origin V2.0
ExoticAvocado
  • 32
  • 1
  • 3
  • hmm, that might work, any idea how to do that in VS 2017? – Ebikeneser Jul 29 '21 at 14:00
  • I agree with this. You (the OP) say push but you did not show what command you used. You need to set the upstream for your new branch. And you need to use the command line, I'd say, and stop relying on an inadequate and tricky GUI. – matt Jul 29 '21 at 14:01
  • Good reply. I agree with you. – ExoticAvocado Jul 29 '21 at 16:15
  • @Ebikeneser, you might want to look here for a way to do it in visual studio for now. I would still recommend you familiarize yourself with the command line version of git because it is much more versatile (even if it doesn't come with the pretty commit timelines :P). – ExoticAvocado Jul 29 '21 at 17:08
  • ok, thanks for input i will give this a go and get back to you. – Ebikeneser Jul 30 '21 at 08:26