Git vs svn

A comparison of Git and SVN

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
●Every user has their own copy
of code on their local, basically
like their own branch.
●Keep making changes and
when you are satisfied merge it
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.
●SVN has a centralized model
●Everyone has a working copy
and changes are committed to
a central repository
●There's not much to say about
it....you guys know it all.

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
$ cd drink_coffee
$ git init
$ git add .
$ git status
$ git commit -a -m ”My first commit”
Lets set up a remote repository now
$ ssh xyz.com
$ cd /var/git
$ mkdir drink_coffee.git
$ cd drink_coffee.git
$ git init
$ exit
$ git remote add origin ssh://xyz.com/var/git/drink_coffee.git
Initiate an empty git
repo on your local
Add files to local repo
For version control
Commit changes to
local
Set up a remote repository in your
Server xyz.com
Having created the remote
repository
we’ll add it to our local repository
as a remote server
called “origin” using git remote add

8. Now let the magic happen :-Now let the magic happen :-
$git push origin master
Now on our local repo if you do a
$ git branch -a
* master
remotes/origin/master
$cd .git
$cat config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://xyz.com/var/git/drink_coffee.git
fetch = +refs/heads/*:refs/remotes/origin/*
$
The remote server, depicting
The target
Our local branch, that is
master
Our remote servers master
branch
A remote repository “origin”
that will fetch all of it’s refs/heads/*
branches
and store them in our local repository
in refs/remotes/origin/*
when a git fetch is performed.

9. Who else is playing with you?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
$ git add sometextfile
$ git commit -m "Added sometextfile"
$git push origin master:newremotebranch
$ git branch -a
* master
origin/newremotebranch
origin/master
$ git checkout --track -b newremotebranch origin/newremotebranch
$cat config
[core]
repositoryformatversion = 0
filemode = true
bare = false
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
$
Creates a branch on the
Remote repo and pushes
To it.
Now our local repository
Is tracking two remote
Branches – ”master” &
”newremotebranch”
Want to work on this new remote
”newremotebranch”?
Lets create a new
local tracking branch
”newremotebranch”.
Take a checkout of the remote
Branch onto your new branch
With the same name.

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: [email protected]
Password: ********
Uploading ssh public key /Users/suman/.ssh/id_rsa.pub
Created http://neevtech-coffee-59.heroku.com/ | [email protected]:neevtech-coffee-59.git
Git remote heroku added
$cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = ssh://xyz.com/var/git/drink_coffee.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "heroku"]
url = [email protected]:neevtech-coffee-59.git
fetch = +refs/heads/*:refs/remotes/heroku/*
$git commit -a -m ”Some more changes”
$git push origin master
$git push heroku master
There you go, one more
Remote repo.
Make some changes
Before you push.

13. Git SVN
Blown apart !
Two remote repos
for a single
Code base. What do
You say to that?
????

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.Branching in git is actually evil.
$cd guy_with_2_gals
$echo "Ok i'll take you to the movies today." > conversation_with_girlfriend
$git commit -m "Commitment given to the first girlfriend"
$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
Ok i'll take you to the movies today.
$ git checkout girlfriend2
$cat conversation_with_girlfriend
Production issue in Duplays.Can we meet tomorrow?
$
Now that's definitely evil.
Branching in Git is like magic.
Create new branches and keep switching
Between them with ease.
Creates a new branch
On your local git repo.

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
$git merge girlfriend2
$cat conversation_with_girlfriend
Production issue in Duplays.Can we meet tomorrow?
$
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.
Merge was never easier before. Merging is
One of the key strengths of Git.
A simple ''git pull origin master'' is also
a merge between changes of remote
Master branch and your local's
Master branch.

17. But sometimes our guy does remember his first girlfriend.
So he decides to revisit his conversation record and update his message.
$git diff HEAD~1
--- a/conversation_with_girlfriend
+++ b/conversation_with_girlfriend
@@ -37 +49 @@
-Ok i'll take you to the movies today.
+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
$git checkout -b what_i_actually_wanted
$git commit -a -m ''I wish i had said this''
$git checkout master
$cat conversation_with_girlfriend
Production issue in Duplays.Can we meet tomorrow?
$git checkout what_i_actually_wanted
$cat conversation_with_girlfriend
I want to take you to the movies today.
$git checkout master
Your master remains
uneffected
Your second thoughts remain
In the new branch
Changes get carried over.
Save the changes in
A new branch
Return back to master and
Keep doing your
Normal things.
HEAD is a pointer pointing to the
Current branch's latest revision.
HEAD~1 implies moving back
By one revision.
Shows differences between
Previous commit and the
Latest revision

18. Differences between Git and SVN with respect
to branching and merging
●Git maintains who performed the merge
●Maintains actual timestamp of the change
●Maintains what were the exact changes in
the merged data
●Git knows when the merge was done
●You can optionally specify why the merge
was done
●One can view merge specific changes
●Switch between branches easily on the
same code base.
●Git automatically remembers the revisions
of merges
●Branching is cheap and lightweight
compared to SVN, as simple as writing a
few bytes into a file.
●All changes made on the branch appear to
be made by the merging user
●Subversion records a merge as a commit
●Timestamp is that of the time it was merged
and not when the changes were made
●It's impossible to see only merge related
changes.
●Apparently you may end up blaming the
wrong person for a change if two or more
developers were working on a same branch.
●To work on a branch a user must copy the
trunk into another directory and then merge
it back when complete
●In Subversion you need to remember what
was the last revision you merged from so
you can generate the correct merge
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.

20. Git wins the race againt them all

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.

22. That's SVN.

23. Lastly, there's github
Github made coding social.
Go and check it out at : http://github.com

24. And lastly behold the GOD who
made it all – Linus Torvalds