A beginner’s guide to Git (and version control software)

10 min readMar 23, 2023

What is Git?
Getting Started
Initialising a Git Repository
Adding and Committing Changes
Linking your repository to GitHub
Branches
List of Commands

Git is a great tool for anyone who dabbles with code. It is often used for version control for both individual users and teams. When I started learning git, I found all the commands a little overwhelming to get the hang of.

If you’re new to Git, this article will help you understand the basic commands of Git and walk you through the processes and scenarios of each command. If you are somewhat aware of Git and its uses, I’ve written a quick overview near the end of this article describing each command mentioned and its general use cases.

If you don’t understand everything in the first pass, I don’t blame you! Just take your time and digest at your own pace.

But first of all, what is Git?

Git is a free and open source version control system. It logs progress changes made to your code folder (or your repository) as they change over time. Each different progress change is a version of your software. Each repository has commits that show a specific version of the code you have written.

Git allows you to revert back to a previous commit if something drastically wrong happens. If you accidentally committed something that crashes the whole system, the system can revert to a previous commit instead of trying to pinpoint the new code that has caused the crash.

Version control is also good in the case that new features that were implemented may be unnecessary for the scope of the project and does not fit the requirements. In that case, reverting to a previous version without the extra functionality ensures that all the code works instead of looking for every little bit of code that mentions the new unnecessary functionality.

Getting Started

First of all, you need to have git installed. Some computers may have it installed already. To check if you have git installed, open your terminal and type:

Git version on Windows

Git version on MacOS

If the result comes up along the lines of “git is an unrecognised command” — you don’t have git installed and need to download it. You can download it from here and follow the instructions on the website. Make sure to download the one compatible for your system!

Now that we have git installed, we can start playing around with it!

Let’s first make a new folder. I will make mine on my desktop under the folder name myProject .

Open git bash or your terminal and navigate to the folder you just created. cd <path-to-folder>

As a test, create a small file with some code in it. I’ll add the following python file to my repository as HelloWorld.py

print("Hello World!")

Save it to your folder. This is all that we will do with this file for now.

Initialising a Git Repository

Now to get on with the actual git portion. Let’s first initialise a local repository on our machine.

Make sure you’ve navigated to the folder where your code is. In my case, I would do cd ./Desktop/myProject before typing in:

git init

This initialises a new git repository in our folder. If you have hidden folders enabled, you may see that this creates a .git file in our folder. This folder stores all the information about our repository.

This might be a little strange — we’ve initialised a repository, and there are things in the folder, but why aren’t the things in the folder automatically added? This is a great question and it is fair to ask since it seems counter-intuitive. My answer is not definite, but the reason I think that this doesn’t happen is because it gives the programmer flexibility on the “version control” aspect of the project — you might want to add specific parts of the code first as one version before adding something new to the repository, or you may initialise the repository while you’re halfway done with one aspect and don’t want to add a “broken version” to one of your commits.

Having a broken version is generally bad because if you need to fallback on a previous version, you don’t want to check to see if the version you’re falling back on also fails — you want to ensure that the previous version worked and is a foundation you can build up more code from.

Adding and Committing Changes

To add the file to the repository, simply type:

git add <filename>

This adds a file to the current commit. Note that it doesn’t immediately add it to the repository. This is so that you can add a few things in succession instead of updating the repository one file at a time. Staging it to a commit to commit a lot of files at once can categorise your changes.

If you want to add all changed files to your commit, you can type in

git add .

This command only adds the changed files of your repository, so any untouched files won’t be added to your commit.

To make changes to the repository itself, we want to commit the change. But before we commit, sometimes we should make sure everything we want to commit is added. We can do this by typing in git status

We can see that one of the changes to be committed is helloWorld.py

Everything seems to be fine! We can safely commit now.

git commit -m "Commit Message description"

This adds all the files that we added in the previous stage to the repository. They will be labeled with the description you gave in the commit message.

If you’ve accidentally added a file to your commit when you didn’t mean to, you can run git rm --cached <file path> to remove it from your next commit. This will keep your file on your system. Removing the --cached flag will remove the file from your disk.

Linking your repository to Github or Bitbucket

Now that we have initialised our local repository and made our first commit, it’s time to link it to our cloud repository so we can share our code. This could be GitHub or Bitbucket, or anything else that’s similar. For this article, I’ll walk through the steps using GitHub, but it will be similar for other websites.

To do this, we will first make a new repository on Github. Log in and create a new repository from the new button underneath the search bar.

Fill in the details — give your repo a name and description. Make sure you do not check “Add a README file” when creating your repository. You can choose to make it private or public for others to see.

