Basics of Git

Published on 2021-05-15

Git is a free and open source (I explain what open source means in this post) source control management (SCM) system originally developed by Linus Torvalds to help him manage the development of the Linux kernel. SCM can also mean source code management and it’s more commonly known as version control. Git quickly replaced existing proprietary solutions such as BitKeeper to become the dominant SCM system. If you need to write or review code (or any text-based file to a greater extent) in a collaborative environment, Git is your friend. In this post, I’m going to go over just the basics of Git and assume that the reader is completely new to the concept of SCM systems.

Why is version control necessary?

In essence, version control or SCM is a system that manages changes to files. Chances are, you have experience collaborating with another person in school or work for a group paper or presentation. You probably didn’t use Git or any SCM system to keep track of changes for this group work, but rather used something like Google Docs or Dropbox to share files with your collaborators. Honestly, I don’t think there’s anything wrong with this approach for simple tasks and projects.

For larger projects with multiple collaborators, however, having a robust version control system in place can save many headaches. Git keeps a record of all past changes to the project such as who made what changes to what file, allows reverting back to older versions or past states of the project, allows modifications to the project without affecting the original and later merging those changes once you are sure of the changes, and much more. I’ll go over some common terminology first.

Common terminology

  • Repository (or repo): where current and historical data of files are stored, often on a remote server.
  • Branch (or fork): branched or forked files may be developed independently of the original copies.
  • Checkout: checking out creates a local working copy of the latest version or specified version from the repository.
  • Clone: cloning creates a new repository that contains all the files and history of revisions of another repository.
  • Commit: write changes made in the working copy to the repository, including metadata about the author and a message that describes the change.
  • Pull: receive revisions or commits from another repository.
  • Push: send revisions or commits to another repository.
  • Working copy: local copy of files from a repository.

Silly example

Let’s say you’re working with a few other people developing the next billion-dollar app. Git is the project manager for this app.

git add

You want to add some new files to for this awesome project. Maybe it’s a new image file or maybe it’s a new script. You tell Git, “hey I have these new files and I want you to keep track of them.” Git says ok and jots down the filenames and their contents.

git commit

After writing everything down, Git just stares at you. You tell Git, “I think these files are good. Can you include them in the official list?” Confused, Git asks, “what are they for?” You give Git a short description of what these files are (commit message). Git creates a record in the project saying that you added the files and why you added them. Git then hands you a receipt.

git push

Git is still standing there. At this point, you’re a little frustrated but you politely ask Git to tell everyone else about the new files. After all, the previous project manager, Dropbox, was eager to tell everyone about any change made to the files (maybe a little too eager). Git says, “They haven’t asked for these yet, but I’ll keep copies in my office (remote repository).”

git pull

A few hours later, you’re curious what others in your team have been working on. Actually, you’re a little worried that you haven’t heard anything from Git about the progress others are making on the project. You call Git and ask for all the updates since the last you spoke. Git looks at your progress and says, “Looks like you’ve been working on files on my list. I can’t update you until you tell me about your progress.” Furious, you yell “Why NOT?” Git calmly responds, “it’s policy.” You roll your eyes, but you add and commit your modified files. You again ask Git for the update. Git frowns and tsks. “According to my records, you made changes to this one file, but Tae also made changes to that file. I’m not an expert so you take a look. I marked where the changes are.” You sigh and look at Git’s notes.

git merge

You look at the changes but luckily they don’t conflict with your changes. You tell Git that everything is good and that these changes don’t conflict with each other. Git nods and merges both changes.

Additional Resources

I hope the silly example above gives you a general idea of how Git works. Mind you, I oversimplified on purpose. At first, Git may seem counterintuitive and annoying to use. However, Git is purposefully designed to require deliberate user input unlike Google Drive or Dropbox. This helps keep track of what everyone is doing and reduce unfortunate mistakes. Below is a list of additional resources for learning and testing out Git for yourself. I promise that Git starts to make more sense once you try it out.