Difference between revisions of "Git/commit"
(a bit more explanation from the book) |
m (proper sorting for category) |
||
| Line 1: | Line 1: | ||
| − | [[category:git/concepts]] | + | [[category:git/concepts|commit]] |
"Committed" seems to be a per-file flag that indicates whether a {{l/same|staged}} file is ready for further operations, such as {{l/same|push}}ing. (There's some ambiguity about whether it makes sense to speak of files being "[un]modified", or whether that only applies to "changes" -- see {{l/same|notes}}.) | "Committed" seems to be a per-file flag that indicates whether a {{l/same|staged}} file is ready for further operations, such as {{l/same|push}}ing. (There's some ambiguity about whether it makes sense to speak of files being "[un]modified", or whether that only applies to "changes" -- see {{l/same|notes}}.) | ||
Revision as of 21:11, 9 March 2015
"Committed" seems to be a per-file flag that indicates whether a staged file is ready for further operations, such as pushing. (There's some ambiguity about whether it makes sense to speak of files being "[un]modified", or whether that only applies to "changes" -- see notes.)
"A commit" is a specific set of project-file revisions that are archived together at a specific time.
When you create a commit with git commit, Git checksums each subdirectory and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed.
After committing, the repository contains the following objects:
- one blob for each of your files, containing that file's contents
- one tree that lists the contents of the directory and specifies which file names are stored as which blobs
- one commit with the pointer to that root tree and all the commit metadata.
The last two paragraphs were adapted from 3.1 Git Branching - Branches in a Nutshell.