Once you’re happy with the settings, create the repository. You should see a screen somewhat similar to below.

We’ll follow the section in the latter code block.

git remote add origin https://github.com/Bombearo/SampleGitRepository.git
git branch -M main
git push -u origin main

Replace my URL with the URL of the repository you created.

git remote add origin <repository url>

This links our local code to our GitHub repository. Our repository now looks like this.

Updating your GitHub repository vs your local repository

You may have noticed in the last section of the block, there’s a command called git push . This is the command that lets us update our commits to our online repository. -u signifies that we want to set the branch name after it as our upstream branch. This upstream branch will become the default branch argument in later calls of git push. After setting an upstream branch, you don’t need to pass in any arguments to git push to push to your repository as shown below.

git push

Any code you commit in your local repository will not be added to your online repository until you run git push .

The three most used steps for anyone using Git is

git add
git commit
git push

in that order. Whenever you make changes, you add it to a commit. Once you’ve made all changes that are relevant to a specific commit and added them, you commit with a meaningful message, and then you push to the repository after a few commits.

This may take the form of:

Create/Update files relating to logging in
Add files to commit
Commit files as “Login functionality”
Do the same for registering
Push to GitHub

Branches

Branches — while not something a beginner needs to know- are very useful tools when using git while collaborating as a team.

Imagine everyone on your team was typing up a document, but you only had a single document and a single line to type on. If you all started typing on it at once, it would be hard to keep the sentence coherent or avoid stepping on each others toes. It would be much easier if you had the space to work on a paragraph each on different lines.

Branches are sort of similar to this. You can view each branch as a building block for your whole code — each branch can be dedicated to specific functionality and later added back into the main code. It’s like typing up your part of an essay somewhere else and pasting it into the main document later on. This is essentially what branching and merging is in git.

In Figure 1, the blue signifies the main branch, and the purple can signify your work. This work is independent to the main branch and can be added back later. Similarly, the green is someone else’s work and can also be merged back onto the main branch later on.

To create a new branch, you can either use the command git branch <branchname> or git checkout -b <branch name> . The first option requires you to run two commands (see below) to switch to the new branch, but the second option only requires that one command to create and switch to the new branch.

git branch <branch name>
git checkout <branch name>

To see all the branches available, type git branch --list .

Other miscellaneous commands

When working with a team, sometimes you need to work with changes that others have made. If your team has existing code on your online repository, you can clone it onto your own machine using git clone <repository url> . git clone directly links the new downloaded repository with the online repository you downloaded from, opposed to a different command called git fork which makes an independent copy not linked to the shared repository on your machine.

Sometimes the online repository may be updated and you need to gather the new changes. Running git pull origin <branch name> will download and update all your files that have been changed on the specified branch. An alternative is git fetch origin <branch name> which only downloads newly created files, but does not touch your existing files on your machine. If you are working collaboratively, make sure to pull often so that you’re not trying to write code that has already been written by someone else!

And that’s about it for a somewhat brief description of the main git commands people tend to use from my experience! Below is just a summary of the use cases of each command I described above.

Quick-Fire git commands (All done in the root of your code folder)

git init — initialises a git repository in the current folder
git add <filepath> — Stages a file to be committed in your next commit (git add .to add all altered or new files to the commit)
git commit -m "Description of changes" — commits your changes as a commit — this is a new version of your software
git push — pushes your commits to your remote repository on the current branch (git push origin <branchname> to push changes for a specific branch)
git pull origin <branch name> — Retrieves the latest changes made from the specified branch name. The-u flag works here to set a default branch to pull from. Do git pull --all to pull all changes from all branches
git fetch origin <branch name>— Retrieves any new files created in the specified branch name, but does not update code in existing files. The-u flag works here to set a default branch to fetch from. Do git fetch --all to fetch all changes from all branches
git checkout -b <branchname> — Creates a new branch with name “branchname” and switches the current branch to the newly made branch
git remote add origin <repository url> — Sets up communication between your local repository, and your cloud repository (Github or Bitbucket)
git rm --cached <filepath> — Removes a staged file from a commit but keeps the file on your system.
git clone <repository-url> — Clones a repository onto your machine
git checkout <branch name> — Changes the current branch to the branch name
git status — Check the status of your commit
git log — View your commit history

Contact me if you have any other questions!📩

Hi! I’m an 20 year old student who’s a huge computer science, programming, maths and music geek!

If you enjoyed this article, feel free to give me a follow. I plan on writing more articles to explain harder concepts in a simple fashion.

Feel free to follow me on Github where I’m working on my latest projects, or find me on LinkedIn!

If you have any more questions you can contact me on:

🎈Github

🎈LinkedIn