git advantages vs svn

Git advantages – in short: git not only offers svn functionality by offers much more than that:

  • LOCAL ACCESS TO ALL BRANCHES AND HISTORY – git clone downloads full repository (including history and all branches) so viewing history and changing branches does not require internet access and it much faster than e.g. svn where it need to talk to online repo to get history or switch branches, on the other side in git it is just about moving pointers. If origin repo gets corrupted than any user repo has all the data (assuming it was recently synchronized)
  • ABILITY TO COMMIT LOCALLY ANYTIME – every time you want to save your work you can commit even if you do not have access to the origin repo
  • NO PERMISSION ISSUES FOR CREATING BRANCHES – with svn you need to have special permission to create branches and it requires svn to copy many files what takes time. On the other hand you can always create your local branch and it is very fast (as creating 40B file)
  • FINE-TUNING COMMITS AND HISTORY – you can always change your last commit’s message (git amend) or the committed file set, moreover you reorder, squash or remove commits with interactive rebase (git rebase -i)
  • GIT is about applying changes whereas SVN is about file snapshots for each revision

Other differences:
SVN: has only working area and online repo committed area (shared with all)
GIT: has working area (contains local working changes), stage area (tracked changes added to the index that are candidates for committing), locally committed area (not yet pushed to public) and finally changes pushed to online repo for sharing with other committers

1. local working changes area — git add –> added file(s) to the stage area to track these changes in index
2. stage area — git checkout –> override local working area with tracked version of the files
3. stage area — git commit –> committed area to add the changes to the history
4. committed area — git reset HEAD–> overwrite stage area with changes from the commit pointed by HEAD (can be without HEAD  defaulting to HEAD, explicit commit hash or HEAD~1 for the previous commit)
5. committed ares — git reset — hard –> overrides stage and local working area with commit changes
6. committed area — git push –> push the changes to online public shared repo
7. online public shared repo — git fetch origin–> update origin branches e.g. origin/master and origin/develop with latest public repo changes (but does not change the local working area nor stage area)
8. online public shared repo — git pull –> update origin references with public repo changes AND also merges these changes with stage area and local working area














Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s