Git 101: A Simple Guide to Understanding How Git Works

Posted on: 27-03-2023by: Jeremy Pitault

Git is a system for managing the versions of files that are shared between different users and computers. The basic idea is to keep track of all the different versions of a file and allow people to collaborate on the same file by merging their updates. If there are conflicts between different changes, Git provides tools to help resolve them.

One of the benefits of Git is that it allows you to keep track of changes to your files over time. This means that you can easily revert back to an earlier version of a file if you need to. Additionally, Git makes it easy to create new versions of your files to try out new features before adding them to the main version.

Repositories, commit, branch… What’s that?

Before we dive into what is Git and why you should use it to manage your project or collaborate with your team, it's important to define a few key terms that will come up frequently:

  • Repository: This is the container for your project that Git tracks. It includes metadata such as the version history. There are two types of repositories:
    • Local: This repository is only available on your local environment. You can use it to test things out and create multiple versions before submitting your work to your collaborators.
    • Remote: This is the repository hosted on a service like GitHub that receives changes from different people. This is the collaborative space that you need when working in a team.
  • Commit: This is a new version of your project. It's important to create commits regularly to have multiple checkpoints across your project's lifespan in case you need to go back to a specific place.
  • Branch: This is a version of your project that diverges from the main version to try out new features before adding them to the main version.

What is the difference between git and GitHub?

Git is a tool that helps keep track of changes made to computer files and enables multiple people to work on the same files. Unlike some other version-control systems, Git does not require a central server to store all versions of the files. Instead, each user creates a copy of the files, including all of the project's history, on their own computer. This copy, known as a "clone," contains all of the information about the original project, while the original files are stored on a server that can be either self-hosted or a third-party service like GitHub.

GitHub is a hosting service that provides a user interface to make it easier for everyone to collaborate and make changes to repositories. It also provides features such as the ability to change settings on a repository, like privacy or third-party application access. Essentially, GitHub acts as a platform on which Git repositories can be hosted and shared, with additional features and functionality.

Git for version control

Git is a powerful tool for version control, enabling you to easily keep track of changes to your code over time. With GitHub, you can go back to any version of a file that you've previously submitted, making it easy to track down errors and bugs. This feature makes Git a valuable tool for solo projects, big company code bases, and open source projects with hundreds of contributors.

In addition to tracking changes, Git also provides metadata for each commit, including the date, commit message, and the author/committer. This information is useful for understanding who made changes to the code and when, which can be important for troubleshooting and collaboration. With Git, you can easily identify who might have made a mistake or caused an issue in the code.

Git for collaboration

Git is the ideal tool for collaborating with multiple people on the same code. It allows you to synchronize your code with other people, while also enabling you to work on your isolated local environment without being affected by their work. How is this possible?

The code is not synchronized in real-time, which means you can choose when to pull the new version submitted by other users to your local repository, and when to push your commit to the remote branch/repository so that it's accessible to everyone else.


It's important to note that the local repository is a copy of the remote repository, which represents the history of all versions. It's different from the working directory, where you're coding and making changes. We'll cover this more in the workflow section.

Does that mean that I can push whatever I want to any public repositories?

Not really. A huge principle in the collaborative aspect of git is the ‘pull request’

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

In other words, before merging your work to the remote repository, a discussion will be opened for other contributors to review your work and decide whether or not it can be integrated to the common repo.

Git Workflow

The 4 different states

When you're making changes to your files in Git, those changes go through different stages before arriving at the final remote repository. There are four different states to be aware of:

  1. The working directory: This is where you make your changes to the files.
  2. The staging area: This is where you add the changes that you want to commit. You might only want to commit changes to one file, for example, and this is where you can specify that. To add a file to the staging area, you can use the command git add <filename>.
  3. The local repository: This is your own local version history. When you create a new version of your project with the modifications you've added to the staging area, it's called a "commit." The command to commit the changes in the staging area to the local repository is git commit.
  4. The remote repository: This is the collaborative place hosted on a service like GitHub. It's the top-level state of the Git workflow. This is also a good place to keep a backup of your repository in case your machine has a problem, or if you want to access your work on another machine. To push your commit from the local repository to the remote repository, you use the command git push.

A few other useful commands you need to know

While this post isn't about how to use Git, here are a few commands that can help you understand how Git works and give you a quick overview of what's possible:

  • git init: This command creates a local repository in your project folder.
  • git clone: This command clones an existing repository, whether it's local or remote, to another location. You'll use this command to start working on an existing project or if you want to start your project with a boilerplate hosted on GitHub.
  • git status: This command displays the state of the working directory and the staging area. It's super useful if you want to double-check the changes you've already added to the staging area before creating a new commit.
  • git fetch: This command gets the latest version of the remote repository to your local repository. The new version won't be available in your working directory.
  • git merge: This command gets the files from the local repository into your working directory. You can also use this command to merge different local branches together. You can find more information on this command here: [link to more info on merging]
  • git pull: This command is a shortcut to git fetch
    • git merge. It pulls the files from the remote repository to the working repository.

What’s next?

Now that you have an understanding of what Git is and how it works, you may be interested in learning how to use it. Here are some good resources to help you get started:

These resources provide step-by-step instructions and explanations to help you learn Git quickly and easily. Whether you're a beginner or just looking to refresh your knowledge, they're a great place to start.