Top git-commit Questions

List of Tags
Hamza Yerlikaya

I accidentally added the wrong directory containing my files in Git. Instead of adding a .java file, I added the directory containing the .class file. How can I undo this action?

Answered By: Esko Luontola ( 2020)

Undo a commit and redo

$ git commit ...              (1)
$ git reset --soft HEAD^      (2)
$ edit                        (3)
$ git add ....                (4)
$ git commit -c ORIG_HEAD     (5)
  1. This is what you want to undo

  2. This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset".

  3. Make corrections to working tree files.

  4. Stage changes for commit.

  5. "reset" copies the old head to .git/ORIG_HEAD; redo the commit by starting with its log message. If you do not need to edit the message further, you can give -C option instead.


I would like to know how to delete a git commit. By "delete" I mean it is as if I did not do that commmit and when I do a git push in the future, my changes will not push to the remote branch.

I read git help. I think the command I should use is git reset --hard HEAD. Is that correct?

Answered By: gahooa ( 584)


Assuming you are sitting on that commit, then this command will wack it...

git reset --hard HEAD~1

The HEAD~1 means the commit before head.

Or, you could look at the output of git log, find the commit id of the commit you want to back up to, and then do this:

git reset --hard <sha1-commit-id>

If you already pushed it, you will need to do a force push to get rid of it...

git push origin HEAD --force

However, if others may have pulled it, then you would be better off starting a new branch. Because when they pull, it will just merge it into their work, and you will get it pushed back up again.

If you already pushed, it may be better to use git revert, to create a "mirror image" commit that will undo the changes. However, both commits will both be in the log.

FYI -- git reset --hard HEAD is great if you want to get rid of WORK IN PROGRESS. It will reset you back to the most recent commit, and erase all the changes in your working tree and index.

Lastly, if you need to find a commit that you "deleted", it is typically present in git reflog unless you have garbage collected your repository.

Crazy Serb

If I do "git log" and get the following output:

[root@me dev]# git log
commit a867b4af366350be2e7c21b8de9cc6504678a61b`
Author: Me 
Date:   Thu Nov 4 18:59:41 2010 -0400

blah blah blah...

commit 25eee4caef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me 
Date:   Thu Nov 4 05:13:39 2010 -0400

more blah blah blah...

commit 0766c053c0ea2035e90f504928f8df3c9363b8bd
Author: Me 
Date:   Thu Nov 4 00:55:06 2010 -0400

And yet more blah blah...

commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Author: Me 
Date:   Wed Nov 3 23:56:08 2010 -0400

Yep, more blah blah.

How do I revert from my current state to the commit made on Nov 3rd, for example?

Answered By: Jefromi ( 663)

This depends a lot on what you mean by "revert".

If you want to temporarily go back to it, fool around, then come back to where you are, all you have to do is check out the desired commit:

# this will detach your HEAD, i.e. leave you with no branch checked out.
git checkout 0d1d7fc32

or if you want to make commits while you're there, go ahead and make a new branch while you're at it:

git checkout -b old-state 0d1d7fc32

If, on the other hand, you want to really get rid of everything you've done since then, there are two possibilities. One, if you haven't published any of these commits, simply reset:

# This will destroy any local modifications
# Don't do it if you have uncommitted work you want to keep
git reset --hard 0d1d7fc32

# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts, if you've modified things which were
# changed since the commit you reset to

On the other hand, if you've published the work, you probably don't want to reset the branch, since that's effectively rewriting history. In that case, you could indeed revert the commits. With git, revert has a very specific meaning: create a commit with the reverse patch to cancel it out. This way you don't rewrite any history.

# This will create three separate revert commits
git revert 0766c053 25eee4ca a867b4af

# To get just one, you could use `rebase -i` to squash them afterwards
# Or, you could do it manually (be sure to do this at top level of the repo)
# get your index and work tree into the desired state, without changing HEAD:
git checkout 0d1d7fc32 .
# and then commit
git commit    # be sure and write a good message describing what you just did

The git-revert manpage actually covers a lot of this in its description. Another useful link from the Git Community Book discussing git-revert is here.


I have a Git repo that I have deleted four files from using rm (not git rm), and my Git status looks like this:

#    deleted:    file1.txt
#    deleted:    file2.txt
#    deleted:    file3.txt
#    deleted:    file4.txt

How do I remove these files from Git without having to manually go through and add each file like this:

git rm file1 file2 file3 file4

Ideally, I'm looking for something that works in the same way that git add . does, if that's possible.

Answered By: Cody Caughlan ( 456)

You can use

git add -u

To add the deleted files to the staging area, then commit them

git commit -m "Deleted files manually"
Clark Gaebel

What's the point of the Sign Off feature in Git?

git commit --signoff

When should I use it, if at all?

Answered By: Brian Campbell ( 142)

Sign-off is a requirement for getting patches into the Linux kernel and a few other projects, but most projects don't actually use it.

It was introduced in the wake of the SCO lawsuit, (and other accusations of copyright infringement from SCO, most of which they never actually took to court), as a Developers Certificate of Origin. It is used to say that you certify that you have created the patch in question, or that you certify that to the best of your knowledge, it was created under an appropriate open-source license, or that it has been provided to you by someone else under those terms. This can help establish a chain of people who take responsibility for the copyright status of the code in question, to help ensure that copyrighted code not released under an appropriate free software (open source) license is not included in the kernel.