If you are Learning to code and want to pursue a career in the field of Computer Science, you will be required to learn version control at some point. Regardless of whether you want to work in web development, DevOps, Data Science etc. Version Control is an important skill required to work in the field of Computer Science. The most famous version control system used widely is Git.

What is Version Control System?

Suppose you are building a project or a program. Let's say that you make some changes in the code. After some time you realize that the previous version of this program/code was much better. You feel like " Hey, it would've been great if I could just get back to the previous version of this code". You might start undoing the changes manually( If you can remember them).

Version Control System enables you to easily undo your changes with simple commands and get back to the previous versions of your program/code without any hassle. It records changes made to the file over time and can recall any specific version of the file. With the help of the Version Control System, many people can work and collaborate on a single file/project while having different versions of the project files on their computers.

What is Git?

Git is the most popular version control system. It is completely free and open source.

Installation and Setup

Installation

You can install git on your computer from here: https://gitscm.com/downloads

Do not go for the GUI clients as we are learning the normal git version only right now.

Configuration

Configure your E-mail and Username ( Make sure to create an account on GitHub Beforehand)

Username Configuration command:

git config --global user.name <"firstname lastname">

Email configuration command:

git config --global user.email <"valid-email id">

You can take a look at this doc for a better understanding.

How Does Git Work?

Repositories

A repository or repo is a container for a project you want to track with Git. You can have many different repos for different projects on your computer. A repo can be present locally on your computer or remotely on the GitHub Cloud. When a Git repository is created inside a folder, it tracks all the files present in it.

Commits

Commits ensure that all the changes that you make to the files are saved into the git repository. Commits are like checkpoints in video games, where you ensure that all the progress that you have done till the point is saved. It's like a safety point for your code to ensure, that all the changes are tracked. It enables you to revert to the previous versions/history of your code.

For Example: Let's say you make some changes to your Portfolio Website. However, after some time you feel the changes to be unnecessary and want to revert to the original version of your website. Now, if you would have committed the changes to the git repository, it will make your work less hectic as you can go back to the previous version of your website with just a simple git command.

The Three Stages Before Making a Commit

Now when you make changes to a file after initializing a git repository, the changes are added to the file and the file goes to the first stage called the "Modified". The changes have been added to the file but they are not saved yet. To save the changes, the file has to be added to the second stage i.e. the "Staging" Area. We cannot commit the changes directly without staging them.

What the Staging area does is that it adds an extra blanket/layer of security to the commits and allows us to review our changes before making any commits. Staging also allows you to commit changes to different files in a repository separately. Ex: Let's say there are two files in a repository, and you want to commit changes in both of them. But you want it to be done separately and Staging allows you to do this.

When you commit your changes, all of the changes are saved and the snapshot of each commit is added to the commit history of the file. Commits should only be made on logical points i.e. after making some major and valuable changes to the code. They should not be done on every small/minor change.

Basic Commands

Creating/Initializing a Repository

To Create or Initialize a repository, first, create a new folder on your computer system. Now, open the folder and create a Python file or any other type of file .html, .css or whatever you want to create.

Now open your Command Line Prompt and through it, go to the respective directory i.e. the folder that you created.

Now type in the following Command:

git init

After this, a new git repository will be created in your folder. It will not be noticeable directly on opening the folder because it will be a hidden file.

Now make some changes to the file by adding some Basic Syntax to it. Notice the change in your text editor. You will notice some differences in the file name or color.

Here I have shown what happens in the VS Code Editor:

The moment I add this print statement to the file, the file name gets highlighted. The "M" after the file name tells that the file has been modified. This Highlighting is a way of Git telling you that " Hey! Don't Worry your file is being tracked. I've Gotchu Bro :)" Now you can try this on your computer and see the changes in your Text Editor yourself.

Staging Files

Now our file has been changed but the changes have not been committed yet. So, first, we will have to take the file to the "Staging" Area. To stage the changes for commit use the command git add followed by the filename:

git add sample.py

To check the status of the repository, whether it has any untracked files or any changes that need to be committed use the command git status :

git status

Now if you think you made a mistake and you want to un-stage the changes or we can say remove the file from the staging area,

Use the command git restore --staged <filename> :

git restore --staged sample.py

Or you can also use the command git reset <filename> :

git reset sample.py

Now let's say you are developing an application or project and you want to commit changes from multiple files. With one simple command git add ., you can do that without going through any hassle of staging the changes from each file one by one.

git add .

Committing Changes

Now after staging the changes, the time has come to finally commit those changes.

To Commit the changes use the command: git commit -m "Add a message"

git commit -m "Added a Print Statement"

The text that you write in the double quotes is saved as a message in the commit history along with your commit. The messages along with the commits are very helpful for future reference. The messages written along with commits should be descriptive to ensure that in the future when you take a look at the commit history you can understand the changes made to the code.

Now let's add some more statements and commit those changes.

Done?

Now, let's take a look at our commit history. Use the command :

git log

Now the history of all of the commits you have made, along with the messages and time will be visible to you on your screen. The large numbers along with your commits are what we call " Commit IDs".

Now if you are overwhelmed by these long texts coming in the form of your commit history, worry not you can see a condensed version of it as well. Use the Command git log --oneline . Now you can see a condensed version of your commit history on your screen.

