Git copies the files from HEAD into the index, and then from the index into the work-tree.
Initially, the HEAD commit and the index normally match: they contain the same versions of all the committed files. The point of this index is to act as an intermediate file-holder, situated between "the current commit" (aka HEAD) and the work-tree. In newer Git versions, you can use git worktree add to add additional work-trees each new work-tree comes with one new index/staging-area.
This index is linked with the one work-tree. Note that each Git repository has just the one index, at least initially. This is also true of commits you obtain from someone else: they save the files that were in the other user's index at the time the other user ran git commit. Each commit also saves a complete snapshot of all the files you told it to: these are the files stored in your index (also known as your staging area) at the time you ran git commit. Commits, the index, and the work-treeĮach commit has several pieces of information, such as the author's name and email address and a time-stamp. This collection rarely shrinks: for the most part, the only thing you ever do with this collection of commits is add new commits. In fact, this is essentially what Git is about: it manages a collection of commits. The first thing to know here is that Git stores commits. The complicated parts come before and after.
0 kommentar(er)
