[ad_1]
\n<\/p>\n
You are, I think, being misled. Git doesn’t store changes<\/em> at all. The whole thing seems very mysterious until you realize that Git just stores everything intact, but does so in a weird way.<\/p>\n First and most important, Git doesn’t exactly store files<\/em>. It winds up doing so, but that’s because Git stores commits<\/em>, and each individual commit contains (all!) the files. That is, at some earlier point during development, you\u2014or someone\u2014told Git: Here’s this entire file-tree, some set of folders \/ directories containing files and sub-directories that contain more files and sub-directories and so on. Make a snapshot of how they all look right now.<\/em> That snapshot, that entire copy of everything, goes into a new commit.<\/p>\n Next, commits, once made, are mostly permanent, and completely, totally, 100% read-only. You cannot change anything that’s inside a commit. You can just think of them as permanent: the only time a commit can truly go away is if you carefully arrange to make sure that no one\u2014not yourself, nor anyone else\u2014can find<\/em> it later, using For many reasons, including not having the repository get enormously fat if you make many commits that keep re-using most of the old versions of most files, the files that are stored inside commits are kept in a special, compressed, Git-only format. Since the files inside commits are frozen, if new commit C9<\/em> is just like its previous commit C8<\/em> except for one file, the two commits will share<\/em> all the identical files, too.<\/p>\n Since you can’t change<\/em> any commit, at all, ever, Git would be useless if it did not have a way to extract<\/em> all the files from some commit. Extracting a commit copies all of its files out of the deep-freeze, and then de-compresses the files and turns them back into ordinary, every-day files that you and your computer can work with. These files are copies<\/em> of what was in that Git commit, but here, in this work area\u2014the work-tree<\/em> or working tree<\/em>\u2014they’re useful to you and your computer, and<\/em> you can change them any way you like.<\/p>\n Now comes the tricky bit. Other version control systems may stop here: they too have commits, that save the files forever in frozen form, and a work-tree, that let you work on the files in ordinary form. To make a new commit, those other version control systems slowly, painfully, one by one, take each work-tree file, compress it down to get it ready for freezing, and then<\/em> check to see if that frozen file will be the same as the old one. If so, they can re-use the old file! If not, they do whatever it takes to save away the new file. This is terribly slow, and there are various ways to speed it up, which they do use in general, but in these non-Git version control systems, after using their “commit” command, you can often get up and go get coffee, or go for a walk or have lunch or something.<\/p>\n Git does something radically different, and this is how These sort-of-slushy copies of files are in what Git calls, variously, the index<\/em>, the staging area<\/em>, or the cache<\/em>, depending on who or what part of Git is doing the calling. The key difference between these index copies of every file, and the frozen copy in the current commit, is that the committed copies really are frozen. They can’t<\/em> be changed. The index copies are only almost<\/em> frozen: they can<\/em> be changed, by writing a new file into the index in place of that old one.<\/p>\n What this means, in the end, is that for every file in the commit, you wind up with not two but three<\/em> active copies, when you tell Git to make that commit be the current commit, using At this point, all three copies of each file match each other<\/em>. That is, all three Now suppose you change one (or both) of the work-tree files. For instance, suppose you change your work-tree You can now ask Git to compare<\/em> the index copies of every file to the work-tree copies of every file, and this time, you’ll see your change<\/em> to When you run This time, asking Git to compare the index<\/em> copy (of everything) to the work-tree<\/em> copy (of everything) shows nothing! They are the same, after all. To see a difference, you must ask Git to compare the Note, however, that you can change the work-tree copy again<\/em> after you use Now all three copies of When and if you do choose to make a new commit\u2014a new permanent snapshot of all the files as they stand now<\/em>\u2014Git makes the new commit’s snapshot using the semi-frozen files in the index. All that the commit verb has to do with them is finish the freezing process (which, at a technical level, consists of making tree<\/em> objects to hold them, but you don’t need to know this). So Once that commit finishes, the Note that Git completely ignored the work-tree during this process! There’s a way to tell The summary of this particular section is that a good way to think of the index is: The index contains the next<\/em> commit you propose to make.<\/strong> The Because there are<\/em> these three simultaneous, active copies of each file\u2014one permanent, one proposed for the next<\/em> commit, and one that you can actually see and work with\u2014Git needs a way to compare<\/em> these things. The There are, of course, more ways you might want to compare any two items, so Note that the two most useful<\/em> Let’s see that again: So now you know what 1<\/sup>The “status” part of What Git stores permanently<\/h3>\n
git reset<\/code> or similar tools.<\/p>\nWhat Git lets you work with, temporarily<\/h3>\n
Git complicates things with its index<\/h3>\n
git commit<\/code> is so fast, compared to those other systems. When Git is taking files out of the deep-freeze to put into your work-tree, Git keeps a sort of semi-frozen\u2014”slushy”, if you will\u2014copy of every file<\/em>, ready to go into the next<\/em> commit. Initially, these copies all match the frozen commit copy.<\/p>\ngit checkout somebranch<\/em><\/code>. (This checkout selects somebranch<\/code><\/em> as the current branch name<\/em> and therefore also extracts what Git calls its tip commit<\/em> to be the current<\/em> commit. There’s always a name for this current commit: Git calls it HEAD<\/code>.) Suppose, for instance, that the tip commit of master<\/code> has two files, named README.md<\/code> and main.py<\/code>:<\/p>\n HEAD index work-tree\n--------- --------- ---------\nREADME.md README.md README.md\nmain.py main.py main.py\n<\/code><\/pre>\nREADME.md<\/code>s are the same, except in terms of their format: the one in HEAD<\/code> is frozen and Git-only; the one in the index is semi-frozen and Git-only; and the one in your work-tree is usable and useful to you; but all three represent the same file contents<\/em>. The same goes for the three copies of main.py<\/code>.<\/p>\nREADME.md<\/code>. Let’s mark it with a (2)<\/code> to indicate that it’s different, and mark the old ones with (1)<\/code> to remember which the old ones were:<\/p>\n HEAD index work-tree\n------------ ------------ ------------\nREADME.md(1) README.md(1) README.md(2)\nmain.py(1) main.py(1) main.py(1)\n<\/code><\/pre>\nREADME.md<\/code>.<\/p>\ngit add<\/code>, you are really telling Git: Take the work-tree copy of the files I’m adding, and prepare them for freezing.<\/em> Git will copy the work-tree copy of README.md<\/code> or main.py<\/code> (or both) back into the index, Git-ifying the contents, getting them ready for the next freeze:<\/p>\n HEAD index work-tree\n------------ ------------ ------------\nREADME.md(1) README.md(2) README.md(2)\nmain.py(1) main.py(1) main.py(1)\n<\/code><\/pre>\nHEAD<\/code> commit to the index, or the HEAD<\/code> commit to the work-tree. Either will suffice right now, because right now<\/em> the index and work-tree match again.<\/p>\ngit add<\/code>. Suppose you modify README.md<\/code> one more time, giving:<\/p>\n HEAD index work-tree\n------------ ------------ ------------\nREADME.md(1) README.md(2) README.md(3)\nmain.py(1) main.py(1) main.py(1)\n<\/code><\/pre>\nmain.py<\/code> match, but all three copies of README.md<\/code> are different. So now it matters whether you have Git compare HEAD<\/code> vs index, or HEAD<\/code> vs work-tree, or index vs work-tree: each will show a different change<\/em> to README.md<\/code>.<\/p>\nGit makes new<\/em> commits from the index<\/h3>\n
git commit<\/code> collects your name, email, the time, your log message, and the current commit’s hash ID, freezes the index, and puts all of those together into a new commit. The new commit becomes<\/em> the HEAD<\/code> commit, so that now HEAD<\/code> refers to the new<\/em> commit. If the old commit was C8<\/em> and the new one is C9<\/em>, HEAD<\/code> used to mean C8<\/em>, but now it means C9<\/em>.<\/p>\nHEAD<\/code> and index copies of every file automatically match<\/em>. It’s obvious that they must, since the new HEAD<\/code> was made from<\/em> the index. So if you make that new commit with the index holding the middle version of README.md<\/code>, you get:<\/p>\n HEAD index work-tree\n------------ ------------ ------------\nREADME.md(2) README.md(2) README.md(3)\nmain.py(1) main.py(1) main.py(1)\n<\/code><\/pre>\ngit commit<\/code> that it should look at the work-tree and automatically<\/em> run git add<\/code>, but let’s leave that for later.<\/p>\ngit add<\/code> command means: Update my proposed next commit.<\/em> This explains why you have to git add<\/code> all the time.<\/p>\nGit’s
diff<\/code> verb<\/h3>\ndiff<\/code> verb is how you ask Git to compare two things, and its options are how you select which<\/em> two things to compare:<\/p>\n\n
git diff commit-A commit-B<\/em><\/code> tells Git: Extract the snapshot in commit A to a temporary area; extract the snapshot in commit B to a temporary area, and then compare them and show me what’s different.<\/em> This is useful in general, but not so much when making a new<\/em> commit, since it’s about existing, frozen, unchangeable commits.<\/p>\n<\/li>\ngit diff<\/code>\u2014with no options or commit specifiers at all\u2014tells Git: Compare the index to the work-tree.<\/em> Git does not look at any actual commit, it just looks at the index\u2014the proposed<\/em> next commit\u2014and compares to your usable copies of files. Whenever something is different, you could<\/em> use git add<\/code> to copy it into the index. So this tells you what you could git add<\/code>, if you wanted.<\/p>\n<\/li>\ngit diff --cached<\/code> or git diff --staged<\/code>\u2014the options have exactly the same meaning\u2014tells Git: Compare the HEAD<\/code> commit to the index.<\/em> This time, Git does not look at your work-tree at all. It just finds out what’s different between the current commit<\/em> and the proposed next commit<\/em>. That is, this is what would be different<\/em> if you committed right now.<\/p>\n<\/li>\ngit diff HEAD<\/code> (or more generally, git diff commit<\/em><\/code>) tells Git: Compare what’s in the commit I named, such as HEAD<\/code>, to what’s in the work-tree.<\/em> This time, Git ignores your index<\/em>, and just goes with the specific commit\u2014such as HEAD<\/code>\u2014and the contents of the work-tree. This is not as useful as the HEAD-vs-index or index-vs-work-tree comparisons, but you can do it if you want.<\/p>\n<\/li>\n<\/ul>\ngit diff<\/code> has a lot of options. But these are the main ones of interest at this point.<\/p>\ngit status<\/code> runs two git diff<\/code>s<\/h3>\ngit diff<\/code>s above, when you’re actively developing, are git diff --cached<\/code>, which tells you what would<\/em> be different if you committed right now<\/em>, and git diff<\/code> with no options, which tells you what else could be different<\/em> if you ran git add<\/code> right now. The git status<\/code> command, which you should use often, runs both of these diffs for you! It runs them with the --name-status<\/code> flag set, internally, so that instead of showing the actual differences, it just shows the file’s name if the file is changed.1<\/sup><\/p>\ngit status<\/code> runs two<\/strong> git diff<\/code> commands. The first one is git diff --cached<\/code>, i.e., what’s different in the proposed commit<\/em>. These are changes that are staged for commit<\/strong>. The second is a plain git diff<\/code>, i.e., what’s different in the index\u2014the proposed commit\u2014and the work-tree. These are changes that are not staged for commit.<\/strong><\/p>\ngit status<\/code> tells you, and when you would want to use git diff<\/code> with or without --staged<\/code> to see more than just the names<\/em> of the files. Remember that the changes that git diff<\/code> shows you are what Git is figuring out:<\/em> the files inside the index, or in the work-tree, are full, complete copies. They just may be different from each other and\/or different from the full, complete copy in HEAD<\/code>.<\/p>\n
\n--name-status<\/code> can instead say that a file is added<\/em>\u2014is in the index, but not in the HEAD<\/code> commit, for instance. Or, in some cases, it can say that a file is renamed or has had some other auxiliary change, but let’s not get into this here.<\/p>\n<\/p><\/div>\n