(SourceTree) How to abandon branches without detaching head

[Ryan Neve]

Before I ask the SourceTree question, I have almost no knowledge of command line git usage although I can use SCCS.

The problem I keep running in to is I get to a point where my code is messed up that I just want to go back to the last good commit and start over. I might look at the abandoned code and copy and paste in the good bits later. What I usually do is click on the last good commit and pull it. This creates a detached head. To re-attach, I tag it (e.g. temp7) at which point I can now commit again.

This is obviously the wrong way to do it as I've long ago left tags: origin, master, temp, temp1, temp2, temp3 etc in the dust.

I just want my current commit to be the master. No merging, no reconciling, just take the current version and make it the origin/master or whatever it should be.

I'd read the SourceTree help but apparently there isn't any.

[Balázs Szakmáry · Accepted solution]

What you need is the reset option (soft if you want to keep the files). Right-click on the last good commit, it is in the context menu.

[Tim Crall]

This is correct. But better yet would be to start a new branch each time you're working a new feature. Then you can literally just abandon that branch if it doesn't work out. If it does work out, merge it back into master and start a new branch for the next feature.

[Tim Crall]

Also, you need to distinguish between 'origin' and 'master'. 'origin' refers to the remote server that you originally cloned the repo from (and presumably where you push your updates back to). It is a remote, not a branch. 'origin/master' refers to the master branch on that server (as opposed to your local master branch, which is just 'master')

[Ryan Neve]

So how do I make my current head the master? Currently master is on an abandoned fork.

[Tim Crall]

At the end of the day, "master" is just a branch, which is just a pointer to a commit. You could delete it and then create it where you want it. If the abandoned fork it's currently pointing to is something you ever want to be able to visit again, be sure to tag it or create a new branch for it. And if there are copies of this repo on a remote you'll have to do a "push -f" and if anyone else has a clone of it, you should probably think twice about doing this, as it's a radical rewrite of history. You might also be able to do a merge with a strategy that would merge the two branches but completely in favor of the branch you actually want. I'd have to experiment with this.

[Tim Crall]

Even easier than deleting and recreating the master branch, you can do a git reset --hard <commitID> to move HEAD and master both to point to the commit you like. This has all the above problems with changing history, though. Doing it with a merge while getting only changes from the new branch and none of the changes from the abandoned master branch doesn't appear to be trivial, but would do a better job of preserving history. This thread discusses this: http://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours

[Tim Crall]

I just tested the answer on that thread by Paul Pladijs (it's the number two answer) and it worked perfectly for what I think you want to do. The number 1 accepted answer there doesn't work in this scenario because it will preserve nonconflicting changes from the abandoned master branch.