To add a bit to Ron Nabuurs' answer, note that git commit
obtains the commit content from Git's index, not from the work-tree. (The index is also called the staging area and sometimes the cache.) When you run git add file
, Git copies the content of the given file
from the work-tree into the index.
If some of your work-tree files are damaged, but the index versions are intact, you can simply avoid running git add
on the work-tree files. The index versions remain unchanged and git commit
will use them.
If the index version is also damaged, but the HEAD
version is intact, you can instruct Git to copy the HEAD
version into the index, using git reset
as Ron showed: git reset file
.
Think of the index as sitting "between" the current (HEAD
) commit and the work-tree, because it does:
HEAD commit index work-tree
----------- --------- ---------
README.md README.md README.md
file.ext file.ext file.ext
The operation that copies from work-tree to index is git add
, and the operation that copies from commit to index is git reset
.
(Any committed file is by definition read-only, so there is no operation to copy from index to commit. Of course, you can make a new commit, which becomes your HEAD
commit, using git commit
to turn the index into a commit.)
It's also possible to copy from any commit, to the work-tree, using git checkout
in the git checkout commit -- file
form of the command. Note, however, that when you do this, git checkout
first copies the file from the given commit to the index, then from the index to the work-tree, so this kind of copy replaces both index and work-tree versions.