Amending the most recent commit message
git commit --amend
will open your editor, allowing you to change the commit message of the most recent commit. Additionally, you can set the commit message directly in the command line with:
git commit --amend -m "New commit message"
…however, this can make multi-line commit messages or small corrections more cumbersome to enter.
Make sure you don't have any working copy changes staged before doing this or they will get committed too. (Unstaged changes will not get committed.)
Changing the message of a commit that you've already pushed to your remote branch
If you've already pushed your commit up to your remote branch, then - after amending your commit locally (as described above) - you'll also need to force push the commit with:
git push <remote> <branch> --force
# Or
git push <remote> <branch> -f
Warning: force-pushing will overwrite the remote branch with the state of your local one. If there are commits on the remote branch that you don't have in your local branch, you will lose those commits.
Warning: be cautious about amending commits that you have already shared with other people. Amending commits essentially rewrites them to have different SHA IDs, which poses a problem if other people have copies of the old commit that you've rewritten. Anyone who has a copy of the old commit will need to synchronize their work with your newly re-written commit, which can sometimes be difficult, so make sure you coordinate with others when attempting to rewrite shared commit history, or just avoid rewriting shared commits altogether.
Perform an interactive rebase
Another option is to use interactive rebase.
This allows you to edit any message you want to update even if it's not the latest message.
In order to do a Git squash, follow these steps:
// n is the number of commits up to the last commit you want to be able to edit
git rebase -i HEAD~n
Once you squash your commits - choose the e/r
for editing the message:
Important note about interactive rebase
When you use git rebase -i HEAD~n
there can be more than n commits. Git will "collect" all the commits in the last n commits, and if there was a merge somewhere in between that range you will see all the commits as well, so the outcome will be n + .
Good tip:
If you have to do it for more than a single branch and you might face conflicts when amending the content, set up git rerere
and let Git resolve those conflicts automatically for you.
Documentation
Assuming the hash of the commit you want is c5f567
:
git checkout c5f567 -- file1/to/restore file2/to/restore
The git checkout man page gives more information.
If you want to revert to the commit before c5f567
, append ~1
(where 1 is the number of commits you want to go back, it can be anything):
git checkout c5f567~1 -- file1/to/restore file2/to/restore
As a side note, I've always been uncomfortable with this command because it's used for both ordinary things (changing between branches) and unusual, destructive things (discarding changes in the working directory).
There is also a new git restore
command that is specifically designed for restoring working copy files that have been modified. If your git is new enough you can use this command, but the documentation comes with a warning:
THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
Best Answer
If you do not know the exact path you may use
If you know the path the file was at, you can do this:
This should show a list of commits in all branches which touched that file. Then, you can find the version of the file you want, and display it with...
Or restore it into your working copy with:
git checkout <SHA>^ -- <path-to-file>
Note the caret symbol (
^
), which gets the checkout prior to the one identified, because at the moment of<SHA>
commit the file is deleted, we need to look at the previous commit to get the deleted file's contents