According to this page
http://www.eecs.harvard.edu/~cduan/technical/git/git-1.shtml
A commit object contains three things:
- A set of files, reflecting the state of a project at a given point in time.
- References to parent commit objects.
- An SHA1 name, a 40-character string that uniquely identifies the commit
object. The name is composed of a hash
of relevant aspects of the commit, so
identical commits will always have the
same name.
My question is regarding first point:
If my current project size is 10MB , so adding a new commit will take another 10MB ? since according to first point each commit contains set of files reflecting project state.
I’m not sure the other answers have really addressed your question completely.
Git stores commits and actual file contents separately. A commit doesn’t contain files — it contains references to the hashes of files that the commit contains. Files are stored separately from commits, and if two commits have the same version of a file, both of those commits will refer to the same hash, but the file itself is not duplicated. If a file changes between commits, the file is stored twice, each version of the file has its own hash, and the commits will refer to different hashes.
Say you start with one commit, which contains two files, a.txt and b.txt, each of which hashes to a different value:
Note that the commit does not contain the file contents. Git has stored the contents of the files, and the hashes, elsewhere.
Say you update a.txt, and make a new commit. First, Git stores the new version of the file in its store of file contents:
And the new commit points to that hash as containing the contents of a.txt:
Since b.txt did not change, there was no need to store it again. The second commit just refers to the same hash as the first commit.