by Aishik Nath | 10 min read

Table of Contents

<aside> 💬 If the article is too long for you, I request you to read the Summary (TLDR)

</aside>

Recap

In the last issue (March 2024), we learnt about the absolute basics of Git and GitHub. How to set up a repository. How to clone it. How to stage files. How to push your changes to the remote repository. I also asked you to explore a few git commands like git pull, git rm, and git log. This issue will explore all those new commands and many more in detail. But first let’s learn some history, again.

Why was Git created?

Before Git, there used to be tools called Centralized Version Control Systems (CVS). They had a single server that contained all the versioned files. The users would simply check out files from that central server. But this system had a very obvious downside - a single point of failure. If the server went down, no one would be able to save versioned changes to anything they had worked on. All the collaboration would be shut off. If the storage device on that server gets damaged or corrupted, the entire history of the project other than the snapshots the clients have on their local machines would be lost forever (unless a backup was kept). This is where Distributed Version Control Systems like Git came in. Here, all the clients fully copy the repository including the whole history and all the versions of a file. If the central server ever goes down or gets damaged, any of the client repositories can be copied back up to the server to restore it. Git is one such Distributed VCS, but is built with philosophies entirely different that the other VCSs present at that time.

Git was designed with the following goals in mind:

1. Speed
2. Simple Design
3. Strong support for non-linear development (using branching)
4. Fully distributed
5. Able to handle large projects efficiently.

Unlike other VCS available, Git stores what all your files look like every time you commit, and keeps a reference to that snapshot. If some files have not changed, they are not stored again; only a link to a previously saved identical file that git had stored is saved. So all commits save how all of your files look like at that moment, but without re-storing every file - thus increasing efficiency.

Storing data as snapshots of the project over time. Picture taken from the book Pro Git by Scott Chacon and Ben Straub, Apress Publications.

Are the files on our computer up-to-date?

Last time we used the git status command but without exploring it much. So in this issue we look into it a bit more. git status shows if the files on your computer are up-to-date, ahead or behind or both behind and ahead of the files in the remote repository. Yes, both behind and ahead. That’s an oxymoron but it can happen as it seems. In the directory of the repository that we were working on in the last issue, let’s run this command.