![]() git directory can actually be smaller than the files it contains, once they're expanded out to normal everyday files. Even then it's compressed-sometimes very compressed, though this actually happens later-so that a. By simply re-using those files directly, Git saves lots of space: if we only touched one file, the new commit only takes space for one new copy. So most of the files in a commit are mostly the same as the files in the previous commit. The de-duplication helps with space: we normally only change a few files, then make a new commit. (There's more stuff in each commit than just this snapshot, but that's all we will cover here.) (Which files does Git know about? We'll see that in the next section.) These snapshots are stored in a special, read-only, Git-only, compressed and de-duplicated form, that in general only Git itself can read. In Git, a commit saves a full snapshot of every file that Git knows about. The new command exists because git checkout got over-stuffed with too many things they got split out into two separate commands, git switch and git restore, to make it easier and safer to use Git. For this particular case, these two commands do exactly the same thing. To properly understand the index, it's good to start with understanding commits.ġSince Git version 2.23, you can use git switch instead of git checkout. A tracked file is one that exists in Git's index. Is a 'staged' file the same thing as a 'tracked' file? These are all names for the same thing.Įdit: I think I may be confusing the terminology. The secret here is what Git calls, variously, the index, or the staging area, or sometimes-rarely these days-the cache. ![]() With Git, you use git checkout, 1 then you do your work, then you run git add, and then git commit. With Mercurial, you use the hg command that selects some commit, then you do your work, then you run hg commit, and you're done. For instance, Mercurial, which is otherwise a lot like Git in terms of usage, doesn't require a separate hg add step, beyond the very first one that introduces an all-new file. There exist version control systems that don't require a separate staging step. Is staging something that exists in name only or does it serve a purpose? When you commit, its going to commit everything anyway, right? What I don't understand is what staging for is from a practical perspective. Version control normally saves every committed version forever. Backups are typically stored for some time, then jettisoned as "too old": a fresher backup is all that matters. Version control is typically designed for finer-grained interactions and offers features that backups don't. Backups and and version control are certainly related-exactly how strongly depends on some things that are to some extent matters of opinion-but there are certainly some differences, if only in intent: Backups are typically designed for disaster recovery (machine fails, fire destroys entire building including all storage media, etc.). I'm new to version control and I understand that "committing" is essentially creating a backup while updating the new 'current' version of what you're working on. (See his answer for why bother type questions this is more about what is going on.) To expand on Ben Jackson's answer, which is fine, let's look at the original question closely. When you come back just do git diff -staged and check which files you changed and where and start making other changes. So add the file to the staging area and it will save your work. At this moment you cannot commit and you want to track which files you are done with so that after coming back you do not need to try to remember how much work have been done. Suppose you need to change three files to make one logical change and you have changed the first file and need a long break until you start making the other changes. It also gives you the offer to take break and forgetting about how much work you have done before taking break.With staging area it is easier to focus in small tasks. Just make one logical change in the code, add the changed files to the staging area and finally if the changes are bad then checkout to the previous commit or otherwise commit the changes.It gives the flexibility to split the task into smaller tasks and commit smaller changes. Staging area gives the control to make commit smaller.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |