Git Isn't Hard
When we tell people why they should use Git over Subversion, the go-to line is, “Git does Subversion better than Subversion, but it does a lot more than that.”
The “lot more” is comprised of a bunch of stuff that makes Git really shine, but it can be pretty overwhelming for those coming from other SCM’s like Subversion.
That said, there’s nothing stopping you from using Git just like you use Subversion while you’re making the transition.
Assuming you’ve installed the necessary software and have a remote repository somewhere, this is how you would grab the code and push your changes back with Subversion:
$ svn checkout svn://foo.googlecode.com/svn/trunk foo # make your changes $ svn commit -m "my first commit"
And how would you do it in Git:
$ git clone git@github.com:pjhyett/foo.git # make your changes $ git commit -a -m "my first commit" $ git push
One more command to make it happen in Git. That extra command has large implications, but for the purposes of this post, that’s all we’re talking about, one extra command.
See, it really isn’t that hard.
Update: I’d be remiss to not also mention that the equivalent of updating your local copy in Subversion compared to Git is `svn update` and `git pull`, respectively. Only one command in both cases.
And if the working directory is your only repository, you don’t even have to push.
I can’t believe how awesome your favicon is.
the most common reply I get is “I’m only a user (update and commit)”, i.e. any “power” tool in this area is a waste of time. :-(
@choonkeat that’s what we hear a lot and the answer is: that’s fine! The difference, of course, is once you realize how great it is being able to do things like branch and merge quickly and simply, you can’t imagine how you ever did without it.
This article is a bit disingenuous. Sure there’s only one extra command, but only if you are using the command line tools to communicate with your version control repository. Such tools are already quite wordy and fiddly, so one extra general command is no big deal.
However, many IDEs provide a smoother integration with the idea of version control. We use Eclipse, for example, which “understands” the model of CVS and Subversion and integrates it into the development cycle and code browsing tools. For example, the IDE is aware of all changes made using it, and can correctly accumulate a sequence of add/delete/move/change operations. This in turn actively empowers the safe use of refactoring features which may make sweeping changes to a codebase.
So far I have not found anything as comfortable for any of the distributed version control systems.
Stepping away from integrated version control in an IDE to a fiddly command line which requires manual management of changes and thus imposes a burden on refactoring seems a big price to pay, however much I would like to move to distributed version control.
Hi Frank, have you looked at JGit1? It’s an Git plugin for Eclipse that you may find quite useful to solve the issues you’re facing. At the end of the day, there are certainly some stark differences between centralized and distributed version control, but you’d be hard-pressed to find someone that has adopted a distributed system and felt it was the wrong choice.
1. http://freshmeat.net/projects/jgit/
I’d like git more if -a was the default for commit.
I agree with the original post. After learning git, svn feels more complicated and somewhat hackish.
I started to use git one day and never look back.
However, I wish Google project hosting supported git. I know about github, but still …
but still…what?
Sorry, comments have been closed for this post.