Git vs SVN By Suman Mukherjee What is VCS? What is Git? What is SVN?Discussions on Github Git and SVN
VCSVersion Control System – also known as RevisionControl SystemRepository 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 enhancementsintroduced, by the change.●Version tracking●Coordinating between teams
GitNew 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
SVN Old shool guy Has been around a long timeRevision control system initiated in 2000 by CollabNet Inc.
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 ● Theres 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.
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 centralrepository...that is you connect to your server forsuch operations.
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 localLets 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
The remote server, depicting The targetNow let the magic happen :-$git push origin master Our local branch, that is masterNow 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/*$
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.gitLet them do the push and pull, while you sit back and relax.
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/newremotebranchorigin/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$
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.
$cd drink_coffee$heroku createEnter your Heroku credentials.Email: firstname.lastname@example.orgPassword: ********Uploading ssh public key /Users/suman/.ssh/id_rsa.pubCreated http://neevtech-coffee-59.heroku.com/ | email@example.com:neevtech-coffee-59.gitGit 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 = firstname.lastname@example.org: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
Two remote repos for a single ???? Code base. What do You say to that?Git SVN Blown apart !
Stuck up with two girlfriends, Git can help you out.Branching and merging was never easier before.
Branching – an inherent feature of GitBranching in git is actually evil.$cd guy_with_2_gals$echo "Ok ill 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 ill take you to the movies today. Create new branches and keep switching Between them with ease.$ git checkout girlfriend2$cat conversation_with_girlfriendProduction issue in Duplays.Can we meet tomorrow?$Now thats definitely evil.
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 localsProduction 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 currentbranch.●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.
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 branchs latest revision.+++ b/conversation_with_girlfriend HEAD~1 implies moving back@@ -37 +49 @@ By one revision. Return back to master and-Ok ill 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 uneffectedProduction issue in Duplays.Can we meet tomorrow?$git checkout what_i_actually_wanted$cat conversation_with_girlfriend Your second thoughts remainI want to take you to the movies today. In the new branch$git checkout master
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 ● Its 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.
Git is faster than SVNGit 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.
SVN eats up a lot of space unlike GitGits repository and working directory sizes areextremely small when compared to SVN.An SVN working directory always contains twocopies of each file: one for the user to actuallywork with and another hidden in .svn/ to aidoperations such as status, diff and commit.A Git working directory requires only one smallindex file that stores about 100 bytes of data pertracked file.