A quick introduction to Git for former SVN users
I must admit that there were times, when I loved SVN an thought about Git as useless, hard-to-use, piece of crap. Now, I can’t imagine my life without it.
When starting a new job, I found a person with similar thought as my past ones. And I decided to write this simple introduction to try to talk that person into changing his mind.
Contents
Key differences between SVN and Git
If very short, sharp words Git is:
- serverless, decentralized version control system,
- that allows more than one remote to single local binding,
- where everything is a branch and
- that offers strong auto-merge and auto conflict-resolve mechanism.
Today, we can observe a global semi-paranoia of migrating from SVN (or even VCS) to decentralized version control systems like Git, Mercurial and similar.
This is a global trend and in general this could be considered as wise decision, as in general terms Git and other DVCSs are better than SVN or other CVCSs. But there are some parts, where SVN wins over Git.
If you are current SVN user and you’re taking possibility of SVN-to-Git migration seriously, then you are strongly encouraged to read this Programmers Stack Exchange answer, which underlines all most important differences between these two version control systems.
Key advantages of Git
Another great advantage of Git over SVN is that many remote repository hosts (like GitHub) are using SSH instead of simple passwords.
This is great in terms of security and ease (you don’t need to repeat entering your password), but it requires you to be familiar with this subject and to have at least basing knowledge in this area. Read my “password-less” serie of articles, if this is something completely new for you.
Try to not misunderstand “serverless + many remotes” idea. The fact, that you’re committing to your local repository (and push/pull changes from/to many remotes) doesn’t actually mean that you have to use that idea everywhere, where you use give. Many projects operate (using Git) on one, central repository, where developers can clone, push and pull like they did checkout, update and commit in SVN.
Git is also for more mature and clever user than SVN was. No matter, how stupid actions your user undertake under SVN, as long as he or she has no direct access to server or repository files on it, everything can be rolled back. The only bad effect can be a mess in logs. But, when using Git, a user enough stupid and with sufficient rights can fuck out entire server repository (or at least mess it up in unrecoverable way), even though he or she hasn’t got direct access to server and is working from local client only.
Git isn’t bad
Git isn’t that hard, as many former SVN users can think (at least in the beginning). See for yourself.
If you’re just starting, with Git, you may find this Stack Overflow question extremely useful. It isn’t written in well-accepted SO nature, but it is a huge resource and I must admit, that there isn’t any Git-related question, up until now, to which I wouldn’t find an answer there. The only problem is time on reading this! :]
Lazy-ass feature in Git
Since you always commit to local repository and only push/pull changes from remote, there is a small snach, not everyone is aware of. You can easily (much easier than in SVN) amend dates of your commits.
Let’s say that you’re working remotely from home and that you’ve been given a job to be made within two weeks. Your project manager is a sucker so he or she don’t know, that you can make this job within 24 hours, if you step hardly on your ass. So, what you’re doing, when using Git. Quite simple. You’re going on nearly-two-weeks-long vacation, then you come back, change your local computer clock back two weeks, do your job, and with each commit your shifting it toward current, real date, step by step, one day. Then you’re finally pushing changes to remote.
When PM asks you about your project, you’ll only admit, with a sad face or voice, that you’ve actually forgot to push changes to remote and did it once after two weeks. But you were honestly doing your job, and as each commit show, you’ve been hard working day-after-day.
Since you’re committing directly to remote repository in SVN, this trick wouldn’t be that easy to achieve.
Future reading
These questions and articles can be good start point to read about Git and how it differs from SVN: