If you're a beginner developer, you might think that these two terms mean the same thing – but they're different.
This tutorial will help you understand what Git and version control are, the basic Git commands you need to know, how you can use its features to boost your work efficiency, and how to extend these features using GitHub.
This guide is beginner friendly, as the examples will be very easy to understand. It will also be a generalized tutorial so anyone can follow along no matter what your favorite programming language is.
For our project, we'll make a to-do list written in a text (txt) file. You will see how we can use the features of Git to work on and create a final version of the list.
In order to complete this tutorial, you'll need the following:
Git is a version control system which lets you track changes you make to your files over time. With Git, you can revert to various states of your files (like a time traveling machine). You can also make a copy of your file, make changes to that copy, and then merge these changes to the original copy.
For example, you could be working on a website's landing page and discover that you do not like the navigation bar. But at the same time, you might not want to start altering its components because it might get worse.
With Git, you can create an identical copy of that file and play around with the navigation bar. Then, when you are satisfied with your changes, you can merge the copy to the original file.
You are not limited to using Git just for source code files – you can also use it to keep track of text files or even images. This means that Git is not just for developers – anyone can find it helpful.
In order to use Git, you have to install it on your computer. To do this, you can download the latest version on the Official Website. You can download for your operating system from the options given.
You can also install Git using the command line, but since the commands vary with each operating system, we'll focus on the more general approach.
I will assume that at this point you have installed Git. To verify this, you can run this command on the
command line: git --version. This shows you the current version installed on you PC.
The next thing you'll need to do is to set your username and email address. Git will use this information to identify who made specific changes to files.
To set your username, type and execute these commands: git config --global user.name "YOUR_USERNAME" and
git config --global user.email "YOUR_EMAIL". Just make sure to replace
"YOUR_USERNAME" and "YOUR_EMAIL" with the values you choose.
We are finally done with installing and setting up Git. It is now time to create our project.
I have created a folder on my desktop called Git and GitHub tutorial. Using the command line, navigate to
your new project's location. For me, I would run the following commands:
cd desktop
cd Git and GitHub tutorial
If you are new to the command line and are still learning how to use it to navigate around your PC, then I would suggest using Microsoft's Visual Studio Code. It is a code editor which has an inbuilt terminal for executing commands. You can download it here.
After installing VS Code, open your project in the editor and open a new terminal for your project. This automatically points the terminal/command line to your project's path.
Now to initialize your project, simply run git init. This will tell Git to get ready to start watching
your files for every change that occurs. It looks like this:
The first line has information about my PC and the path to where the folder exists. The second line is the command
git init , and the third line is the response sent back telling me that my repository (repo) has
been initialized. It is considered empty because we have not told Git what files to track.
A repository is just another way to define a project being watched/tracked by Git.
I have created only one file called todo.txt . This is what the file looks like:
Before we proceed learning with other git command. Lets talk about Github.
GitHub is an online hosting service for Git repositories. Imagine working on a project at home and while you are away, maybe at a friend's place, you suddenly remember the solution to a code error that has kept you restless for days.
You cannot make these changes because your PC is not with you. But if you have your project hosted on GitHub, you can access and download that project with a command on whatever computer you have access to. Then you can make your changes and push the latest version back to GitHub.
In summary, GitHub lets you store your repo on their platform. Another awesome feature that comes with GitHub is the ability to collaborate with other developers from any location.
Now that we have created and initialized our project locally, let's push it to GitHub.
f you are a beginner, you will come across some new terms like push, commit, add, and so on – but do not be overwhelmed by them. With some practice you will be able to remember these terms and what they do.
I will divide this section into steps to help you understand the process more clearly.
To be able to use GitHub, you will have to create an account first. You can do that on their website.
You can click on the + symbol on the top right corner of the page then choose "New repository".
Give your repo a name then scroll down and click on "Create repository".
Before we "add" and "commit" our files, you need to understand the stages of a file being tracked by Git.
A file is in the committed state when all the changes made to the file have been saved in the local repo. Files in the committed stage are files ready to be pushed to the remote repo (on GitHub).
A file in the modified state has some changes made to it but it's not yet saved. This means that the state of the file has been altered from its previous state in the committed state.
A file in the staged state means it is ready to be committed. In this state, all necessary changes have been made so the next step is to move the file to the commit state.
You can understand this better by imagining Git as a camera. The camera will only take a snapshot when the file reaches the commit state. After this state, the camera starts comparing changes being made to the same file with the last snapshot (this is the modified state). And when the required changes have been made, the file is staged and moved to the commit state for a new snapshot.
This might be a lot of information to take in at the moment, but do not be discouraged – it gets easier with practice.