Undoing Commits and Changes

Now if you realize that you do not want a particular commit in your commit history and you wish to remove it or if you simply just want to take a look at the previous versions of your code at a particular commit, worry not we can do that as well.

There are three different commands for going back to previous versions of your code according to your needs.

1. Checkout Commit - Use the command git checkout <Commit ID> .This gives you a read-only mode where you can look at the previous version of your code but you cannot make any changes to the Code and the Commit History is not affected. Take a look in your text editor and you will see the code being the same as it was at that particular commit.

   To escape the read mode and get back to the current version of the code use the command git checkout main.

2. Revert Commit - Use the command git revert <Commit ID>. This command reverts all the changes that are made after that particular commit (including that commit itself). However, you might need to make some changes in your editor to resolve some merge conflicts. After resolving the conflicts, type in git add <filename> and then run the command git revert --continue.

   You can still go back to the original version after this command as the snapshot of the revert command is also added to your commit history. You can simply use the Commit ID of the revert command and get back to the previous version again.

3. Reset Commit- Use the command git reset <Commit ID>. This resets all the commits you have made after a particular commit. It still doesn't reset the code back to that version immediately and only removes the commits from your commit history. If you would look back at your code in the text editor it's still the same. This is because it gives you a chance in case you want to put all the previous changes/commits, under a single commit.

   However, if that's not the case and you do want to directly get back at that particular commit, use the command git reset <Commit ID> --hard. This resets the code along with the commit history immediately.

   Note: Remember it is not advised to use this command as it can affect your repository and the changes cannot be reverted in any case as the other commits are permanently deleted from the commit history.

Branches

When we initialize a git repository in a folder, a main branch is created. All the changes or commits that are made in the future are saved & tracked on this main branch. However, while working out a new feature for your product, you would want to test the feature on a separate branch before merging it with the code on the main Branch. Why?

Because the Main Branch represents the stable version of the code that is published and used. Testing out new features by directly making changes on the Main Branch can create problems with the functionality of the code. Whereas a separate branch acts like an isolated environment to test out different things and features in the code. So, that is why it is advised to test out new features on a separate branch and if everything is stable we can merge it with the main branch. For Example, let's say two people are working on separate features for an app. Now both of them can work and test the features on separate branches and later on they can merge those separate branches into the main branch. This is called Branching. Branching is very useful as it can save a lot of time and does the job without adversely affecting the functionality of the main code.

Now let's try to learn more about Branching.

Creating and Working within a new branch

To create a new branch in a git repository, type in git branch <branch name>

For Example:

git branch feature

To check that which branch are we currently using/working on, use the command :

git branch -a

Now you will see all the branches in the repository listed out. To identify the branch currently being used check for the one highlighted with Green color and an asterisk( * ) on its left. That is the branch you are currently working on.

Now to switch to a different branch, use the command git checkout <branchname> For Example:

git checkout feature

In a git repository when a new branch is created, the stable version of all the files and code is directly copied into it from the main branch. Now make some new changes to the branch like creating new files or adding some more lines of code and make sure to commit those changes. Done? Cool.

Now, let's get back to the main branch through the command git checkout main. Notice, that all the changes you made and committed previously in the new branch are not visible/shown at all. This is because when we work on a separate branch we work in an isolated environment. This means that all the work/changes that we do are represented on that branch itself only(until merged with the main branch itself). The main branch remains unaffected. You can also look at the commit history of both branches and notice the difference.

You can create as well as switch to the branch in a single command itself by using the command: git checkout -b < Branch name>

Deleting a Branch

What if the feature/changes you were working on don't work well with the main code and you wish to delete it? Worry not.

Use the command: git branch -D <Branch name>

In case you wish to delete a branch that is already merged with the main branch, just make the "D" lowercase i.e. git branch -d <Branch name>.

Merging the Branches

While merging the branches, it is important to be in the same branch you want to merge into. Let's say you want to merge the new branch that you recently created with the main branch. So first you will need to switch back to the main branch with the command git checkout main. Now after switching to the main branch type in the command: git merge <branch name>. Ex:

git merge feature

Now if you had made any changes in the new branch previously and the main branch wasn't changed in the time before merging, then you will see a line Fast-Forward. This is a way of git telling you that it is fast-forwarding all the changes to the main branch and no changes were made to the main branch in the time between branching out and merging in.

But if you had made any changes in the main branch as well while working in the new branch before merging, you will see a line Merge made by the 'recursive' strategy. This is a way of git telling you that the main branch has changed in between the time of branching out and merging it back in and a new strategy has been used to merge the branches.

Note: This usually doesn't matter but sometimes, making changes to the main branch in between branching out and merging back in can cause potential merge conflicts. So, you have to remain cautious to avoid such occurrences of merge conflicts.

Conclusion

So, that's all for today folks. Now you have learned enough to start using Git on your own. You are done with most of the basic commands. If you want to learn more about Git and other basic commands in-depth, then you can take a look at the official documentation.

Official Git Documentation

or you can also check out this awesome in-depth guide blog by Sahil Mahapatra: Git & GitHub: In-Depth Guide

I hope that you enjoyed and learned about git.

If you have any suggestions or feedback, feel free to put them in the comments section. I would love to hear your valuable feedback.