Introduction to git

Git is an Open Source Distributed Version Control System. Now that’s a lot of words to define Git.

Let me break it down and explain the wording:

Control System: This basically means that Git is a content tracker. So Git can be used to store content — it is mostly used to store code due to the other features it provides.

Version Control System: The code which is stored in Git keeps changing as more code is added. Also, many developers can add code in parallel. So Version Control System helps in handling this by maintaining a history of what changes have happened. Also, Git provides features like branches and merges, which I will be covering later.

Distributed Version Control System: Git has a remote repository which is stored in a server and a local repository which is stored in the computer of each developer. This means that the code is not just stored in a central server, but the full copy of the code is present in all the developers’ computers. Git is a Distributed Version Control System since the code is present in every developer’s computer. I will explain the concept of remote and local repositories later in this article.

Why you need a version control system like Git ?

In real life projects usually have multiple developers working in parallel. So a version control system like Git is needed to ensure that there are no code conflicts between developers.

In addition, the requirements of such projects change frequently. So a version control system allows developers to revert to an old version of the code.

Finally, sometimes several projects running in parallel contain the same codebase. In this case, the concept of branching in Git is very important.

Let’s get started on using Git now

Files in a Git project have various stages like Creation, Modification, Refactoring, and Deletion and so on. Irrespective of whether the project is tracked by Git or not, these phases are still prevalent. However when a project is under Git version control system, they are divided into 2 environments & contains 5 areas distributed as follows.

A local environment with:

• Working directory untracked
• Working directory tracked
• Staging area or index
• Local repository

A remote with:

• Remote repository

These stages are the essence of Git. You get great flexibility in tracking the files due to these stages that files can reside in under Git. Let's understand each of these states one by one.

Create your local Git repository

• Go into your project folder and add a local Git repository to the project using the following commands:

git init        

• The git init command adds a local Git repository to the project.

git clone [repository URL]        

• Creates a copy of a remote repository on your local machine. It downloads all the files and commit history from the remote repository and sets up a local copy for you to work with.

git add [file-name.txt]        

• Add a file to the staging area

git commit -m "[commit message]"        

• The commit command makes sure that the changes are saved to the local repository.
• The command git commit –m "<message>" allows you to describe about the commit and help's to understand what has happened.

git status        

• Use git status to find out information regarding what files are modified and what files are there in the staging area — it shows other information as well, which we can ignore for now.

git log        

• Use git log to print out all the commits which have been done up until now.

git push        

• Uploads local changes to a remote repository. It synchronizes the commits on your local machine with the remote repository, making your changes available to other collaborators.

As soon as changes are ready in the working directory, they must be added in the staging area.

When there is a set of changes with a single purpose in the staging area, it’s the time to create a commit with a message about that purpose in the local repository.

When there is one or several commits in the local repository that are ready to be shared with the rest of the world, they must be pushed to the remote repository.

At that time, you can talk about the different states of a file in the Local/development environment: modified, staged and committed

Furthermore, you can explain:

• To show the changes in the working directory: git diff
• To show the changes in the staging area: git diff --staged
• To show the changes in the working directory and the staging area: git diff HEAD.

Updating the Local/development environment

Fetching

git fetch        

Pulling

When executing git pull, the data from remote repository travel to two areas:

• To local repository: fetch
• To working directory: merge

If you take care of the commit history, consider the use of git pull --rebase

Instead of fetch + merge, it consists of fetch + rebase.

Your local commits will be replayed and you won’t see the known diamond shape in commit history.

"If you internalize these concepts, it will be easier for you to go a step further with branches, merging, rebasing, etc. because you will have built a solid basis."

"With these essential Git concepts under your belt, you're well-equipped to embark on your version control journey. As you delve deeper into the world of Git, embrace the challenges, celebrate the victories, and never stop learning. Together, let's harness the power of Git to drive innovation, foster collaboration, and shape the future of software development."

Congrats ??

Now you know the basics of how to use Git, so go ahead and explore more!

I will soon be publishing one more article on slightly more advanced concepts of Git. Stay tuned!

Ariqt Ariqt Nederland Rejilal Ramachandran Rupesh Kumar B Venkata Sreyanth Arun Paul (Polly) Meghana Bandi Katta Amuktha Sai Sreeja Tharun Theja S Akhila Salveru