A slightly longer post today but itâs important that the basics of git are covered. My first suggestion is to think of git as tracking _content_, not files. In the coming days Iâll cover the way that Git stores information and this should become a lot clearer. But it helps to realise that the contents of a file and the name of that file are not kept in the same place. Secondly, Git only tracks changes files that you tell it to track. I think of Git considering this content in 4 places. Hereâs a simple diagram  This is a simple view of the four buckets. Iâve shown the simplified commands that move content between these buckets (leaving off the extra flags and parameters for simplicity). ##Commit This is the frozen state of the files that git is tracking at the time that it was created. These are the objects that are actually stored in a repository and are shared with other repositories ##Index This is the staging area for commits. This is the state of the tracked files that will be used to create the commit. ##Working tree This is the area where there are changes to tracked files, but these changes have not been added to the index and will not become part of the next commit. This needs some explanation. When you create a new repository, and as you add and remove files from your project, you need to tell git about the files that it is supposed to track. But that doesnât mean that these filesâ changes will automatically become part of a commit. The changes need to be in the index for them to become part of the commit. Some people donât like having two steps to commit a file.But you donât need to because `git commit --all` will take all changes to tracked files and make a commit from them in one step. Because branching, merging and changing history are easy with git, it encourages you to make many small commits rather than one large commit. So, imagine the scenario where you are working on a feature and add those changes to the index with `git add`. You can now make other changes to your files. If you think these changes are significant enough to go in their own commit, you can commit the changes that are staged in the index and then add the new changes to this index. Or, if you think you want to make all these changes one commit, just use `git commit --all` and the new changes and the staged changes will all become a single commit. When starting out with git, itâs easy to forget that all changes are not automatically made into a commit. So remember [yesterdayâs](http://365git.tumblr.com/post/470426947/) post about amending commits which will help to fix these ommissions. ##Untracked files If you add new files to your project they are not tracked by git. If you run `git status` youâll see that these new files exist and that they are not tracked. This is a reminder that these may need to be added. Of course, there may be good reasons not to include a file, and if you donât want to be constantly reminded to add the file, you can ask for it to be ignored. (Iâll cover this another day.) ##Summary Git tracks content in 3 places and doesnât worry about anything it doesnât track. You can move files between these areas, and if you use `git status` not only does it tell you what files belong to which area, but also how to move them out of those areas.
