Short Courses: GIT Source Code Management Solution



Learn how to keep track of the code changes and undo them without losing any work. Learn how to work in a team and code separately in just 1 week. This course is totally practical and provides hands-on experience to the participants. Learn the SCM tool used by:

  • Google
  • Facebook
  • Microsoft
  • Linux Foundation
  • Twitter and many others

Students are expected to bring their own Laptops/Notebooks.

The fee for this course is PKR 2,800 and all the fee collected will be donated to Mishkat Welfare Trust
From: 30th June to 4th July 2014
Timings: 11:30 AM to 1:00 PM
Venue: Olives School, Judicial Colony, Rawalpindi.

Limited transport facility available for female students. Please mention it in the Comments field and provide your address.

At least 5 students must be enrolled for the course to commence.

Introduction to Git


Source Code Management with Git

Git is a Version Control System (VCS) and sometimes referred to as Source Code Management (SCM). A software that tracks the changes that have been made to files. Over time when different versions of a file exists, Git will:

  • Compare them and display the lines that are different.
  • Keep track of all the changes that have been made from one version to the other.
  • Merge different versions and changes together.

Git is however not just specific to source code, it can be used for managing versions of this files. For example you are working on a project proposal and you have named the files as proposal_v1.docx, proposal_v2.docx etc. Microsoft Word offers a form of version control through its feature Track Changes. Similarly Adobe Photoshop offer a feature called History. Wikis also offers the same thing.

Source Code Management before Git

Before Git, different other tools have been used to provide version control such as:

Source Code Control System (SCCS)
Released in 1972 by AT&T as a closed source product but was free with UNIX. It was used in Universities by students and later found its way in companies. Instead of saving three different versions of the same file it just saved a snapshot of the changes in each version.
Revision Control System (RCS)
Released in 1982 as an open source and cross-platform. Instead of keeping the original file as a whole and then keeping snapshots of all the changes made in every version, it did the opposite. Saved the complete file in the latest version and saved snapshot of changes for the older ones.
Concurrent Versions System (CVS)
Introduced in 1990, it added features such as able to add version control on multiple files. Additionally now multiple users were able to work concurrently.
Apache Subversion (SVN)
CVS was further improved in SVN introduced in 2000. It was faster and allowed saving of non-text files like images also. SVN was not just looking at changes made to certain file but was looking for all the changes happening in a directory. It was the most popular VCS before Git.
BitKeeper SCM
Released in 2000 as a proprietary solution but also had a Community Version which was free but had less features. Distributed Version Control was added to it. This free edition was used by the Linux Community for the Linux Kernel from 2002-2005. In April 2005, the Community Version was no more free and so Linux Foundation thought of coming up with their own solution.
Linus Torvalds

Linus Torvalds

Birth of Git

Git was created by Linus Torvalds in April 2005 as an open source product. Like BitKeeper it is also a Distributed Version Control System and is cross-platform. One other advantage is that it is many times faster than other SCMs. It has better safeguards built into it for data corruptions.

How Git Works

In centralized version control systems a copy of the code is placed centrally and users work on their end, when they commit the changes it will placed in the central repository. It is up to the user to keep track of what is happening in the central repository.

In Distributed Version Control Systems however, like Git, different users (or teams of users) maintain their own repositories, instead of working from a central repository. Git is very flexible and different workflows can be implemented with Git.

The changes are stored as “change sets” or “patches”. In other words, Git tracks changes not versions. These “change sets” or “patches” can be exchanged between repositories, merge with other “change sets” or “apply patches”. There are no single master repository instead there are many working copies each with their own combination of change sets.

How to Push to a Git Non-Bare Remote Repository

Git has two modes of remote repositories, Bare and Non-Bare. The Bare are those repositories which do not have a working directory while a Non-bare repository is just like any Git repository, it has a .git folder and the usual files.

Git is very flexible and dynamic. The remote repository can be on the internet and accessed using SSH, it can be on the local network or it can simply be on the same machine (a different path). In all cases the behavior of Git is more of less the same.

Lets open the terminal and begin.

Create a folder for local repository:

mkdir local

Create a folder for remote repository:

mkdir remote

Move into the local folder and create a repository:

cd local
git init
git add .
git commit -m "initial commit"

Now go to the remote folder and create a non-bare repository:

cd ../remote
git init

Come back to the local folder, and add the remote repository to its list of remotes:

cd ../local
git remote add remote /home/ahmad/Desktop/remote
git push -u remote master:updates

The changes have been pushed to the updates and now we need to merge them to the master of the remote repository:

cd ../remote
git merge updates
git log

To make another change:

cd ../local
git commit -am "another change added"
git push -u remote master:updates
cd ../remote
git merge updates
git log

Hopefully this worked 🙂