This git guide for beginners teaches how to get started with git as a complete beginner. You will learn how to create git repositories on your local machine and also on remote servers and platforms like GitLab and GitHub.
It even features exercises along the way to get more hands-on and a bigger one at the end of the article.
I also made a video explaining git:
What is git
Git is a source code version control system used all around the globe together with GitLab, GitHub or other tools. But what is what?
It is the software behind everything (GitLab, GitHub, git bash, etc…) and is very powerful. Most of the time you won’t need every feature from it but just the main features and commands like:
clone, add, commit, pull, push, merge, rebase
The code is structured in repositories on which you can perform these actions. Repositories are kinda like projects or group/parts of projects that belong together.
Git allows you to go back in time, create different versions and work simultaneously as a team on a project.
You’ll learn how you can do this in this article. For that, we’ll need to know some basic commands and how to host the repositories on GitHub or GitLab.
Also you’ll need to have git installed. There are graphical tools and command line tools available so make sure to get what suits your needs and style the best.
I’ll use the command line, but most commands have similarly called buttons in GUI software.
What are GitLab and GitHub
- Liking/Starring projects
- Create Issues/Bugs on existing projects
- Manage Code Reviews
- Trigger Pipelines and automatically test, deploy and release your project
It’s kind of a social network, but for code, that uses git in the background. I will go into more detail on what you can do on those platforms in a future post.
For this post, I’ll just get you started with the basics like creating repositories and working with them (
pull & push).
Basic git usage
When working alone with git, you will usually use it to manage different versions of your code (and maybe have a stable release/version). For this, you will only need the most basic commands.
Make sure to follow the steps, since we will need the repository in the later steps.
This command is used to initialize a repository. You want to perform this action in the root of your project.
The project root for a Web App is shown in the figure above. You can of course initialize the repository in this directory or create a repository for each part of your project (eg. create different repos for server, infrastructure, client, etc…).
I prefer to have everything that is part of the same project in the same repository (more or less). But the taste differs. You will find and use what suits you the most.
Exercise #1: Create a repository
- Create a new directory called
- Enter the directory
- Initialize a repository (with the
Once you initialize a git repository with
git init you can then add the files to the repository and commit them.
add and commit
git add git commit [-m "message"]
Just because a file is in the same directory or subdirectory of the repository, does not mean, that it is already part of it.
Similar to a mise-en-place when cooking, the ingredients are there, but they are not in the food.
To “track” a file (or put it into the dish, when talking about cooking) you need to first add it to the repository.
This is how it will look like, if you create a file, but don’t add it.
Also tools like VSCode will show you that the file or changes are not tracked:
You can simply add the file to the repository with
git add <filename> and the changes will be tracked:
They will also be shown as “staged” in tools like VSCode:
Once the files are staged you need to commit them (with a message). I usually prefer to write the message directly as part of the command with the
-m param (otherwise it will open a default editor, which will mostly be vim):
(If you happen to forget
-m and open vim by accident -> press ESC and enter
:wq! to exit)
The message given with
-m is what you will see on platforms like GitHub/GitLab or even with git log:
The message should preferably be short and concise, but you can add a new line and add a more detailed description of your commit.
It’s a good practice using a format called “conventional commits”, which helps you create more useful messages. They look a little something like this:
fix: removes refresh bug
Exercise #2: Make your first commit
- Create a file called README.md
- Add the following text to it:
This repository is part of the git tutorials for beginners from https://d3vnull.com/git-for-beginners
- Save the file
- Add it to your repository
- Make a commit with the staged file and a message following conventional commits (eg.
docs: adds readme)
If you will just work locally, you won’t need more commands most of the time. But the real power of git comes with the capabilities to work on remote code.
Remotes: GitHub and GitLab
GitHub and GitLab are similar and have similar functionality. We will cover the basics of setting up a project/repository and how to connect it locally and even push our first couple of commits to it.
You can use either one for this guide. Just choose the one you find more appealing as it doesn’t matter which you choose right now.
Setting up a project
Setting up a project on these platforms is pretty simple. You need to create a free account (or login with google, Facebook, etc…) and then you can get started:
Exercise #3: Create a GitHub or GitLab project/repo
- Follow the instructions from above and the website.
- Enter the name
- Make the repo public
- Leave the rest as is.
(public repos are free, btw: repos is short for repository)
Get the git repository to your local machine
Now it’s time to get your repository on your machine, so we can start working on it!
GitLab and GitHub each show you, how you can clone/pull/push to the repository once you clicked create.
You will have two options most of the time:
- Create a new repository locally
- Add a remote to an existing repository
You’ll go with the first option, if you haven’t already created a repository. The second one is for when you already have a repository, added files and commits and just want to push it to the remote repository.
The commands used for this can usually be copy-pasted from the repository page.
First we add a remote to our repository with:
git remote add origin <url/to/repo>
Then we need to make the first push to the master branch on origin as upstream:
git push -u origin master
More on what those terms mean will follow in a future tutorial, for now all you need to know is that our local repository will push to the repository on GitHub or GitLab.
If you did everything correctly and go to your remote git repository, you can refresh the page and should see something like this:
You should be able to see the readme right away with the text you added and the commit message.
HINT: If you want/need to use SSH you’ll need to generate keys and add your public key to your GitLab/GitHub account.
See their docs for more information.
Exercise #4: Push your changes to the remote repository
- Follow the steps from above to push your first commit to your remote repository
Working in a team
The real power of git and platforms such as GitHub and GitLab comes with collaboration. We will simulate such a situation.
For this we will need a second “copy” of the repository locally.
git clone <url>
Now that the remote repository has some content, we can clone it.
The url (or on GitLab the whole command) can be copied from this buttons:
This will clone (download the repository with the right remote and all information and branches).
Just make sure there is not already a folder/directory with that name in the dir you want to clone:
Or you can use a destination path other than the repo name by adding a dir name at the end of the command:
git clone <url> <dirname>
Exercise #5: Create a new commit and push it
- Clone the project into another directory
- Add the following text to the README (after what you already have):
Now I finally know how git works!
- Push the change (add, commit, push)
- Go into the first directory (
d3vnull-git-tutorial) created at the beginning.
- Make sure you have no pending changes.
- Pull the changes with
git pull(we’ll take a look at git pull next)
The newly added text should appear in this README as well now!
It should also be changed on your remote:
Btw the markup language used in the
README.md file is called
markdown. If you want to know more about it I suggest using the Cheatsheet from GitHub.
In the last exercise you used
git pull. This command will
fetch the latest changes on the
remote repository and
merge them into your current (local) repository.
We will take a closer look at
merge and additional features of git and the platforms in the next article. Read it here.
Plus if you know someone who could need this article share it with them or on social media 🙂
Add one or more files to your repository and push them. Try editing the same file from both your directory. What do you think will happen if you’ll change the same lines in both repository and push them? How could something like that be solved with multiple workers?
Don’t worry if you ruin the repository. You can just delete the local copy and clone it again 😉