Time keeps changing, and perhaps the thing that keeps changing more often than time is your code; it keeps building and breaking. Just like we can capture the moments in time by taking a photo or making a video, similarly we have a tool in programming world known as Git that can be used to capture the code. Not only it can save the different snaps of our code, it also lets us move back and forth between two snaps/screenshots of our codebase.
Git was developed by Linus Torvalds in 2005, and back at that time, the purpose of it was to manage the source code for Linux. But now, it has hit the mainstream and is most used source code management software.
Head over to install Git on your local machine; it’s easy.
After you are done with the installation of Git, you can verify it by checking the Git’s version.
git --version
As of this writing, 2.6.3 is the latest stable release, and you should manage to install a version that is greater than 2 to follow up with this tutorial.
The first step is to configure Git, and it is way simple. Since, you can do all the things in Git through command line, and that is often the preferred way, so we would like to move with this way:
git config --global user.name "Your Name" git config --global user.email "your.email@example.com"
Sure, there are other configuration options as well, but that’s all you need to know to for now to move forward.
Git is a distributed version control system. Ok, it is a loaded word, here is the explanation:
You may be familiar with centralized version control system in which all the source code is kept in the main system and all other users/contributors are supposed to download/modify the code from that central system.
Having a centralized version control system may be good sometimes, but it has a serious drawback: we’ve got no backup. If our central system breaks down, no user can download the code, neither can contribute back. Now, this is where the distributed version control system becomes effective.
In distributed version control system, each user/contributor has its own copy of the latest code that he can download or contribute to. This means each developer would have his own set of changes to the code that he can additionally provide to other developers. So, in distributed version control system – you got no central system; if your system breaks down, you can download the code from another system but that code would be his version of the latest code.
In Git, code space is divided into three parts:
1. Working Directory
2. Staging Area
3. Repository
The working directory is simply the current directory you are working in. When you make some changes in a working directory, and you would like to take a snap of those changes and save them in Git version control system, then – staging those changes is the first step in this regard. You need to take all those changes(and we’ll see how in a bit) and send them to the staging area. And once you have sent all the required changes to the staging area, you can commit those changes, and this way the changes will permanently be stored in Git’s local repository.
Well, these were just the basic building blocks of using Git, and join us in the very next article where we shall apply these concepts through the help of different commands to see Git in action. Till then, Happy Git’ing.
