GIT
The Ultimate Guide for Beginners
Learn Git Version Control
Jameson Garner
Table of Contents
PART 1: Git - Basic Concepts
Version Control System
Verson Control System (VCS) s a software that helps software developers to work together and mantan a complete hstory of ther work.
Lsted below are the functons of a VCS
Allows developers to work simultaneously.
Does not allow overwriting each others changes.
Maintains a history of every version.
Followng are the types of VCS
Centralized version control system (CVCS).
Distributed/Decentralized version control system (DVCS).
In ths chapter, we wll concentrate only on dstrbuted verson control system and especally on Gt. Gt falls under dstrbuted verson control system.
Distributed Version Control System
Centralzed verson control system (CVCS) uses a central server to store all fles and enables team collaboraton. But the major drawback of CVCS s ts sngle pont of falure, .e., falure of the central server. Unfortunately, f the central server goes down for an hour, then durng that hour, no one can collaborate at all. And even n a worst case, f the dsk of the central server gets corrupted and proper backup has not been taken, then you wll lose the entre hstory of the project. Here, dstrbuted verson control system (DVCS) comes nto pcture.
DVCS clents not only check out the latest snapshot of the drectory but they also fully mrror the repostory. If the server goes down, then the repostory from any clent can be coped back to the server to restore t. Every checkout s a full backup of the repostory. Gt does not rely on the central server and that s why you can perform many operatons when you are offlne. You can commt changes, create branches, vew logs, and perform other operatons when you are offlne. You requre network connecton only to publsh your changes and take the latest changes.
Advantages of Git
Free and open source
Gt s released under GPLs open source lcense. It s avalable freely over the nternet. You can use Gt to manage property projects wthout payng a sngle penny. As t s an open source, you can download ts source code and also perform changes accordng to your requrements.
Fast and small
As most of the operatons are performed locally, t gves a huge beneft n terms of speed. Gt does not rely on the central server; that s why, there s no need to nteract wth the remote server for every operaton. The core part of Gt s wrtten n C, whch avods runtme overheads assocated wth other hgh-level languages. Though Gt mrrors entre repostory, the sze of the data on the clent sde s small. Ths llustrates the effcency of Gt at compressng and storng data on the clent sde.
Implicit backup
The chances of losng data are very rare when there are multple copes of t. Data present on any clent sde mrrors the repostory, hence t can be used n the event of a crash or dsk corrupton.
Security
Gt uses a common cryptographc hash functon called secure hash functon (SHA1), to name and dentfy objects wthn ts database. Every fle and commt s check-summed and retreved by ts checksum at the tme of checkout. It mples that, t s mpossble to change fle, date, and commt message and any other data from the Gt database wthout knowng Gt.
No need of powerful hardware
In case of CVCS, the central server needs to be powerful enough to serve requests of the entre team. For smaller teams, t s not an ssue, but as the team sze grows, the hardware lmtatons of the server can be a performance bottleneck. In case of DVCS, developers dont nteract wth the server unless they need to push or pull changes. All the heavy lftng happens on the clent sde, so the server hardware can be very smple ndeed.
Easier branching
CVCS uses cheap copy mechansm, If we create a new branch, t wll copy all the codes to the new branch, so t s tme-consumng and not effcent. Also, deleton and mergng of branches n CVCS s complcated and tme-consumng. But branch management wth Gt s very smple. It takes only a few seconds to create, delete, and merge branches.
DVCS Terminologies
Local Repository
Every VCS tool provdes a prvate workplace as a workng copy. Developers make changes n ther prvate workplace and after commt, these changes become a part of the repostory. Gt takes t one step further by provdng them a prvate copy of the whole repostory. Users can perform many operatons wth ths repostory such as add fle, remove fle, rename fle, move fle, commt changes, and many more.
Working Directory and Staging Area or Index
The workng drectory s the place where fles are checked out. In other CVCS, developers generally make modfcatons and commt ther changes drectly to the repostory. But Gt uses a dfferent strategy. Gt doesnt track each and every modfed fle. Whenever you do commt an operaton, Gt looks for the fles present n the stagng area. Only those fles present n the stagng area are consdered for commt and not all the modfed fles.
Let us see the basc workflow of Gt.
Step 1 You modfy a fle from the workng drectory.
Step 2 You add these fles to the stagng area.
Step 3 You perform commt operaton that moves the fles from the stagng area.
After push operaton, t stores the changes permanently to the Gt repostory.
Suppose you modfed two fles, namely sort.c and search.c and you want two dfferent commts for each operaton. You can add one fle n the stagng area and do commt. After the frst commt, repeat the same procedure for another fle.
Blobs
Blob stands for Bnary Large Object. Each verson of a fle s represented by blob. A blob holds the fle data but doesnt contan any metadata about the fle. It s a bnary fle, and n Gt database, t s named as SHA1 hash of that fle. In Gt, fles are not addressed by names. Everythng s content-addressed.
Trees
Tree s an object, whch represents a drectory. It holds blobs as well as other sub-drectores. A tree s a bnary fle that stores references to blobs and trees whch are also named as SHA1 hash of the tree object.
Commits
Commt holds the current state of the repostory. A commt s also named by SHA1 hash. You can consder a commt object as a node of the lnked lst. Every commt object has a ponter to the parent commt object. From a gven commt, you can traverse back by lookng at the parent ponter to vew the hstory of the commt. If a commt has multple parent commts, then that partcular commt has been created by mergng two branches.
Branches
Branches are used to create another lne of development. By default, Gt has a master branch, whch s same as trunk n Subverson. Usually, a branch s created to work on a new feature. Once the feature s completed, t s merged back wth the master branch and we delete the branch. Every branch s referenced by HEAD, whch ponts to the latest commt n the branch. Whenever you make a commt, HEAD s updated wth the latest commt.
Tags
Tag assgns a meanngful name wth a specfc verson n the repostory. Tags are very smlar to branches, but the dfference s that tags are mmutable. It means, tag s a branch, whch nobody ntends to modfy. Once a tag s created for a partcular commt, even f you create a new commt, t wll not be updated. Usually, developers create tags for product releases.
Clone
Clone operaton creates the nstance of the repostory. Clone operaton not only checks out the workng copy, but t also mrrors the complete repostory. Users can perform many operatons wth ths local repostory. The only tme networkng gets nvolved s when the repostory nstances are beng synchronzed.
