Repositories and Staging

At the end of the day, especially because this tool is developed by Unix enthusiasts, everything involved in using Git is a file. Git itself is version management for files after all. This means that it becomes important to understand where the files for a project are, and how Git will be manipulating them. There are 4 main zones/concepts when it comes to file manipulation: the working directory, the staging area, the repository, and the stash.

Working Directory

When you edit files you are editing them in the working directory. The working directory is where you, the developer, are doing work. It is just the raw source code files which Git is trying to track. The working directory is also what Git considers to be "non sacred" in the sense that the working directory can be easily manipulated by the program. Checking out an old version/commit, for instance, will alter the entire working directory to the state of the project in that commit. Deleting files from git will remove them from the working directory. Pulling changes will also impact the working directory.

Staging Area

Outside of your working directory, but not yet stored in the history of the project, is the Staging Area. Due to the fact most programs are comprised of many many files, several of which may be impacted in a single commit/version, a versioning system like Git will need to know what is actually being put into the next commit/version. To do this, Git has the Staging Area, which tracks the files that will have their revisions in the next version/commit. This is separate from the working directory in that the files inside the working directory are untouched by the Staging Area. Instead, it would be more accurate to say that you copy changes from the Working Directory into the Staging Area before solidifying them with a version/commit.

Repository

The repository is the primary structure which is managed entirely by Git. The repository keeps the history of all commits/versions, their authors, their relations, branches, comments, reversions, etc. The repository is the thing the Git tool builds around, and is the timeline of changes you are operating. When you make a commit, you take any changes you have put into the Staging Area, bundled them into a new version based on a previous version, and put that version/commit into the timeline of the repository.

Repositories are local first, and made on a project by project basis. This means that when you use Git you are using a repository that exists only for that project only on the computer you used Git on. If you want other computers to be able to access changes in the repository, we use a "Remote Repository" (most often from a Forge), which exists to be a shared point of truth for other repositories. When a Remote Repository is added to a project, it means that your local repository will be able to download any changes made to the remote repository, and upload any changes to the remote repository, which can then be downloaded and uploaded to other Git users using that remote repository. Effectively, a Remote Repository is one you share with other devices (including other people), and you sync changes between it and your local computer frequently.

Stash

The stash is a quick and easy way to keep changes from the working directory while moving around the repository. When changing positions in the Git timeline, the working directory is updated to reflect the contents of the version you are switching to. In this process, and work done in the Working Directory which has not been put into the Repository itself would be lost permanently. To prevent this situation, you are provided with the Stash. The stash is a place to store changes made to files outside of the Repository, so that those changes can be brought back out of the stash later. They do not exist in any version, and are just saved on the specific device which stashed them. You'll mostly be encountering the stash when you have unfinished business while swapping between branches.