views:

106

answers:

3

Hi, I have a newbie question about Git:

I need to move back and forth in a history of a branch. That means, I need to get all the files to the state they were in in some old revision, and then I need to get back to the latest state in the repository. I don't need to commit.

With SVN, it would be

svn up -r800

to get to revision 800, and

svn up

to get in sync with the repository.

I know the hash of the commit I want to get back to, so I tried

git reset <hash>

which seems to get me there. But then I tried

git pull

but that complains about conflicts.

So what's the proper way to move through the history of the branch?

I'm thinking in terms of SVN, so don't hezitate to point me to some nice tutorial. Note that I've already checked http://git.or.cz/course/svn.html and http://www.youtube.com/watch?v=8dhZ9BXQgc4 .

Thanks, Ondra.

+5  A: 

You can use git checkout to checkout any commit and then use it with a branch name to go back to a named branch.

git checkout with a commit id and not a branch name moves you off any named branch and on to what is known as a detached head.

If you use git reset then it will move your branch itself back to an old state, orphaning the more recent commits which probably isn't what you want.

Charles Bailey
What the `checkout` really does? Does it change the files to the state of the given commit, by reversly applying the patches of the commits between current state and the given commit's state?
Ondra Žižka
I've found `git reset` and `git reset origin`. I will not do any commits, so it does not matter whether I loose the recent commits as far as it's easily recoverable (which means, by a single command).
Ondra Žižka
git checkout don't make the change permanent. To do it, use git merge. See my answers.
Donny Kurnia
checkout reset's the index/cache/staging area to the tree designated by the given commit and then updates the working tree to match the cache. It doesn't need to do any patch re-applying; it just uses the tree as at the given commit. (It also has error checking and updates the checked out branch if you pass it a branch name.)
Charles Bailey
+4  A: 

Well, I'm a former svn user too, and now use git for all my projects.

When using git, you should change the way of thinking from client-server architecture that used in svn. In svn, every change need connection with server. Using git, your repo is in the working directory. You don't need connection to every repo action.

Only use git push and git pull to synchronize between repo. Think of it like using rsync or any backup solution, to make two place have exactly same content. Just like you connect external backup harddisk, then make the content in it same with the content in your main. That's the usage of git pull and git push.

If you just want to go back and forth the history, do it using git checkout. See the revision id using git pull. If you using linux, use gitk to see the revision tree. In windows, tortoise git can display it using revision graph.

To get back to latest revision, use git checkout master. Before doing any command, make yourself always do git status. This command will display anything you need to know about current repo condition, and what action that you need to do to make it right. Before do git pull and git push, it's better to make sure that git status result is contain text working directory clean.

If you need to revert a file to it's previous revision, you can do it with git merge. Before doing it to file, test it first with git diff. Ex: git diff rev1:rev2 filename. It will print out any different between two revision. Change in rev1 will replaced by change in rev2. So to do revert, rev2 will be the older than rev1. After you satisfy with the diff result, do it with git merge, just replace diff with merge, all other parameter stay the same.

I hope this help you. The main key is to see that your work dir is your repo. Understand this will make you can use git to it's full capability. Good luck.

Donny Kurnia
Excellent! Thanks ( to both ).
Ondra Žižka
A: 

To checkout a different version of a file, use

git checkout rev -- filename

Where rev can be the ID of a commit, the name of a branch, the name of a tag, or a relative version.

Use git log, gitk to look examine versions to see which version of the file you want.

To make this version of the file permanent, you need to commit the file: git add filename; git commit filename

I would not recommend git pull to examine versions because it does a merge -- potentially modifying your current state.

You do not need to use git reset in this case, unless you git add a file you decide not to commit.

Jamey Hicks