Compare and contrast local and remote repositories
Git is a distributed system where the source code is located on every developer's machine. This includes the complete history with all commits ever made on that project. This is called a local repository.
This allows the developer to work in their own isolated environment without worrying that someone will break his code while they are still developing a feature. It also allows you to compare code with previous versions, rollback code, merge code, and so on. You can even do this without a network connection.
Most of the work a developer will do with Git will be done on a local repository. Git supports (and facilitates) branching. Branching will be discussed in a separate module, but most branches will be created on a local repository as well.
In a later phase, you need to share your modifications or new features with the development team. Therefore, Git uses a remote repository. A local repository can also be linked to multiple remote repositories if needed. The remote repository is used to easily share code with other team members, but also to set up build pipelines. These pipelines build the code that is pushed to the remote repository. A push can be the trigger to start the pipeline.
Local repository
In the local repository, we can distinguish three different areas or directories.
Working directory: This is a single checkout of one version of the code. The working directory will contain the code you are actively working with. You can change the files by using the checkout command. Each time you change the active working branch, the files in your working directory will be changed to resemble the specific version of the code. The files you can see in your Windows Explorer are files within the working directory.
Staging area: This area is used as an area between your working directory and the Git directory. Before you can commit a file from the working directory into the Git directory, you first need to stage that file. The file is then, as is, marked for the next commit. You can continue to work with the file. All modifications to that file, that are not staged, won't be added with the next commit. Only the content of the file that is staged will be added. This is useful if you are working on a feature, but you're not completely finished yet. You can stage your modifications and continue to work. If you need to commit at the end of the day, you can still commit a working version (the version from the staging area), without the risk of committing a half-developed file.
Git directory: The Git directory contains all the metadata and the object database. Each file you commit to the Git directory will be stored within this directory. If you enable Hidden items within Windows Explorer, you will see a hidden .git folder. This folder contains subfolders with the objects, but also with pointer information. If you delete this folder, your local Git repository is gone. This makes it also easy to put your local repository on a USB drive and take that with you and use it on other computers. Do not mess with this directory or your local repository will be broken. This is also the directory that will be used to synchronize with the remote repository.
By using this setup, a file within Git can be in one of three stages.
Not modified and stored in the Git directory: the file is committed.
Modified and in the staging area: the file is staged.
Modified and not in the staging area: the file is modified.
Git file lifecycle
In the next schema, you can see the complete lifecycle a file can go through. The first time when a new file is created or added to a folder within your Windows Explorer, the file will get the untracked status. This file is not part of the Git lifecycle. Use the add command to add this file to the staging area, where it will become staged. Later you can use the commit command to add the file to the Git directory. Then the file will get the status unmodified. Whenever you edit a file the file will get the modified status, or untracked when you remove the file from the Git directory. You use the rm command to remove a file. Removing a file from the Git directory doesn't mean the file is also deleted on disk. This is an action you as developer have to do manually.
Remote repository
The remote repository is then used via push and pull commands to synchronize with your local repository. So, even when you are sharing code or getting updates from your team, it is done from commands that update your local repository. Because each repository is self-contained, the owner of the repository is responsible for keeping it up to date with changes from others.
In the next schema, you can see how two developers can use the remote repository to share modifications. Developer A is committing changes to the local repository and uses the push command to upload modifications to the remote repository. Developer B can use the pull command to download the modifications and can push modifications.
