It's easy to see the work-tree: it has your files in their ordinary format, where you can view and edit them with all the regular tools on your computer. 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 Comments
Leave a Reply. |