I am trying to compare two commits of a Git Project. What I do is I clone the repository to a postfix folder, I then use:
git --grep=xxx Where xxx is the commit number, retrieve the hash and then use git checkout for the retrieved hash.
However, git grep only returns the details of that particular commit.
If for example the commit had ID 24, would it be enough for me to retrieve commit with ID 23 in order to get a version of the project without the fix?
I'm not sure what are those IDs you're talking about: Git commits do not have any sequental IDs and are only identified by their SHA-1 names which are hashes calculated over the corresponding commit objects.
So I might suppose you're talking about a project which embeds some externally generated IDs. One reason might be that this is a project which follows a Subversion repository as by default all commits created in such a repository will have the Subversion URL and revision ID artifically embedded in their messages.
First things first: in general, the answer to your question is no. The reason is that any Git commit might have more than one parent—if it's a merge commit. Hence considering a commit and merely stepping backwards (see below for how to do that) is not possible.
The gitrevisions(7) manual page lists two forms of selecting one of the parent commits:
<rev>^, e.g.HEAD^,v1.5.1^0A suffix
^to a revision parameter means the first parent of that commit object.^<n>means the<n>th parent (i.e.<rev>^is equivalent to<rev>^1). As a special rule,<rev>^0means the commit itself and is used when<rev>is the object name of a tag object that refers to a commit object.
<rev>~<n>, e.g.master~3A suffix
~<n>to a revision parameter means the commit object that is the<n>th generation ancestor of the named commit object, following only the first parents. I.e.<rev>~3is equivalent to<rev>^^^which is equivalent to<rev>^1^1^1. See below for an illustration of the usage of this form.
As you can see, Git either forces you to indicate the parent explicitly or assume the first (also "left") parent (this is the one which the merge has been made into).
Hence, once you know the SHA-1 name of a commit, let it be 2abcde45, you can refer to its first parent using 2abcde45^ or 2abcde45^1 or 2abcde45~1 which are all the same for this task.
I'd like to again stress the fact Git commits do not have "IDs" in the sense you seem to be using, so please take time to actually know what IDs you're dealing with. Posting another question here on SO citing the commit message of a sample commit would be OK, I think.
Once you have the commit checked out, you can wind back to the parent commit easily (assuming it only has one parent):
$ git checkout HEAD^ 
