1

I am using git (from visual studio but I don't think that is that relevant) and I have come to have the following situation

My current git history now

As you can see there are four branches (BX) and several other commits in between. Also the master branch (M) -which is in red.

Well, due to my inexperience, I have gotten into the situation that the stable version of my program is in B3. I made some experimentation in B4 but I think that I will discard it. -I know how to do it, no problem there.

However- the master branch is in a completely different direction. The two commits toward it have things that I don't care about and that I absolutely don't want in my already working program.

So my question is - since "master" is supposed to be the stable release- how do I make master point to where B3 is???

This must be a really basic question but I trust in the advice of experienced people

Maroun
  • 94,125
  • 30
  • 188
  • 241
KansaiRobot
  • 7,564
  • 11
  • 71
  • 150

2 Answers2

1

One potential solution (if these are all local feature branches you have created) is to do the following:

  1. git branch -d B4
  2. git checkout master
  3. git reset --hard <SHA of B2's commit you want>
  4. git checkout B3
  5. git rebase B3 master

This will delete branch B4, remove the commits from master that you do not want, and then replay all the commits from the B3 branch that you want onto the head of master. Keep in mind you may need to resolve some conflicts during the rebase. When you finish resolving them, run git rebase --continue.

lolsky
  • 428
  • 2
  • 14
  • Sorry but don't understand. I mean, yes 1 is deleting B4 and then you go to master. Then (3) the master will point at B2. But after that, why 4 and 5?? I mean B3 would be already ON master (which is B2) so why do I need to rebase it?? why not just a fast forward merge?? – KansaiRobot Nov 18 '16 at 01:16
  • You're absolutely right. A fast-forward merge would provide the same result as a rebase, without the need to create additional commits. – lolsky Nov 18 '16 at 02:31
  • Thanks. One more question. When in 3) I make the master point to B2, what happens to the commits that previously went to master? are they erased? – KansaiRobot Nov 18 '16 at 05:51
  • Git uses a garbage collector that will eventually erase those commits, but typically they will stick around for a couple weeks. If you need to get them back and the garbage collector hasn't removed them yet, you can use `git reflog` to find out when the ref changed for master and use `git reset --hard ` to bring master back to its original state before (3). – lolsky Nov 18 '16 at 06:39
  • Also, check out [this](https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1) answer for a more in depth explanation of how to get commit changes back after a `git reset --hard`. – lolsky Nov 18 '16 at 06:40
1

The simplest thing to do is

git branch -f master B3
git checkout master

This abandons the old master and moves it to B3.

j6t
  • 9,150
  • 1
  • 15
  • 35
  • Thank you. Not that I really care much for the commits of the old master but just to learn git theory... if I execute your commands, are the old master commits lost forever? – KansaiRobot Nov 16 '16 at 00:29
  • @KansaiRobot They are not lost immediately, but they will be garbage-collected after some time, typically 2 weeks. Then they are gone forever. Until then, you can recover them with [various tools](http://stackoverflow.com/questions/10099258/how-can-i-recover-a-lost-commit-in-git). – j6t Nov 16 '16 at 07:48
  • Thanks. But what if there is a Tag in master, and then execute `git branch -f master B3`? in that case, will the commits stay? or are they erased? – KansaiRobot Nov 18 '16 at 05:52
  • @KansaiRobot When there is a tag that points at the old master, that commit is protected and will not be lost. – j6t Nov 18 '16 at 11:36