Difference between revisions of "Git/commit"
< Git
Jump to navigation
Jump to search
m (proper sorting for category) |
(more details) |
||
| Line 1: | Line 1: | ||
[[category:git/concepts|commit]] | [[category:git/concepts|commit]] | ||
| − | " | + | [[category:git/commands|commit]] |
| + | ==Concept== | ||
| + | "A commit" is a specific set of project-file revisions that are archived together at a specific time. A commit is created from what is currently in the {{l/same|staging}} area. | ||
| − | " | + | "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. |
| − | + | At {{l/same|commit}} time, Git checksums each subdirectory (and file?) and stores those tree objects under the {{l/same|HEAD}} {{l/same|branch}} of the project's Git {{l/same|repository}} (which is kept under the .git/ folder). 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. | |
| − | + | When you create a commit with [[../commit|git commit]], Git stores the following objects: | |
* one blob for each of your files, containing that file's contents | * 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 tree that lists the contents of the directory and specifies which file names are stored as which blobs | ||
| − | * | + | * a commit object, which is basically a pointer to the snapshot of the content you staged, which contains: |
| + | ** the author's name and email (from Git's configuration data) | ||
| + | ** the commit message that you typed when creating the commit | ||
| + | ** pointers to the commit or commits that directly came before this commit (its parent or parents) | ||
| + | *** zero parents for the initial commit | ||
| + | *** one parent for a normal commit | ||
| + | *** multiple parents for a commit that results from a merge of two or more branches. | ||
''The last two paragraphs were adapted from [http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell 3.1 Git Branching - Branches in a Nutshell].'' | ''The last two paragraphs were adapted from [http://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell 3.1 Git Branching - Branches in a Nutshell].'' | ||
| + | ==Command== | ||
Revision as of 21:24, 13 March 2015
Concept
"A commit" is a specific set of project-file revisions that are archived together at a specific time. A commit is created from what is currently in the staging area.
"Committed" seems to be a per-file flag that indicates whether a staged file is ready for further operations, such as pushing.
At commit time, Git checksums each subdirectory (and file?) and stores those tree objects under the HEAD branch of the project's Git repository (which is kept under the .git/ folder). 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.
When you create a commit with git commit, Git stores 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
- a commit object, which is basically a pointer to the snapshot of the content you staged, which contains:
- the author's name and email (from Git's configuration data)
- the commit message that you typed when creating the commit
- pointers to the commit or commits that directly came before this commit (its parent or parents)
- zero parents for the initial commit
- one parent for a normal commit
- multiple parents for a commit that results from a merge of two or more branches.
The last two paragraphs were adapted from 3.1 Git Branching - Branches in a Nutshell.