Skip to main content

Command Palette

Search for a command to run...

Git for Beginners: Basics and Essential Commands

Published
5 min read

What is Git and why is it used?

Git, created by Linus Torvalds in 2005, is something we call a version control system or VCS. Now what is a VCS, you may ask? A VCS is a software tool that helps manage changes to source code (or any data) over time.

Git is a system that tracks changes to source code over time.

In basic terms, Git helps us store what changed, who changed it, and when it changed. It even allows us to revert to a specific “version” of the code or file if needed (often done if any change ends up breaking the code!). It also allows collaboration with multiple developers, and gracefully manages simultaneous changes to the same code. If you want to understand why we even need systems like Git, read my other article here. It is an industry standard as almost every software organisation uses a platform that uses Git, most famously Github, and a few others like BitBucket, GitLab, etc.

Basic terms

  • Repository (Repo): This is the folder that git tracks. It contains your project files, and also Git’s metadata and history. Any folder in your system can be made into a Git repo by running the command git init inside it.

  • Branch: It is like a separate workspace where changes can be made without affecting the original codebase. Branches can be a new version of a repository, experimental changes, or personal forks (refer below) of a repo for users to make and test changes. The default or top level branch is usually the main (or master) branch. Other branches (usually called feature branches) can be created from main.

  • Commit: If you’ve ever played video games, you can think of it as a save game. It saves your progress at a point in time. If you are WASTED (if you get the reference, we’re friends) at any point in the game, latest save game is loaded. Similarly, a commit is a snapshot of your project at a specific point in time, with a message describing what changed, and who changed it. You can always go back to a previous commit if you need to (in case anything “breaks”).

  • HEAD: It is a reference to your current position in Git history. By default, it points to the latest commit of the current branch. So, if you make a new commit to the same branch, the HEAD will point to that commit. You can even switch to a different branch, then the HEAD will point to the latest commit of that branch.

  • Fork: A copy of any repository, usually done to make your own customised version or build on top of that codebase.

  • Checkout: Refers to switching between branches in a repo. Syntax is: git checkout <branch-name>. So if you hear someone say checkout to main or checkout to feature-a, they’re telling you to switch to that branch.

  • Push: Updates a remote with the commits made to the current branch using the git push command. You are literally "pushing" your changes to the remote.

  • Pull: Simply means retrieving updates from remote into your local environment. Usually done with git pull command, which is technically git fetch + git merge. In short, git fetch downloads new changes, git merge applies those changes to your local.

  • Remote: A copy of the original repo. It simply points to another “version” of the repo, which usually resides on a server like GitHub. So if you create a repo on your machine, that is your local repo. You then push it to GitHub, then that repo becomes the remote. This repo will be used by you and other collaborators to push and pull changes.

  • Origin: The default name for the primary version of a repository. Git also uses origin as a system alias for pushing and fetching data to and from the primary branch. For example, git push origin main, when run on a remote, will push the changes to the main branch of the primary repository.

Git workflow

The above figure roughly represents how git organises your workflow. There are three main areas:

  1. Working directory - where your files reside and you make changes

  2. Staging area - where you prepare changes for committing

  3. Repository - where Git permanently stores commits

Essential commands

  • git init: Initialises git in your project folder. This creates a .git folder within your project folder that git uses to track your content. If you want to know more about the .git folder, read a part of my other article here.

  • git add: Adds files you want to track in the “staging area”, which means that you intend to commit these files. Syntax is git add <file-name> but usually use git add . to add all files in the workspace to the staging area.

  • git commit: Creates a snapshot of the staged changes. Once you commit, the changes/files are ready to be pushed to remote. Syntax: git commit -m “commit-message”. The commit message is a short and meaningful description of the changes.

  • git push: Pushes your changes to the remote.

  • git branch: Lists all branches

  • git status: Shows the current state of the repo like which files were modified, which ones are new, what changes are staged, etc.

  • git log: It shows the commit history of the repo, which includes commit hash (unique ID), author, date, commit message. Below is a rough representation of how commits work and how commit history may be shown.

Basic Git workflow

This is a follow along so that you can make your first git commit! All commands will be from terminal (cmd or powershell for Windows).

  1. Create a new project: You can create a new folder anywhere on your system and go into that folder.

mkdir new-project

cd new-project

  1. Initialise git: git init

  2. Create a file: touch index.html

  3. Check status: git status

  4. Add file to staging area: git add index.html

  5. Commit changes: git commit -m “add index.html”

Congratulations! You’ve just made your first git commit.