GIT

By:Anuj Sharma

Topics covered: GIT Introduction GIT Benefits over different tools GIT workflow GIT server creation How to use GIT for first time.

GIT- IntroductionGit is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005, and has since become the most widely adopted version control system for software development.As with most other distributed revision control systems, and unlike most client–server systems, every Git working directory is a full-fledged repository with complete history and full version-tracking capabilities, independent of network access or a central server. Like the Linux kernel, Git is free software distributed under the terms of the GNU General Public License version 2.

Benefits of GIT over Clearcase• Atomic commits• Proper change sets• Speed• A proper history browser (so that you can see what changed for a commit, rather than the individual file nightmare of clearcase) • Reduced maintenance cost and overhead• No licensing cost• GIT is actually being maintained (I know clearcase 8 has a new GUI, but the underlying tools will still be the same old clunky and rotten relics) • Merges that are more sophisticated than the dumb text merges of clearcase, allowing a more flexible branching strategy • Considerably lower overhead for a developer (can you imagine any system with higher developer overhead than clearcase!) • MUCH, MUCH, MUCH easier branching and merging. • No VOB locking during backups. • Easier to back up

Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk. Git has the 'bisect' command. It's nice. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal. You have to tell SVN whenever you move or delete something. Git will just figure it out.

Benefits of GIT over SVN

GIT –Basic Workflow

First, we need to install git in our system. It can be done in many ways. I am giving an example of Linux. I am using “Ubuntu 13.04 ” Linux flavor to explain. So, its very simple to install using below command:

sudo apt-get install git

Now, git is installed in your machine. Just verify it once by running this command:

git --version

Then, someone needs to create the central repository on a server. If it’s a new project, you can initialize an empty repository. Central repositories should always be bare repositories (they shouldn’t have a working directory), which can be created as follows:

git init --bare MyProject.git

You might have noticed the –bare repository created above ended in .git. By convention, bare git repositories should end in .git. For example, project1.git. The .git ending of a directory signals to others that the git repository is bare.The Bare repo contains below things initially:

Since now we have a git repo ready at our server. Now we have to make use of this centralized repo. All we need to do, is to clone this repo to have a local copy of ours. Cloning a repo also needs some permission. Now we will check two approaches.

1. Cloning a repo in same server (IP), with different user name. I have one other user in my server “sharma”.

2. Cloning a repo in different server (IP) will need some special feature “ssh”. Create a pub file with your details, using the below command; ssh-keygen -t rsa -C anuj.sharma@gmail.com It will create few pub files, out of which you can just do, cat .ssh/id_rsa.pub It will be having "anuj.sharma@gmail.com" at the end, just to

verify it got generated with your details. It can be seen in the below snapshot.

Create a file with authorized_keys name, and add your pub files to it.

cat .ssh/authorized_keys Now change the permissions of authorized_keys as it will act an

important role in providing access to other users. chmod 700 .ssh/authorized_keysIt can be seen in the below snapshot.

You may add as much as pub files as you want. It will act as an authentication for your git repo. Now whenever any user want to clone, git admin has to provide access by adding a pub file to authorized_keys. And your clone command would be something like this.

git clone server@IP:/home/anuj/git_repos/MyProject.gitIt will not ask for password, if pub file is already added.

So, now we have local repo of our own.

We have to check which repo we are using, we can use “git remote -v” to check the same. It will display the git repo, your are in.

Now, we have to add few things to our git config, so that it will give the information of user. We need to use below commands as shown in snapshot.

Now, we can start working on our repo. Lets create a test file in git repo “abc.txt”. git status will give the . It can be shown in below snapshot.

The red color shows that file is not a part of git yet. For this we need to add this file to git repo, using “git add”

Since this file is added to git, color has been changed to green. It means, it is now added to staged area of git, from where we can proceed to commit. It can be shown below:

-s is used for “signed-off by user”-m is used for “message”

We can check the git log, how it will look.

Commit-id show above is unique to a change.

This presentation ends here, In my next presentation, we will go bit deep and cover most of the commands with their use cases. Till then you may check the commands on my blog:

https://anujparashar.wordpress.com/2013/12/29/git-commands-cheetsheet/

Thank you….