Learn How to Use Version Control with Git and GitHub: The Absolute Guide for Beginners

If you are new to programming, version control is one of the first concepts you must learn, but what does version control mean?

What is Version Control?

You can find multiple definitions in the web that can be too technical. However, I will put this in simple words: Version control allows you to track any changes of made on a project, such as every time you made a change on a file, which lines/words/letters were changed on that file, who made the change on the file, or when the person made that change.

What are the benefits?

• Trace all the changes made: Although this is pretty much the definition of version control, it is useful when you need to check at what point in the process things got changed.
• Multiple programmers working on multiple features: You will notice this when working with teams, but essentially while you are working on feature A, another programmer can be working on feature B, without waiting for each other to complete their respective feature development.
• Fast development: Since multiple programmers can be working at the same time on several features of a project, the development speed increases; hence your team, unless you are a solo-team is able launch a product is less time.
• Room to make mistakes: Have you heard about software having v1, v1.1, v1.2, v2, v2.3…? Well, if you introduce a new functionality for a new version in a project and let’s say it is a disaster with too many bugs, you can always go back at any point a use the latest working version of a project.

There are different version control options available out there such as Git, Mercurial, Monotone, and many others that I’ve never heard of, and probably you too unless it is a used for a specific case. There are different varieties of version control: centralized and distributed.  If you are interested in reading more about centralized vs distributed version controls in this article.

However, if you don’t know which version control to learn, then learn Git. It the most popular out there and most of the companies use it.

Note: Git is a distributed version control system. For more information about Git, checkout their website https://git-scm.com/

Version Control Hosting Platforms

There are many hosting platforms out there such as Github, Bitbucket, or GitLab that allows you to store your projects for free. This is important because you can keep you code on the cloud, instead of in your local machine and you will be able to “clone” or copy it or access it from anywhere in the world.

It also serves as the hub for teams to contribute to a project or adding their chunks of code symbolizing the development of a feature or fixes of a project.

Learning any version control hosting platform is more than sufficient, as the concepts are generally similar in any of them. The most popular and widely used is Github.

Public vs Private

Although it sounds self-explanatory, it doesn’t hurt to mention you can keep your repositories on any of these version control hosting platforms as public or private.

Why would you keep a repository public?

There are several reasons, you want to show off the code of a project or share it with other developers. Usually, when you are looking for a job having some public repositories is good for potential employers to checkout your code and the quality of it. You can tell a lot by checking a programmer’s coding style.

However, you don’t always want to make those repositories public unless you want to show the code base of a product you are monetizing and want others to see it and copy it, which is a big no no.

Let’s Learn Version Control with Git

The first thing you are going to do if you haven’t is to download Git on your local machine. Feel free to use the default installation instructions unless you have experience working with Git.

Once it is installed, we are going to open the terminal and setup some basic configuration.  

Prefer to watch the video?

Configuring your Identity

The first thing we need to do is to set up your user name and user email. This information is used at the moment of committing changes to allow you to track who made the changes.

git config --global user.name "Andres Reales"
git config --global user.email [email protected]

If you need to verify if these values were set correctly, you list the information using the following command

git config --global  --list

Initialize a repository

Time to start our first ever git repository. If you have a website, an app, or you are simply starting from scratch and you want to start your repository make sure you go to your project’s folder using the terminal

cd go/to/my/project/folder

Once you do that, we are going to initialize our repository with the following command.

git init

A hidden folder called .git is created in your project’s folder. If you want to check it, you can run the following:

ls -a    // if you are using bash or a linux terminal
dir /a:hd  // if you are using the windows command terminal

Make your first commit

It’s time to do our first commit, or in other words, telling git we want to generate a new version of the changes we made in our project’s folder. If you are starting you could add a README file or basic index.html file to your project’s folder.‍

Take into account that any time you create, update or delete a file in your project, git will detect it. In order to check what changes we made we use the following command:

git status

You should see the updates or untracked files in your project. In my case, it is showing that the index.html file is untracked.

Since we need to track changes in our project we are going to stage the files we want to commit.

‍Note: Staging in Git is a way to tell the version control system that there are certain files are going to be part of your next commit. In other words, let’s create a new version of the changes we made of certain files.

‍In order to stage my index.html file, I will use the following command:

git add index.html

Note: If you have multiple files you want to stage and you want to avoid staging a file at a time, you can run the following command instead:

git add .

Once you stage your files, you should notice a green color output showing the staged files.

