tags:

views:

64

answers:

3

I'm using Git for my personal projects with a remote repository hosted in assembla.com. I'm used to a simple svn-like workflow, but now I'm trying to do something that (I think) should be relatively simple but the git documentation has not helped me achieve it so far.

This is the situation. I made a bunch of changes in my local master branch, and committed them. Now I realize that my changes are not absolutely necessary and rather detrimental to performance, but may be useful/necessary in the future. So I want to revert the previous state, while somehow keeping these changes stored somewhere. Of course, git reset --hard won't do because it will erase my changes permanently.

I'm not sure this is the correct solution, but I'm thinking of making a branch with these changes, but I can't quite figure out the correct sequence of commands to do so. Note that I want to keep track of these changes in the remote repository, not just my local repository, since I work from different computers.

I'll be grateful for any ideas on how to do this, whether they involve remote branches or not.

+2  A: 

You want to create a branch at your current HEAD:

git branch possibly-useful-stuff

and then reset your master branch back to where it belongs, probably one of these:

git reset --hard origin/master  # the remote branch
git reset --hard master~<n>     # n commits before master
git reset --hard <hash>         # a specific commit

To keep track of them in the remote, you'll just need to push this branch to the remote:

git push <remote> possibly-useful-stuff
Jefromi
Thanks for the answer, this worked.
dimatura
+1  A: 

The simplest thing to is to make a new branch containing your current state. You can then push that to the remote master and reset your master branch back to position of the remote master.

E.g.

git branch side-lined

git push origin side-lined

git reset --hard origin/master
Charles Bailey
A: 

I don't now git specifically, but I use Mercurial. If I ran in to this situation with Mercurial, I'd commit it marking it as a branch (somehow, someway) and then check out the revision desired.

On my next commit, Mercurial would create a new head revision. I know this is general, but I had the idea so I shared it.

Git and Mercurial are similar so I think the ideas should work for you... (Please Note there are terminology differences and I may not be using the right terms)

Note: It appears that others have since posted git specific directions doing sort of what I was describing.

Frank V
Why would you post a general answer when there are already three duplicate answers with the specifics?
Jefromi
I was writing and didn't see them come up. Besides that, I feel giving the general idea of what to do would be more productive then to give the exact commands.
Frank V
All right, sorry, I thought it'd been a bit longer since the original answers. The general idea is good, though it's a little dangerous to mix mercurial and git when giving beginner advice, since there are variations in terminology. In this case, there's only one HEAD in a git repository (it points to the current branch), and you straight-up create branches (not mark commits as branches).
Jefromi
Your point of terminology differences is well received. I'll exercise more caution in mixing the two in the future. For the meanwhile, the note saying there are git specific directions should suffice. I think the answer is "right" enough to provide an additional perspective and hence, to not delete.
Frank V