Control System: This basically means that Git is a content tracker. So Git can be used to store stuff – it is used to store code because of the other features it has.
Version Control System: The code stored in Git changes as more code is added. Also, multiple developers can add code in parallel. So the version control system helps to handle this by maintaining a history of what happened. In addition, Git provides features like branching and merging, which I’ll cover later.
Distributed Version Control System: Git has a remote repository which is stored in a server and a local repository which is stored in each developer’s computer. This means that the code is not stored in just one central server, but the complete copy of the code is present in all the developers’ computers. Git is a distributed version control system because the code is present in every developer’s computer. I will explain the concept of remote and local repositories later in this article.
Why is a version control system like Git needed?
Real life projects usually have multiple developers working in parallel. Hence there is a need for a version control system like Git to ensure that there is no code conflict between developers.
In addition, the requirements in such projects change frequently. So a version control system allows developers to go back and revert to an older version of the code.
Finally, sometimes multiple projects run in parallel comprise the same codebase. That’s why the concept of branching is very important in Git.
Let’s start using Git now
Instead of mentioning all the concepts at once, I will explain the concepts of Git through an example so that it is easy to follow.
Here we will demonstrate with just plain text, rather than actual code, as the main focus of this article is on Git, not any specific programming language.
Code staging and committing
Committing is the process in which code is added to the local repository. Before you code, it needs to be in the staging area. The staging area is there to keep track of all the files that have to be committed.
Any files that are not added to the staging area will not be committed. It gives control to the developer as to which files need to be committed.
“Early commit” is the commit message here. Enter a relevant commit message to indicate what code changes were made in that particular commit.
Use git status to get information about which files have been modified and which files are in the staging area – it also shows other information, which we can ignore for now.
Till now we have not created any branch in Git. By default, Git goes to the master branch.
What is a Branch?
A branch is nothing but a pointer to the latest commit in a Git repository. So currently our master branch is a pointer to the second commit saying “demo.txt file is modified”.
Why the need for multiple branches?
Supporting multiple parallel development requires multiple branches. See the image below to see how branches work.
Initially, commit 1 and commit 2 were made in the master branch. After commit 2 a new branch named “test” is created, and commit 3 and commit 4 are added to the test branch.
At the same time, a separate commit 3 and commit 4 are added to the master branch. Here we can see that after commit 2 two parallel commits are being done in 2 different branches.
The test branch and the master branch are different here and have different codes – the code from the test branch can be merged into the master branch using git merge. This will be covered later.