I have seen GIT commit --amend in detached HEAD state. The question requires the answer to be more complex than needs be. I'd like to understand just how git commit --amend works in a normal HEAD situation.
Assume that you're in a clean working state and that your repo looks as follows:
If you then run
git commit --amend
write a commit message, save and quit your editor, the following happens:
- Your staging area—which, if you haven't staged any new changes, will be identical to commit
f42c5—is used to create a new commit:31b8e. Its parent(s) will be the same as that(those) of the commit you're amending:f42c5. - The
masterbranch reference is moved to point to that new commit (31b8e). - The
HEADreference followsmaster.
Note that the amended commit (f42c5) is now unreachable from any reference in your repo (hence its "transparent" style on my graph). It still lives in your repository's object database, but will eventually be deleted for good, when Git runs its periodic housekeeping, or if you trigger it explicitly by running git gc (garbage collection).
Addendum (based on Jason Baker's comment): Note that, as long as the amended commit, f42c5, still exists in your repo and you have a way of finding out its commit ID (for example, by fishing it out of the master branch's reflog), you can still check it out. Running
git checkout master # just to be sure that master is the current branch
git reset --hard f42c5
or (assuming you haven't, in the meantime, made any new commit on master, reset master, or otherwise moved the master branch reference)
git checkout master # just to be sure that master is the current branch
git reset --hard master@{1}
would put you in the following situation:
But now, commit 31b8e would become unreachable.
Say you just committed "B"
... --- A --- B
^
|
master
HEAD
Amending "B" will create a parallel commit which becomes the new branch head.
+---- B
|
... --- A --- B'
^
|
master
HEAD
B' is the commit resulting from a combination of the changes from B plus the changes you had staged when you issued the git commit --amend.
According to my knowledge, ammend works thus:
For git commit --ammend works the changes to ammend must be into Stagging Area (SA)
- It makes
git reset -- softfor bring back changes commited in the last commit (commit to ammend) to SA and move the index to previous commit (commit before commit to ammend). Everything keep how was beforegit commitcommand were used. - It makes
git addwith all files to add to new commit ( it will be the ammended commit). The files to add are those were into SA before thegit reset --softwas landed, after reset this files are keept into the WD, so it is necessary add them to SA for generate the ammended commit. - Makes git commit. It will generate a new commit and hence a new id for ammended commit. For this, git commit --ammend should not be used with pushed commits
If you use --no-edit the comment is re-used in the ammended commit, else you must introduce a new comment (becouse it is a new commit and every commit need a comment).
For more info about Stagging Area and Working Directory, see Reset Demystified
来源:https://stackoverflow.com/questions/26050327/how-does-git-commit-amend-work-exactly