If by mistake, you staged a file you didn’t want to include in your commit, i.e., a styles.css files, you can unstage it by using the reset command

git reset styles.css

You should see in red color that styles.css has been unstaged.

Note: Make sure you add the name of the file you want to unstage, otherwise it will unstage all the files if you use:

git reset

Once you stage all the files you want to track, we are going to commit our changes.

git commit -m “Initial commit”

Once you do so, it will generate a commit id with files you decided to include.

‍Time to Save My Local Repo in Github

Go to Github and sign up with a new account. Don’t worry, it’s free.

‍After you create your account we are going to create a new repository.

Fill out the basic information required such as your repository name and the owner of the repository. Make sure you select yourself as the owner!

‍You can also make your repository public if you want anyone on the internet to see your repository.

‍Once that is done, click on next and you will create your repository.

Your repository has been created. You should see the url of your repository. In my case, it is https://github.com/arealesramirez/learningGit.git. Make sure to copy it as we are going to use it next.

‍It’s time sync your local repository with your Github repository. Open again your terminal and add a “remote” to your local repository.

git remote add origin https://github.com/arealesramirez/learningGit.git

Note: If this is the first time you are using Github, the system will prompt you for your Github credentials.

‍Push it to Github

We are going to use the push command to get our index.html file and other files into our Github repository. Since this is the first time you are pushing to your Github repository, we are going to set an upstream or a tracking reference using the option –set-uptream or -u next by the “remote” name and the branch name.

git push -u origin master

Go to your repository in Github, in my case l called it learningGit and you will see my local files are now there.

HELP!

Everyone needs help, so you as well, especially trying to remember all of these new git commands. You can get a description of the commands available using –help.

git --help

Don’t worry, you will remember these commands easier as you use them more often. In a matter of a time they will be part of your programming knowledge.

Cloning a Repository

Most likely if you are joining a team working on an existing project, you will need to get the project’s code base from the hosting version control. For example, if you were to get my repository called learningGit, you will need to clone it to your local machine.

git clone https://github.com/arealesramirez/learningGit.git

And now you will have access to my learningGit repository. This is a public repository, so you can clone it to your local machine to practice the git commands and make any changes to the project locally.

‍Based on the project’s settings, you could also push your changes to the hosting platform.

‍Don’t push confidential files to Github!

You might have an environment variables file with credentials to connect to the database or API keys from third party platforms. However, you definitely don’t want to include these files to Github or any other hosting version control platform for security reasons.

‍To avoid this we are going to create a .gitignore file (yes include the period before gitignore text) and inside there we are going type the name of the files we do not want to track in our remote version control.

‍Pieces of Advice

Commit as many times you can!

Whenever you are working on your projects, make sure to commit and push your changes early and often, even if your code doesn’t work correctly. Trust me, you will want to have something saved instead of nothing if one day your computer breaks and you no longer have access to the code you’ve been working for hours or even days.

Pull before pushing

‍Remember this as you don’t want to mess someone else’s code. You need to pull the latest changes before pushing your changes.

‍Think about it, you and Jhon are working on the master branch. Jhon finished developing the contact form before you finished developing the navigation panel. Jhon had already pushed his changes to the master branch in Github repository or wherever the project repository is, but you don’t have those changes yet in your local machine. Once you finish developing the navigation panel, you are exhausted but ready to push those changes to the master branch. If you push your changes without pulling, Jhon’s contact form work will be lost. To avoid this from happening, you will pull first.

git pull

In that way, you will get the latest changes including Jhon’s contact form. Now it’s time for you to push your changes.

git push

Work on independent branches, then merge to main branch

If we go back to the previous example, Jhon is working on the contact form and you are working on the navigation panel. These are two different functionalities or tasks. Generally, it is better to have a working branch where you have a working version of your project.

‍It’s time for you start working on the navigation panel, right?

‍Let’s create a new branch, in that branch all the development related to the navigation panel will be done.

git checkout -b navigation-panel

You’ve been pushing your changes to the navigation-panel branch, and you completed the development. It’s time to merge all the changes you made on the navigation-panel branch into master branch.

‍To merge the navigation-panel branch into master branch, you need to go to the master branch and pull the latest changes if there are any.

git checkout master
git pull

Now, merge navigation-panel into master branch and push the latest changes to the remote master branch.

git merge navigation-panel
git push

Congratulations, you have learned the basic git commands. Go ahead and create new branches, add files, commit changes, push changes, pull changes, change branches, merge branches, etc. The best way to learn is by practicing and practicing. You got this!