Beyond Version Controlling with GITBeyond Version Controlling with GIT

By: Abhishek Parolkar

This presentation is licensed under:Creative Commons Attribution­Noncommercial­No Derivative Works 2.5 India

   

Who am I?

   

Agenda1.) “We, the coders of this universe”  2.) “We, the coders for this universe”3.)  SCM – in history4.)  Distributed SCM5.)  Welcoming the change in perpective.6.)  Learning GIT  

   

“We, the coders of this universe” 

 Code = > Idea => Code =>Innovate 

   

“We, the coders for this universe” 

Communicate => Build =>  Collaborate => Contribute

   

SCM – in history

Only two ways of making change

   

SCM – in historyLock­Modify­Unlock

   

SCM – in historyCopy­Modify­Merge

   

So, Whats wrong here?

   

When you lock the file, others have nothing to do.... 

...so they wait for their chance !

   ...... to lock you ;­)

   

When  you are working on an innovative immplementation...Your fellow commiter gives you a call and says ...

             “Dude!, Update and resolve conflicts”

   

If you are really really good, you get to grow a branch...

   :­)Wow!

But, practically,...branches never merge

   

In centralised system of version control , you surely hurt many innocent  souls

   

So, finally , you invite anger!

Courtesy:  http://www.bbspot.com/Images/News_Features/2007/04/mad­spidey.jpg

   

Introducing GIT

The distributed source code management tool

   

What is  Git?"Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high­level operations and full access to internals."

    * Branching is fast and easy.    * Offline work is supported; local commits can be submitted later.    * Git commits are atomic and project­wide, not per­file as in CVS.    * Every working tree in Git contains a repository with a full project history.    * No Git repository is inherently more important than any other.

   

Getting startedTwo ways:

1.) make a repository from local source directory$ cd source­dir$ git­init

2.) Clone others repository

$ git­clone git://git.kernel.org/.../git/torvalds/linux­2.6.git  linux­2.6

use git­pull for fast­forward­merge

   

If you have an archive of the source tree 

$ tar zxf  sneos.tar.gz$ cd sneos$ git init$ git add . $ git commit ­m "import sneos source tree."$ git tag v1.1 

   

Everybody uses these commands to maintain git repositories.

    *   git­init  or git­clone to create a new repository.    *   git­fsck  to check the repository for errors.    *   git­gc to do common housekeeping tasks such as repack and prune.   

   

For Individual Developer (Standalone)

A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands.

    *   git­show­branch to see where you are.    *   git­log to see what happened.    *   git­checkout  and git­branch to switch branches.    *   git­add to manage the index file.    *   git­diff and git­status to see what you are in the middle of doing.    *   git­commit to advance the current branch.    *   git­reset  and git­checkout (with pathname parameters) to undo changes.    *   git­merge  to merge between local branches.    *   git­rebase to maintain topic branches.    *   git­tag  to mark known point.

   

Create a topic branch and develop.

    $ git checkout ­b alsa­audio     $ edit/compile/test    $ git checkout ­­ curses/ux_audio_oss.c     $ git add curses/ux_audio_alsa.c     $ edit/compile/test    $ git diff HEAD     $ git commit ­a ­s     $ edit/compile/test    $ git reset ­­soft HEAD^     $ edit/compile/test    $ git diff ORIG_HEAD     $ git commit ­a ­c ORIG_HEAD     $ git checkout master     $ git merge alsa­audio     $ git log ­­since='3 days ago'     $ git log v2.43.. curses/ 

   

Individual Developer (Participant)

    *  git­clone(1) from the upstream to prime your local repository.    *  git­pull(1) and git­fetch(1) from "origin" to keep up­to­date with the upstream.    *  git­push(1) to shared repository, if you adopt CVS style shared repository workflow.    *  git­format­patch(1) to prepare e­mail submission, 

 if you adopt Linux kernel­style public forum workflow.

Example:$git clone git://git.kernel.org/pub/scm/.../torvalds/linux­2.6 my2.6$ cd my2.6$ edit/compile/test; git commit ­a ­s (1)$ git format­patch origin (2)$ git pull (3)$ git log ­p ORIG_HEAD.. arch/i386 include/asm­i386 (4)$ git pull git://git.kernel.org/pub/.../jgarzik/libata­dev.git ALL (5)$ git reset ­­hard ORIG_HEAD (6)$ git gc ­­prune (7)$ git fetch ­­tags (8)

   

Integrator

    *    git­am to apply patches e­mailed in from your contributors.    *    git­pull to merge from your trusted lieutenants.    *    git­format­patch to prepare and send suggested alternative to contributors.    *    git­revert to undo botched commits.    *    git­push to publish the bleeding edge.

Repository Administration

    *    git­daemon to allow anonymous download from repository.    *    git­shell can be used as a restricted login shell for shared central repository

   users.

   

Thank you!

I am just a click away, abhishek@parolkar.com

Blog: http://abhishek.parolkar.com

Find more here:http://www.kernel.org/pub/software/scm/git/docs/everyday.htmlhttp://www.versioncontrolblog.com/http://www.russellbeattie.com/blog/distributed­revision­control­systems­git­vs­mercurial­vs­svn