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.
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')
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.
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
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.
Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG