1. Git vs SVN
By
Suman Mukherjee
What is VCS?
What is Git?
What is SVN?
Discussions on Github
Git and SVN
2. VCS
Version Control System – also known as Revision
Control System
Repository of files for your source code.
●Changes made to the source is tracked.
● Who made the change.
●Why they made it.
●References to problems fixed, or enhancements
introduced, by the change.
●Version tracking
●Coordinating between teams
3. Git
New kid in town who deserves an audience.
●Fast
●Excellent for large open source projects
●Feature rich
●Branching and merging is what Git does best
●GitHub makes programming a social activity
4. SVN
Old shool guy
Has been around a long time
Revision control system initiated in 2000 by
CollabNet Inc.
5. Git vs SVN
● Git has a distributed model ● SVN has a centralized model
● Every user has their own copy ● Everyone has a working copy
of code on their local, basically and changes are committed to
like their own branch. a central repository
● Keep making changes and ● There's not much to say about
when you are satisfied merge it it....you guys know it all.
to your master.
● Master is on your local, so
changes stay on your local.
● If you have a remote link like a
GitHub repo...push changes on
your master to that.
6. That said...local copy of code means speed.
Basic operations like diff, commit, status etc.
Become ultra fast.
In SVN such operations occur in the central
repository...that is you connect to your server for
such operations.
7. Enough said...show me some
code.
Say you have a rails app.... drink_coffee
Initiate an empty git
$ cd drink_coffee repo on your local
$ git init
$ git add .
Add files to local repo
$ git status For version control
$ git commit -a -m ”My first commit”
Commit changes to
local
Lets set up a remote repository now
$ ssh xyz.com Set up a remote repository in your
$ cd /var/git Server xyz.com
$ mkdir drink_coffee.git
$ cd drink_coffee.git
$ git init Having created the remote
repository
$ exit we’ll add it to our local repository
as a remote server
called “origin” using git remote add
$ git remote add origin ssh://xyz.com/var/git/drink_coffee.git
8. The remote server, depicting
The target
Now let the magic happen :-
$git push origin master Our local branch, that is
master
Now on our local repo if you do a
Our remote servers master
branch
$ git branch -a
* master
remotes/origin/master
$cd .git
$cat config
[core] A remote repository “origin”
repositoryformatversion = 0 that will fetch all of it’s refs/heads/*
branches
filemode = true and store them in our local repository
in refs/remotes/origin/*
bare = false when a git fetch is performed.
logallrefupdates = true
[remote "origin"]
url = ssh://xyz.com/var/git/drink_coffee.git
fetch = +refs/heads/*:refs/remotes/origin/*
$
9. Who else is playing with you?
If you have a couple of collaborators, all they need to do is :-
$git clone ssh://xyz.com/var/git/drink_coffee.git
Let them do the push and pull, while you sit back and relax.
10. Want some remote repo action?
If you want to work on the remote repo, you can do that as well.
$cd drink_coffee_copy
$git init
$ git remote add origin ssh://xyz.com/var/git/drink_coffee.git
$ echo "This is madness" > sometextfile Creates a branch on the
Remote repo and pushes
$ git add sometextfile To it.
$ git commit -m "Added sometextfile"
$git push origin master:newremotebranch
Now our local repository
$ git branch -a Is tracking two remote
* master Branches – ”master” &
”newremotebranch”
origin/newremotebranch
origin/master
$ git checkout --track -b newremotebranch origin/newremotebranch
$cat config Want to work on this new remote
”newremotebranch”?
[core] Lets create a new
local tracking branch
repositoryformatversion = 0 ”newremotebranch”.
filemode = true Take a checkout of the remote
Branch onto your new branch
bare = false With the same name.
logallrefupdates = true
[remote "origin"]
url = ssh://xyz.com/var/git/drink_coffee.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "newremotebranch"]
remote = origin
merge = refs/heads/newremotebranch
$
11. How about multiple remote
repos?
How about multiple remote repos for the
same code base on local?
Can that be done?
Why not?
If i have ”origin” as a source for a remote repo...
Why not one more with a different name?
Saw somebody pushing to ”heroku”.
”git push heroku master”.
Sounds like exactly what i need.
Lets give it a shot.
12. $cd drink_coffee
$heroku create
Enter your Heroku credentials.
Email: suman@neevtech.com
Password: ********
Uploading ssh public key /Users/suman/.ssh/id_rsa.pub
Created http://neevtech-coffee-59.heroku.com/ | git@heroku.com:neevtech-coffee-59.git
Git remote heroku added
$cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true There you go, one more
Remote repo.
[remote "origin"]
url = ssh://xyz.com/var/git/drink_coffee.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "heroku"]
url = git@heroku.com:neevtech-coffee-59.git
fetch = +refs/heads/*:refs/remotes/heroku/* Make some changes
$git commit -a -m ”Some more changes” Before you push.
$git push origin master
$git push heroku master
13. Two remote repos
for a single
????
Code base. What do
You say to that?
Git SVN
Blown apart !
14. Stuck up with two girlfriends, Git can help you out.
Branching and merging was never easier before.
15. Branching – an inherent feature of Git
Branching in git is actually evil.
$cd guy_with_2_gals
$echo "Ok i'll take you to the movies today." > conversation_with_girlfriend
Creates a new branch
$git commit -m "Commitment given to the first girlfriend" On your local git repo.
$git checkout -b girlfriend2
$echo "Production issue in Duplays.Can we meet tomorrow?" > conversation_with_girlfriend
$ git commit -a -m "Conversation with the second girlfriend"
$git checkout master
$cat conversation_with_girlfriend Branching in Git is like magic.
Ok i'll take you to the movies today. Create new branches and keep switching
Between them with ease.
$ git checkout girlfriend2
$cat conversation_with_girlfriend
Production issue in Duplays.Can we meet tomorrow?
$
Now that's definitely evil.
16. Now our guy lost his first girlfriend...because she thought that he was rude.
So he decides to carry on with his second affair.
$git checkout master Merge was never easier before. Merging is
One of the key strengths of Git.
$git merge girlfriend2 A simple ''git pull origin master'' is also
$cat conversation_with_girlfriend a merge between changes of remote
Master branch and your local's
Production issue in Duplays.Can we meet tomorrow? Master branch.
$
The second girlfriend never came to know about our guys first affair.
Why merging is inherent in Git?
●The pull command fetches commits and then merges them into your current
branch.
●If you have no local changes, then the merge is a fast forward
●If you have local changes, Git will automatically merge, and report any conflicts.
17. But sometimes our guy does remember his first girlfriend.
So he decides to revisit his conversation record and update his message.
Shows differences between
Previous commit and the
$git diff HEAD~1 Latest revision
--- a/conversation_with_girlfriend HEAD is a pointer pointing to the
Current branch's latest revision.
+++ b/conversation_with_girlfriend HEAD~1 implies moving back
@@ -37 +49 @@ By one revision.
Return back to master and
-Ok i'll take you to the movies today. Keep doing your
Normal things.
+Production issue in Duplays.Can we meet tomorrow?
$git checkout HEAD~1
$echo ''I want to take you to the movies today.'' > conversation_with_girlfriend
$git checkout master Changes get carried over.
$git checkout -b what_i_actually_wanted Save the changes in
A new branch
$git commit -a -m ''I wish i had said this''
$git checkout master Your master remains
$cat conversation_with_girlfriend uneffected
Production issue in Duplays.Can we meet tomorrow?
$git checkout what_i_actually_wanted
$cat conversation_with_girlfriend
Your second thoughts remain
I want to take you to the movies today. In the new branch
$git checkout master
18. Differences between Git and SVN with respect
to branching and merging
● Git maintains who performed the merge ● All changes made on the branch appear to
be made by the merging user
● Maintains actual timestamp of the change
● Subversion records a merge as a commit
● Maintains what were the exact changes in
the merged data ● Timestamp is that of the time it was merged
and not when the changes were made
● Git knows when the merge was done
● It's impossible to see only merge related
● You can optionally specify why the merge changes.
was done
● Apparently you may end up blaming the
● One can view merge specific changes wrong person for a change if two or more
developers were working on a same branch.
● Switch between branches easily on the
same code base. ● To work on a branch a user must copy the
trunk into another directory and then merge
● Git automatically remembers the revisions it back when complete
of merges
● In Subversion you need to remember what
● Branching is cheap and lightweight was the last revision you merged from so
compared to SVN, as simple as writing a you can generate the correct merge
few bytes into a file. command.
19. Git is faster than SVN
Git is extremely fast. No network latency involved.
● Perform a diff.
● View file history.
● Commit changes.
● Merge branches.
● Obtain any other revision of a file
● Switch branches.
21. SVN eats up a lot of space unlike
Git
Git's repository and working directory sizes are
extremely small when compared to SVN.
An SVN working directory always contains two
copies of each file: one for the user to actually
work with and another hidden in .svn/ to aid
operations such as status, diff and commit.
A Git working directory requires only one small
index file that stores about 100 bytes of data per
tracked file.