11.4. The Git Workflow¶
Using a Git repo involves the following steps. First, you create the Git repo by running the git init or git clone command. Second, you add files with the git add <filename> command for the repo to track. Third, once you’ve added files, you can commit them with the git commit -am “<descriptive commit message>” command. At this point, you’re ready to make more changes to your code.
You can view the help file for each of these commands by running git help <command> , such as git help init or git help add . These help pages are handy for reference, although they’re too dry and technical to use as tutori- als. You’ll learn more details about each of these commands later, but first, you need to understand a few Git concepts to make the rest of this chapter easier to digest. ## How Git Keeps Track of File Status All files in a working directory are either tracked or untracked by Git. Tracked files are the files that have been added and committed to the repo, whereas every other file is untracked. To the Git repo, untracked files in the working copy might as well not exist. On the other hand, the tracked files exist in one of three other states:
The committed state is when a file in the working copy is identical to the repo’s most recent commit. (This is also sometimes called the unmodi-fied state or clean state.)
The modified state is when a file in the working copy is different than the repo’s most recent commit.•
The staged state is when a file has been modified and marked to be included in the next commit. We say that the file is staged or in the stag-ing area. (The staging area is also known as the index or cache.)
Figure 12-4 contains a diagram of how a file moves between these four states. You can add an untracked file to the Git repo, in which case it becomes tracked and staged. You can then commit staged files to put them into the committed state. You don’t need any Git command to put a file into the modified state; once you make changes to a committed file, it’s auto- matically labeled as modified.

Figure 12-4: The possible states of a file in a Git repo and the transitions between them
At any step after you’ve created the repo, run git status to view the current status of the repo and its files’ states. You’ll frequently run this com- mand as you work in Git. In the following example, I’ve set up files in differ- ent states. Notice how these four files appear in the output of git status :

In this working copy, there’s a new_file.py 1, which has recently been added to the repo and is therefore in the staged state. There are also two tracked files, staged_file.py 2 and modified_file.py 3, which are in the staged and modified states, respectively. Then there’s an untracked file named untracked_file.py 4. The output of git status also has reminders for the Git commands that move the files to other states. ## Why Stage Files? You might wonder what the point of the staged state is. Why not just go between modified and committed without staging files? Dealing with the stag- ing area is full of thorny special cases and a large source of confusion for Git beginners. For instance, a file can be modified after it has been staged, leading to files existing in both the modified and staged states, as described in the previous section. Technically, the staging area doesn’t contain files so much as changes, because parts of a single modified file can be staged and other parts unstaged. Cases like these are why Git has a reputation for being complex, and many sources of information on how Git works are often imprecise at best and misleading at worst.
But we can avoid most of this complexity. In this chapter, I recommend avoiding it by using the git commit –am command to stage and commit modi- fied files in a single step. This way they’ll move directly from the modified state to the clean state. Also, I recommend always immediately committing files after adding, renaming, or removing them in your repo. Additionally, using GUI Git tools (explained later) rather than the command line can help you avoid these tricky cases.