1

I have a remote origin repository with three branches, a master and two alternatives. Both alternatives are ahead of the master by several hundred commits.

What I'd like to do is to effectively make one of the alternatives, "alternative1", the new "master", like in this question.

Currently, my local repo is on branch "alternative1." When I'm done, I'd like my local repo to be on branch "master", and I'd like branch "master" to be equivalent to the latest commit to branch "alternative1".

I follow the accepted solution to the duplicate problem I linked. But what I don't fully grasp are what the ramifications of this operation mean for my local repo vs the remote repo. When I've done the merge via the ours strategy as shown in that solution, if another random person decides to go grab origin/master from the remote repo, will they also receive the code corresponding to the last commit I pushed to "alternative1" before the merge? Or do I have to somehow re-push the new master?

Furthermore, is this something that can be accomplished through BitBucket's in-browser merge feature?

Community
  • 1
  • 1
msolters
  • 225
  • 2
  • 8

1 Answers1

1

If you did a "normal" merge (i.e. created a new merge commit, or fast-forwarded – as compared to a reset --hard/branch -f), there should not be any problems.

Anyone who will fetch from your repository will receive the latest source code as is contained in your version of the branch (given that you have pushed all branches which you want to update).

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Thanks! Back then, the two core concept I was missing about branch merging in GIT seemed to be: 1. Merges can happen locally or remotely, but will not affect each other until the changes are pushed/pulled (respectively). 2. That the destination branch in a merge is changed while the actual branch being merged remains as it was. – msolters Jul 06 '15 at 09:54