1.2 Git Basics: States

Understanding States in git unlocks the whole magic I think. Once this topic is demystified, begin the should have an easy time to pick up more advanced features of git. To me it really is the puzzle piece that ties everything together any file can be broken down into one of four hats committed, tracked, untracked and ignored files. The main three states, the ones that are most important for your day-to-day work fall into the category of tracked files, unmodified modified, and staged files. This is git's bread and butter and what you will deal with most of the time. Untracked files are simply files in your working directory that are not part of your git repo yet. Git will only notice them being around, when we dig a little deeper we will find ignored files and committed files as well. Let's start here, committed files are in the cryptographically hashed state. They represent a very efficient format for storage in case you are unsure about their whereabouts. They are stored within your .git directory. Unsurprisingly, the .git directory is where the real action is. When you initiate a new git repo with the git init command, you create a database for git objects and their metadata. The files placed in such commit objects are in this cryptographically hashed state. Long story, very short, your files have been run through a mathematical function and end up as being 40 character long hashes that represent all the information your files consisted of. Every little change to these files result in a new unique hash when you commit these changes. When you clone or fork a project, this cookie directory is what you are getting. Your git history, your snapshots are represented mainly by get objects. This hashed state is sort of the end goal of any file that is relevant to your version control system. Since this hashed state is really hard to read or manipulate get then populate the index in the working directory with the relevant versions so that you can continue your work. Untracked files can be of different origin. For example newly created files that haven't been staged and committed yet or files that have been removed from version control These files are only noticed by gits but are not part of your database of version control thoughts. The git status command shows your list of untracked files to remind you to possibly at them to your report. Unless they are part of the .gitignore file of course, then they wont show up. Files that have been added to your that .getignored file are also untracked of sorts. By ignoring certain files, git goes one step beyond. The get status command does not show any changes to these files at all. It simply disappears from git's radar, sort of a silenced on tracking. Back to the most important bits, the states of tracked fights unmodified, unmodified and staged fights they mirror the possible states for the working directory and the index. Their main purpose, is to prepare new commits. The working directory represents either unmodified or modified files. Modified files are sort of work in progress versions. Once they are committed the state changes back to being unmodified. Stage files are being prepped to be placed into a new commit snapshot. The whole purpose is to build up cohered commits. They give you an opportunity to slice your changes into atomic commit objects that tell a story. Staged files help you avoid dumping a Bunch of unrelated changes into one big bucket. Once a file has been placed into a commit object the respective file in your working directory is considered unmodified. That means that the hash version from your last commit and your working directory mirror each other exactly. Let's close with the bigger picture about the transition of untracked file to its cryptographically hashed version. You can view these various states of files at successively better states, better of version of files before becoming git objects in your .git directory.