These are in what Git calls, variously, the index, or the staging area, or-rarely these days-the cache. Instead, Git keeps all of the Git-ized files from the last commit. When you make a new commit, Git will have to re-Git-ize all the files, and this process would be very slow, so Git doesn't just do it over again. They are copies, made from those files but the files inside the Git repository are in a different, Git-only format. The working tree files are not the ones that are inside the Git repository. You do your work here, in your working tree. Git calls this area, with the usable files that you can work on and with, your working tree. Git uses the names database to find the big ugly hash ID of that particular commit, then uses the archive inside that commit to populate a working tree full of usable files. This is what git checkout or the new (since Git 2.23) git switch is for: you tell Git get me the latest master commit or get me the latest develop commit. Or rather, you can't use it until you first have Git un-archive it, to turn its saved archive back into ordinary files. What all this means is that you cannot actually use any commit. To make this archive not use up all your disk space quickly, the stored files inside commits are in a special, read-only, Git-only, compressed and de-duplicated form. And, each commit stores a full archive of every file. Nothing about any commit can ever change, once you make the commit. With all that in mind, remember also that every commit is completely, totally, 100% read-only. Commits themselves store the commit numbers of other commits, so once we find some particularly interesting commit-such as the latest master or develop commit, for instance-we can use that commit to find other interesting commits but we need the hash ID of that one particular commit, to get started. Each commit is numbered, with a unique (and big and ugly) hash ID that appears random, so we need some mechanism to find particularly interesting commits, such as the most recent commit for some branch. The names are mostly used to find the commits. One holds all the commits and other internal Git objects, and the other holds names: branch names, tag names, and other such names. The main bulk of a Git repository consists of two databases. Before I get to the next steps, though, I want to describe exactly what this all means. I wrote some code, staged it I wanted to do commit. There's no automated way to get back what you had. The short answer is that you may have to do a lot of work, or just a little work.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |