Table of Contents
Introduction to Git
In professional development environments, the code is written in teams of developers. From your colleague sitting around the corner to a remote developer living across the globe, anyone could be writing code with you and contributing to the same codebase. The best and most popular way to contribute code to a single codebase is Version Control Systems.
Version Control Systems
Version control systems are systems that allow us to contribute to and manage different releases and stages of a software product without actually having to keep multiple files or folders. They also make development within a team more manageable and less of a pain as developers don’t have to be trading folders, but rather communicate with a single source where all the changes are happening and everything is saved.
There are two types of Version Control Systems: Centralized and Distributed.
Centralized Version Control Systems
Centralized means that the codebase or the project resides in one central place also known as a repository. In order to make changes, people need to have access to that repository and write their code in it.
Distributed Version Control Systems
In distributed systems like Git and Mercurial, things are much more flexible, since they are distributed systems. Which means that everyone has his working copy of the repository that keeps track of his changes and the different releases made by him or by his colleagues.
What is git?
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
How Git works
Most version control systems work by calculating the differences in each file, and then by summing up these differences they can reach whichever version saved, but that’s not the way Git works.
Git functions as a series of snapshots for your file system. Every time you change something in your files committing it, or just saving the state of your project, Git takes a picture of the whole system and saves a reference to it. If there’s a file that hasn’t been changed, then it stores a reference to the previous snapshot. We’ll get to how this is one of the most powerful and enabling features in Git when we dive deeper into the features Git provides.
There are three states for your files to be in when you’re working with Git. These three states are: modified, staged and committed.
When you make changes to a file in your working directory, it is then modified, but these modifications are not stored in the codebase. When you stage the file, these changes are marked to be saved in the next commit. When you commit the file, these changes are finally stored in your codebase.
There’s a fundamental thing to understand about Git, which is the fact that you can run two types of the repository. Usually, you have a local repository on your machine, that is your desktop or laptop, which is defined in your working directory, and a remote repository that is stored on the cloud.
The difference is, you can use the local repository and Git with all its features on your local machine, until and unless you want to share your code with others. It is only then that you need to make a remote repository of your code on GitHub/Gitlab etc and upload your code to that repository.
Once you do that, anyone with the access to your repository can download the code to his/her local machine and contribute to it.
Configuring Git: Getting Started
To get started, visit https://git-scm.com/ and download the appropriate version for your operating system. After running the installation, open Git bash or Git CMD. and CD ( change directory command) into an empty directory of your choice and run these commands. Replace the “John Doe” with your git username and “firstname.lastname@example.org” with your git account’s email id.
$ git config --global user.name "John Doe" $ git config --global user.email email@example.com
Here, git config is a command that asks your computer to make changes in config the file in the .git folder of the root of your system.