191: Git: Keep Track Of Your Files As They Change. Part 6.

Programming involves change and managing that change is the only way to make sense of it. You’ll learn about the staging area in this episode and how that affects your commits. Git actually has three areas where it keeps your files. The most visible of these is called the working directory. The second area is the staging area. This is where files go when you add them and before they get committed. The third area is the archive area. I’m not sure if this area has an official name or not so that’s how I refer to this area. This is the area where Git holds all the versions of your files as they existed through each commit. Every time you commit changes, you’re updating the archive area with the latest changes. And the archive area continues to hold all the older versions of your files. Listen to the full episode to learn more especially how to avoid committing empty files that you create through your integrated development environment. You can also read the full transcript below. Transcript You’ll learn about the staging area in this episode and how that affects your commits. Normally, you don’t have to worry about the staging area. But some aspects of Git will be confusing without this understanding. Imagine the work you do by changing your files as if you were packing bags for a trip. Now you could take each bag out to your car right away but that may not be the most efficient way to load your car. It’s better to leave each bag where it is first and then take them all out to a loading area where you can then load them into your car. In other words, you stage them or prepare them first before finally loading them. Git actually has three areas where it keeps your files. The most visible of these is called the working directory. This is the area you see when you browse your files and is where you can open them and make changes to them. This is the area that you’re used to. When you check out a different branch, this is the area that gets updated with the files that match that branch. Many people don’t even think about the other two areas in Git. The working directory is so visible and is where you do your work that many people don’t even consider the possibility that there could be other areas. The second area is the staging area. This is where files go when you add them and before they get committed. When you create a new file in your project, it’ll initially show up as an untracked file in your working directory. You tell Git that you’d like to track changes to this file by adding it. What actually happens is that adding the file makes a copy of the file in your staging area. This is enough to let Git know that the file is tracked even though it hasn’t yet been committed. The third area is the archive area. I’m not sure if this area has an official name or not so that’s how I refer to this area. This is the area where Git holds all the versions of your files as they existed through each commit. Every time you commit changes, you’re updating the archive area with the latest changes. And the archive area continues to hold all the older versions of your files. Now, these areas can get confusing when a file exists in more than one at the same time. Let’s start out with the simple case of a new file. The new file will exist in your working directory. If it’s someplace outside of your working directory, then it doesn’t relate to this Git repo at all. Git only works with files that are anywhere inside the directory structure of your project repo. Okay, so you have a new file. If you run the command “git status”, then Git will tell you that there is an untracked file in your working directory. Any commit you make at this point will not affect that file. It will remain untracked. And if you delete the file, then it’s gone forever as far as Git is concerned. That file will not be found anywhere in your Git h