GIT : Basics

Before getting into setup stuff lets see about different type of version system.

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Local Version Control Systems

Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to. To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.

Centralized Version Control Systems

These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything—the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem.

Distributed Version Control Systems

In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren’t possible in centralized systems, such as hierarchical models.

Git is a version control system invented by Linus Torvalds (Father of Linux OS). It is one of the most robust, fast vcs currently in the market. Lets start, by installing git on to your machine. I will be using windows for this tutorial. Download it from here and install it. Also, I would be using command line. Notice the 3 Git launchers (when you right click) after installation.

We would be using Git bash from here on.

First of all we have to make a initialize a repository and ask git to track it. Open Git bash from where you want to make a directory or you can move within it using cd. Now type the following command:

$ git init myproject

This will create a new directory called ‘myproject’ and ask git to keep a track of it. The directory itself will be empty with a hidden folder .git. This is where git keep the history and all the version control details for this project.

You can also create a git repository simply by typing $ git init inside any folder, and git will from now on will be tracking it. If you remove your .git folder, all your history etc will be gone and that folder will not be tracked by git anymore.

Before starting any wrk, it is wise to setup few config details , so as to track who commited/changed what using following commands:

git status tells us details about untracked files and staged files. It first tells on which branch we are currenlty in, which here says ‘master’. Master is the branch created by git and as a convention all the files/code present on the master are the final ones. We will discuss about branching in the later tutorials but for now let work on the master branch only.

Git status also tells us that it has a untracked/unstaged file right now. We can add it to staging and then commit it to the braching using git add and git commit command shwn as follows:

So, you first added your file to the staging area using git add. Then you committed it. This adding step may looks like an unnecessary step now, but later when you have a lots of unstaged files and you dont want them to be commited under a common commit, this will come in handy.

There are other ways to add files to staging as weell like
$ git add . or $ git add –all
or you can add and commit in one line also like
$git commit -a -m “Commit message”

Lets make some changes in the file and commit again.

You can check what all changes are done by using git log.

Suppose now we have to see what did out project looked like when we made the first commit. We can do that using git checkout <commit identifier> . Usually you only need to write 5-6 first of the character of the identifier. Lets do it.

‘HEAD’ means what my current repo is pointing to. It may be master branch or any other branch or a commit version in a partiuclar branch. Right now it in a older version and its kind of warking you not to make commit here as things may get weired afterwards. For now we just wanted to see what our files looked like at this point of time/commit. We use cat command to look into the file and see that the changes we did in the next commit are not there. We can switch back to our master branch by using git checkout master.

To see the difference between 2 commits we ca use
$git diff <commit identifier1> <commit identifier 2>

You may use other git UI tools to see the changes in a more understandable manner, tools like git gui, tortoise git or the git eclipse plugin etc. Thats it for now, we will look into branching and other details in the next posts. Thanks for visiting.