I have made some changes to a file which has been committed a few times as part of a group of files, but now want to reset/revert the changes on it back to a previous version.
I have done a git log along with a git diff to find the revision I need, but just have no idea how to get the file back to its former state in the past.
This question is related to
git
version-control
git-checkout
The answer is
git revert <hash>
Will revert a given commit. It sounds like you think git revert only affects the most recent commit.
That doesn't solve your problem, if you want to revert a change in a specific file and that commit changed more than that file.
I have to plug EasyGit here, which is a wrapper to make git more approachable to novices without confusing seasoned users. One of the things it does is give more meanings to git revert. In this case, you would simply say:
eg revert foo/bar foo/baz
Amusingly, git checkout foo will not work if the working copy is in a directory named foo; however, both git checkout HEAD foo and git checkout ./foo will:
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
If you know how many commits you need to go back, you can use:
git checkout master~5 image.png
This assumes that you're on the master branch, and the version you want is 5 commits back.
- Git revert file to a specific commit
git checkout Last_Stable_commit_Number -- fileName
2.Git revert file to a specific branch
git checkout branchName_Which_Has_stable_Commit fileName
git-aliases, awk and shell-functions to the rescue!
git prevision <N> <filename>
where <N> is the number of revisions of the file to rollback for file <filename>.
For example, to checkout the immediate previous revision of a single file x/y/z.c, run
git prevision -1 x/y/z.c
How git prevision works?
Add the following to your gitconfig
[alias]
prevision = "!f() { git checkout `git log --oneline $2 | awk -v commit="$1" 'FNR == -commit+1 {print $1}'` $2;} ;f"
The command basically
- performs a
git logon the specified file and- picks the appropriate commit-id in the history of the file and
- executes a
git checkoutto the commit-id for the specified file.
Essentially, all that one would manually do in this situation,
wrapped-up in one beautiful, efficient git-alias - git-prevision
Use git log to obtain the hash key for specific version and then use git checkout <hashkey>
Note: Do not forget to type the hash before the last one. Last hash points your current position (HEAD) and changes nothing.
You have to be careful when you say "rollback". If you used to have one version of a file in commit $A, and then later made two changes in two separate commits $B and $C (so what you are seeing is the third iteration of the file), and if you say "I want to roll back to the first one", do you really mean it?
If you want to get rid of the changes both the second and the third iteration, it is very simple:
$ git checkout $A file
and then you commit the result. The command asks "I want to check out the file from the state recorded by the commit $A".
On the other hand, what you meant is to get rid of the change the second iteration (i.e. commit $B) brought in, while keeping what commit $C did to the file, you would want to revert $B
$ git revert $B
Note that whoever created commit $B may not have been very disciplined and may have committed totally unrelated change in the same commit, and this revert may touch files other than file you see offending changes, so you may want to check the result carefully after doing so.
You can use any reference to a git commit, including the SHA-1 if that's most convenient. The point is that the command looks like this:
git checkout [commit-ref] -- [filename]
Obviously someone either needs to write an intelligible book on git, or git needs to be better explained in the documentation. Faced with this same problem I guessed that
cd <working copy>
git revert master
would undo the last commit which is seemed to do.
Ian
In the case that you want to revert a file to a previous commit (and the file you want to revert already committed) you can use
git checkout HEAD^1 path/to/file
or
git checkout HEAD~1 path/to/file
Then just stage and commit the "new" version.
Armed with the knowledge that a commit can have two parents in the case of a merge, you should know that HEAD^1 is the first parent and HEAD~1 is the second parent.
Either will work if there is only one parent in the tree.
I think I've found it....from http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Sometimes you just want to go back and forget about every change past a certain point because they're all wrong.
Start with:
$ git log
which shows you a list of recent commits, and their SHA1 hashes.
Next, type:
$ git reset --hard SHA1_HASH
to restore the state to a given commit and erase all newer commits from the record permanently.
if you commit a wrong file in your last commits follow the instruction :
- open source tree, change to this commit
- change the lines and find your commit that the wrong file sent as commit
- you can see the list of your changes in that commit
- select it and then click on ... buttons right-hand side ... click reverse file
- then you can see it on file status tab at the bottom left-hand side then click unstage:
- open your visual studio code and revert back by committing your removed files
- after them all, you can see results in your last commit in the source tree
In order to go to a previous commit version of the file, get the commit number, say eb917a1 then
git checkout eb917a1 YourFileName
If you just need to go back to the last commited version
git reset HEAD YourFileName
git checkout YourFileName
This will simply take you to the last committed state of the file
Amusingly, git checkout foo will not work if the working copy is in a directory named foo; however, both git checkout HEAD foo and git checkout ./foo will:
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
- Git revert file to a specific commit
git checkout Last_Stable_commit_Number -- fileName
2.Git revert file to a specific branch
git checkout branchName_Which_Has_stable_Commit fileName
First Reset Head For Target File
git reset HEAD path_to_file
Second Checkout That File
git checkout -- path_to_file
I have to plug EasyGit here, which is a wrapper to make git more approachable to novices without confusing seasoned users. One of the things it does is give more meanings to git revert. In this case, you would simply say:
eg revert foo/bar foo/baz
And to revert to last committed version, which is most frequently needed, you can use this simpler command.
git checkout HEAD file/to/restore
This is a very simple step. Checkout file to the commit id we want, here one commit id before, and then just git commit amend and we are done.
# git checkout <previous commit_id> <file_name>
# git commit --amend
This is very handy. If we want to bring any file to any prior commit id at the top of commit, we can easily do.
Here is my way.
a) In Android Studio, open the file.
b) git -> Show History, find the previous commit I want to revert to. Get the commit_id (i.e. commit hash).
c) git checkout commit_id file_path
If you're using Git Extensions and you only want to revert to the parent commit for the file, you can select the commit that contains the changes you want to revert, then select the 'Diff' tab in the details pane, right-click the file you want to revert, then 'Reset file(s) to' ...., then 'A' (the parent)
Many answers here claims to use git reset ... <file> or git checkout ... <file> but by doing so, you will loose every modifications on <file> committed after the commit you want to revert.
If you want to revert changes from one commit on a single file only, just as git revert would do but only for one file (or say a subset of the commit files), I suggest to use both git diff and git apply like that (with <sha> = the hash of the commit you want to revert) :
git diff <sha>^ <sha> path/to/file.ext | git apply -R
Basically, it will first generate a patch corresponding to the changes you want to revert, and then reverse-apply the patch to drop those changes.
Of course, it shall not work if reverted lines had been modified by any commit between <sha1> and HEAD (conflict).
if you commit a wrong file in your last commits follow the instruction :
- open source tree, change to this commit
- change the lines and find your commit that the wrong file sent as commit
- you can see the list of your changes in that commit
- select it and then click on ... buttons right-hand side ... click reverse file
- then you can see it on file status tab at the bottom left-hand side then click unstage:
- open your visual studio code and revert back by committing your removed files
- after them all, you can see results in your last commit in the source tree
In order to go to a previous commit version of the file, get the commit number, say eb917a1 then
git checkout eb917a1 YourFileName
If you just need to go back to the last commited version
git reset HEAD YourFileName
git checkout YourFileName
This will simply take you to the last committed state of the file
You can quickly review the changes made to a file using the diff command:
git diff <commit hash> <filename>
Then to revert a specific file to that commit use the reset command:
git reset <commit hash> <filename>
You may need to use the --hard option if you have local modifications.
A good workflow for managaging waypoints is to use tags to cleanly mark points in your timeline. I can't quite understand your last sentence but what you may want is diverge a branch from a previous point in time. To do this, use the handy checkout command:
git checkout <commit hash>
git checkout -b <new branch name>
You can then rebase that against your mainline when you are ready to merge those changes:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
Note, however, that git checkout ./foo and git checkout HEAD ./foo
are not exactly the same thing; case in point:
$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(The second add stages the file in the index, but it does not get
committed.)
Git checkout ./foo means revert path ./foo from the index;
adding HEAD instructs Git to revert that path in the index to its
HEAD revision before doing so.
I think I've found it....from http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Sometimes you just want to go back and forget about every change past a certain point because they're all wrong.
Start with:
$ git log
which shows you a list of recent commits, and their SHA1 hashes.
Next, type:
$ git reset --hard SHA1_HASH
to restore the state to a given commit and erase all newer commits from the record permanently.
git checkout ref|commitHash -- filePath
e.g.
git checkout HEAD~5 -- foo.bar
or
git checkout 048ee28 -- foo.bar
You can quickly review the changes made to a file using the diff command:
git diff <commit hash> <filename>
Then to revert a specific file to that commit use the reset command:
git reset <commit hash> <filename>
You may need to use the --hard option if you have local modifications.
A good workflow for managaging waypoints is to use tags to cleanly mark points in your timeline. I can't quite understand your last sentence but what you may want is diverge a branch from a previous point in time. To do this, use the handy checkout command:
git checkout <commit hash>
git checkout -b <new branch name>
You can then rebase that against your mainline when you are ready to merge those changes:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
In the case that you want to revert a file to a previous commit (and the file you want to revert already committed) you can use
git checkout HEAD^1 path/to/file
or
git checkout HEAD~1 path/to/file
Then just stage and commit the "new" version.
Armed with the knowledge that a commit can have two parents in the case of a merge, you should know that HEAD^1 is the first parent and HEAD~1 is the second parent.
Either will work if there is only one parent in the tree.
You have to be careful when you say "rollback". If you used to have one version of a file in commit $A, and then later made two changes in two separate commits $B and $C (so what you are seeing is the third iteration of the file), and if you say "I want to roll back to the first one", do you really mean it?
If you want to get rid of the changes both the second and the third iteration, it is very simple:
$ git checkout $A file
and then you commit the result. The command asks "I want to check out the file from the state recorded by the commit $A".
On the other hand, what you meant is to get rid of the change the second iteration (i.e. commit $B) brought in, while keeping what commit $C did to the file, you would want to revert $B
$ git revert $B
Note that whoever created commit $B may not have been very disciplined and may have committed totally unrelated change in the same commit, and this revert may touch files other than file you see offending changes, so you may want to check the result carefully after doing so.
Use git log to obtain the hash key for specific version and then use git checkout <hashkey>
Note: Do not forget to type the hash before the last one. Last hash points your current position (HEAD) and changes nothing.
Here's how rebase works:
git checkout <my branch> git rebase master git checkout master git merge <my branch>
Assume you have
---o----o----o----o master \---A----B <my branch>
The first two commands ... commit git checkout git rebase master
... check out the branch of changes you want to apply to the master branch. The rebase command takes the commits from <my branch> (that are not found in master) and reapplies them to the head of master. In other words, the parent of the first commit in <my branch> is no longer a previous commit in the master history, but the current head of master. The two commands are the same as:
git rebase master <my branch>
It might be easier to remember this command as both the "base" and "modify" branches are explicit.
. The final history result is:
---o----o----o----o master \----A'----B' <my branch>
The final two commands ...
git checkout master
git merge <my branch>
... do a fast-forward merge to apply all <my branch> changes onto master. Without this step, the rebase commit does not get added to master. The final result is:
---o----o----o----o----A'----B' master, <my branch>
master and <my branch> both reference B'. Also, from this point it is safe to delete the <my branch> reference.
git branch -d <my branch>
Note, however, that git checkout ./foo and git checkout HEAD ./foo
are not exactly the same thing; case in point:
$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(The second add stages the file in the index, but it does not get
committed.)
Git checkout ./foo means revert path ./foo from the index;
adding HEAD instructs Git to revert that path in the index to its
HEAD revision before doing so.
git checkout ref|commitHash -- filePath
e.g.
git checkout HEAD~5 -- foo.bar
or
git checkout 048ee28 -- foo.bar
git revert <hash>
Will revert a given commit. It sounds like you think git revert only affects the most recent commit.
That doesn't solve your problem, if you want to revert a change in a specific file and that commit changed more than that file.
I have to plug EasyGit here, which is a wrapper to make git more approachable to novices without confusing seasoned users. One of the things it does is give more meanings to git revert. In this case, you would simply say:
eg revert foo/bar foo/baz
Note, however, that git checkout ./foo and git checkout HEAD ./foo
are not exactly the same thing; case in point:
$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(The second add stages the file in the index, but it does not get
committed.)
Git checkout ./foo means revert path ./foo from the index;
adding HEAD instructs Git to revert that path in the index to its
HEAD revision before doing so.
You can quickly review the changes made to a file using the diff command:
git diff <commit hash> <filename>
Then to revert a specific file to that commit use the reset command:
git reset <commit hash> <filename>
You may need to use the --hard option if you have local modifications.
A good workflow for managaging waypoints is to use tags to cleanly mark points in your timeline. I can't quite understand your last sentence but what you may want is diverge a branch from a previous point in time. To do this, use the handy checkout command:
git checkout <commit hash>
git checkout -b <new branch name>
You can then rebase that against your mainline when you are ready to merge those changes:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
You can use any reference to a git commit, including the SHA-1 if that's most convenient. The point is that the command looks like this:
git checkout [commit-ref] -- [filename]
You can do it in 4 steps:
- revert the entire commit with the file you want to specifically revert - it will create a new commit on your branch
- soft reset that commit - removes the commit and moves the changes to the working area
- handpick the files to revert and commit them
- drop all other files in your work area
What you need to type in your terminal:
git revert <commit_hash>git reset HEAD~1git add <file_i_want_to_revert>&&git commit -m 'reverting file'git checkout .
good luck
Amusingly, git checkout foo will not work if the working copy is in a directory named foo; however, both git checkout HEAD foo and git checkout ./foo will:
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
As of git v2.23.0 there's a new git restore method which is supposed to assume part of what git checkout was responsible for (even the accepted answer mentions that git checkout is quite confusing). See highlights of changes on github blog.
The default behaviour of this command is to restore the state of a working tree with the content coming from the source parameter (which in your case will be a commit hash).
So based on Greg Hewgill's answer (assuming the commit hash is c5f567) the command would look like this:
git restore --source=c5f567 file1/to/restore file2/to/restore
Or if you want to restore to the content of one commit before c5f567:
git restore --source=c5f567~1 file1/to/restore file2/to/restore
You have to be careful when you say "rollback". If you used to have one version of a file in commit $A, and then later made two changes in two separate commits $B and $C (so what you are seeing is the third iteration of the file), and if you say "I want to roll back to the first one", do you really mean it?
If you want to get rid of the changes both the second and the third iteration, it is very simple:
$ git checkout $A file
and then you commit the result. The command asks "I want to check out the file from the state recorded by the commit $A".
On the other hand, what you meant is to get rid of the change the second iteration (i.e. commit $B) brought in, while keeping what commit $C did to the file, you would want to revert $B
$ git revert $B
Note that whoever created commit $B may not have been very disciplined and may have committed totally unrelated change in the same commit, and this revert may touch files other than file you see offending changes, so you may want to check the result carefully after doing so.
You can do it in 4 steps:
- revert the entire commit with the file you want to specifically revert - it will create a new commit on your branch
- soft reset that commit - removes the commit and moves the changes to the working area
- handpick the files to revert and commit them
- drop all other files in your work area
What you need to type in your terminal:
git revert <commit_hash>git reset HEAD~1git add <file_i_want_to_revert>&&git commit -m 'reverting file'git checkout .
good luck
If you know how many commits you need to go back, you can use:
git checkout master~5 image.png
This assumes that you're on the master branch, and the version you want is 5 commits back.
Amusingly, git checkout foo will not work if the working copy is in a directory named foo; however, both git checkout HEAD foo and git checkout ./foo will:
$ pwd
/Users/aaron/Documents/work/foo
$ git checkout foo
D foo
Already on "foo"
$ git checkout ./foo
$ git checkout HEAD foo
Many answers here claims to use git reset ... <file> or git checkout ... <file> but by doing so, you will loose every modifications on <file> committed after the commit you want to revert.
If you want to revert changes from one commit on a single file only, just as git revert would do but only for one file (or say a subset of the commit files), I suggest to use both git diff and git apply like that (with <sha> = the hash of the commit you want to revert) :
git diff <sha>^ <sha> path/to/file.ext | git apply -R
Basically, it will first generate a patch corresponding to the changes you want to revert, and then reverse-apply the patch to drop those changes.
Of course, it shall not work if reverted lines had been modified by any commit between <sha1> and HEAD (conflict).
For me none of the reply seemed really clear and therefore I would like to add mine which seems super easy.
I have a commit abc1 and after it I have done several (or one modification) to a file file.txt.
Now say that I messed up something in the file file.txt and I want to go back to a previous commit abc1.
1.git checkout file.txt : this will remove local changes, if you don't need them
2.git checkout abc1 file.txt : this will bring your file to your wanted version
3.git commit -m "Restored file.txt to version abc1" : this will commit your reversion.
git push: this will push everything on the remote repository
Between the step 2 and 3 of course you can do git status to understand what is going on. Usually you should see the file.txt already added and that is why there is no need of a git add.
Many suggestions here, most along the lines of git checkout $revision -- $file. A couple of obscure alternatives:
git show $revision:$file > $file
And also, I use this a lot just to see a particular version temporarily:
git show $revision:$file
or
git show $revision:$file | vim -R -
(OBS: $file needs to be prefixed with ./ if it is a relative path for git show $revision:$file to work)
And the even more weird:
git archive $revision $file | tar -x0 > $file
git revert <hash>
Will revert a given commit. It sounds like you think git revert only affects the most recent commit.
That doesn't solve your problem, if you want to revert a change in a specific file and that commit changed more than that file.
git checkout -- foo
That will reset foo to HEAD. You can also:
git checkout HEAD^ foo
for one revision back, etc.
If you're using Git Extensions and you only want to revert to the parent commit for the file, you can select the commit that contains the changes you want to revert, then select the 'Diff' tab in the details pane, right-click the file you want to revert, then 'Reset file(s) to' ...., then 'A' (the parent)
git-aliases, awk and shell-functions to the rescue!
git prevision <N> <filename>
where <N> is the number of revisions of the file to rollback for file <filename>.
For example, to checkout the immediate previous revision of a single file x/y/z.c, run
git prevision -1 x/y/z.c
How git prevision works?
Add the following to your gitconfig
[alias]
prevision = "!f() { git checkout `git log --oneline $2 | awk -v commit="$1" 'FNR == -commit+1 {print $1}'` $2;} ;f"
The command basically
- performs a
git logon the specified file and- picks the appropriate commit-id in the history of the file and
- executes a
git checkoutto the commit-id for the specified file.
Essentially, all that one would manually do in this situation,
wrapped-up in one beautiful, efficient git-alias - git-prevision
Many suggestions here, most along the lines of git checkout $revision -- $file. A couple of obscure alternatives:
git show $revision:$file > $file
And also, I use this a lot just to see a particular version temporarily:
git show $revision:$file
or
git show $revision:$file | vim -R -
(OBS: $file needs to be prefixed with ./ if it is a relative path for git show $revision:$file to work)
And the even more weird:
git archive $revision $file | tar -x0 > $file
This worked for me:
git checkout <commit hash> file
Then commit the change:
git commit -a
git checkout -- foo
That will reset foo to HEAD. You can also:
git checkout HEAD^ foo
for one revision back, etc.
Note, however, that git checkout ./foo and git checkout HEAD ./foo
are not exactly the same thing; case in point:
$ echo A > foo
$ git add foo
$ git commit -m 'A' foo
Created commit a1f085f: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
$ echo B >> foo
$ git add foo
$ echo C >> foo
$ cat foo
A
B
C
$ git checkout ./foo
$ cat foo
A
B
$ git checkout HEAD ./foo
$ cat foo
A
(The second add stages the file in the index, but it does not get
committed.)
Git checkout ./foo means revert path ./foo from the index;
adding HEAD instructs Git to revert that path in the index to its
HEAD revision before doing so.
I had the same issue just now and I found this answer easiest to understand (commit-ref is the SHA value of the change in the log you want to go back to):
git checkout [commit-ref] [filename]
This will put that old version in your working directory and from there you can commit it if you want.
I have to plug EasyGit here, which is a wrapper to make git more approachable to novices without confusing seasoned users. One of the things it does is give more meanings to git revert. In this case, you would simply say:
eg revert foo/bar foo/baz
This is a very simple step. Checkout file to the commit id we want, here one commit id before, and then just git commit amend and we are done.
# git checkout <previous commit_id> <file_name>
# git commit --amend
This is very handy. If we want to bring any file to any prior commit id at the top of commit, we can easily do.
For me none of the reply seemed really clear and therefore I would like to add mine which seems super easy.
I have a commit abc1 and after it I have done several (or one modification) to a file file.txt.
Now say that I messed up something in the file file.txt and I want to go back to a previous commit abc1.
1.git checkout file.txt : this will remove local changes, if you don't need them
2.git checkout abc1 file.txt : this will bring your file to your wanted version
3.git commit -m "Restored file.txt to version abc1" : this will commit your reversion.
git push: this will push everything on the remote repository
Between the step 2 and 3 of course you can do git status to understand what is going on. Usually you should see the file.txt already added and that is why there is no need of a git add.
Here's how rebase works:
git checkout <my branch> git rebase master git checkout master git merge <my branch>
Assume you have
---o----o----o----o master \---A----B <my branch>
The first two commands ... commit git checkout git rebase master
... check out the branch of changes you want to apply to the master branch. The rebase command takes the commits from <my branch> (that are not found in master) and reapplies them to the head of master. In other words, the parent of the first commit in <my branch> is no longer a previous commit in the master history, but the current head of master. The two commands are the same as:
git rebase master <my branch>
It might be easier to remember this command as both the "base" and "modify" branches are explicit.
. The final history result is:
---o----o----o----o master \----A'----B' <my branch>
The final two commands ...
git checkout master
git merge <my branch>
... do a fast-forward merge to apply all <my branch> changes onto master. Without this step, the rebase commit does not get added to master. The final result is:
---o----o----o----o----A'----B' master, <my branch>
master and <my branch> both reference B'. Also, from this point it is safe to delete the <my branch> reference.
git branch -d <my branch>
You have to be careful when you say "rollback". If you used to have one version of a file in commit $A, and then later made two changes in two separate commits $B and $C (so what you are seeing is the third iteration of the file), and if you say "I want to roll back to the first one", do you really mean it?
If you want to get rid of the changes both the second and the third iteration, it is very simple:
$ git checkout $A file
and then you commit the result. The command asks "I want to check out the file from the state recorded by the commit $A".
On the other hand, what you meant is to get rid of the change the second iteration (i.e. commit $B) brought in, while keeping what commit $C did to the file, you would want to revert $B
$ git revert $B
Note that whoever created commit $B may not have been very disciplined and may have committed totally unrelated change in the same commit, and this revert may touch files other than file you see offending changes, so you may want to check the result carefully after doing so.
git checkout -- foo
That will reset foo to HEAD. You can also:
git checkout HEAD^ foo
for one revision back, etc.
You can quickly review the changes made to a file using the diff command:
git diff <commit hash> <filename>
Then to revert a specific file to that commit use the reset command:
git reset <commit hash> <filename>
You may need to use the --hard option if you have local modifications.
A good workflow for managaging waypoints is to use tags to cleanly mark points in your timeline. I can't quite understand your last sentence but what you may want is diverge a branch from a previous point in time. To do this, use the handy checkout command:
git checkout <commit hash>
git checkout -b <new branch name>
You can then rebase that against your mainline when you are ready to merge those changes:
git checkout <my branch>
git rebase master
git checkout master
git merge <my branch>
I think I've found it....from http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Sometimes you just want to go back and forget about every change past a certain point because they're all wrong.
Start with:
$ git log
which shows you a list of recent commits, and their SHA1 hashes.
Next, type:
$ git reset --hard SHA1_HASH
to restore the state to a given commit and erase all newer commits from the record permanently.
git checkout -- foo
That will reset foo to HEAD. You can also:
git checkout HEAD^ foo
for one revision back, etc.
Obviously someone either needs to write an intelligible book on git, or git needs to be better explained in the documentation. Faced with this same problem I guessed that
cd <working copy>
git revert master
would undo the last commit which is seemed to do.
Ian
I had the same issue just now and I found this answer easiest to understand (commit-ref is the SHA value of the change in the log you want to go back to):
git checkout [commit-ref] [filename]
This will put that old version in your working directory and from there you can commit it if you want.
And to revert to last committed version, which is most frequently needed, you can use this simpler command.
git checkout HEAD file/to/restore
As of git v2.23.0 there's a new git restore method which is supposed to assume part of what git checkout was responsible for (even the accepted answer mentions that git checkout is quite confusing). See highlights of changes on github blog.
The default behaviour of this command is to restore the state of a working tree with the content coming from the source parameter (which in your case will be a commit hash).
So based on Greg Hewgill's answer (assuming the commit hash is c5f567) the command would look like this:
git restore --source=c5f567 file1/to/restore file2/to/restore
Or if you want to restore to the content of one commit before c5f567:
git restore --source=c5f567~1 file1/to/restore file2/to/restore
First Reset Head For Target File
git reset HEAD path_to_file
Second Checkout That File
git checkout -- path_to_file
I think I've found it....from http://www-cs-students.stanford.edu/~blynn/gitmagic/ch02.html
Sometimes you just want to go back and forget about every change past a certain point because they're all wrong.
Start with:
$ git log
which shows you a list of recent commits, and their SHA1 hashes.
Next, type:
$ git reset --hard SHA1_HASH
to restore the state to a given commit and erase all newer commits from the record permanently.
git revert <hash>
Will revert a given commit. It sounds like you think git revert only affects the most recent commit.
That doesn't solve your problem, if you want to revert a change in a specific file and that commit changed more than that file.
Here is my way.
a) In Android Studio, open the file.
b) git -> Show History, find the previous commit I want to revert to. Get the commit_id (i.e. commit hash).
c) git checkout commit_id file_path
This worked for me:
git checkout <commit hash> file
Then commit the change:
git commit -a
Source: Stackoverflow.com