Now I'm freelance I've had the time to put into learning Git and I'm glad I did, but the point is there are still a lot of people using SVN, some of whom will switch to Git in the future, and posts like this can be very useful to them.
How true this is. I spoke with one sysadmin who told me that even if 100% of the developers were using git-svn he would never allow git as the official location to store code on the servers and it must be pushed back to svn. I am not sure how to respond to people like that.
Edit: When pressed for more details it was clear that he was happy with his svn server setup and didn't want to change and have to learn something new. This was not a logical discussion, but an emotional one and as he ran the servers he had the final say.
Thing is, I understand svn. I get it, and I have used it for years and know, almost instinctively now, what will happen when I use the various commands.
Git for me just feels overly confusing. I suppose it's just because I'm used to "the old way" but just take a look online at how many articles that are out there trying to explain how git works. Why are so many needed? It feels like there are many more than there are explaining how svn works.
By the way, I can see the benefits of git and I feel I'm getting the hang of it quite well now, but I still like svn :)
It's not really that hard to learn btw. There are some esoteric things that can be tricky but the Svn workflow can be learned in a day or two tops.
Perforce seems to be entrenched in more corporate environments.
So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team?
Guess I'm really just trying to figure out if git is so amazingly better that I really am under a rock (I'm not seeing that), or if it's more of the "if you're not using {latest hip tech} you're not to be taken seriously" kind of thing that we see so much on HN.
(sorry about new account -- can't find original credentials)
apparently there was enough interest to bump it to the front page.
I think that we're still not fully taking advantage of Git because the other members of the team tend to commit and push all the time (so the code is backed up) but that makes rebasing and squashing quite difficult.
Git has also allowed us to work better with maintaining feature branches and bug fix branches which helps us to give individual branches to QA for test and only release those features/fixes that have been QA approved. If a feature isn't ready on time for deployment, it just doesn't get added to the integration branch and it'll go out the next release. That's pretty cool.
Personally, I've settled on using SourceTree as a GUI with a fallback to the command-line for certain operations.
As for squashing or not, I rarely do, and in general only squash commits that are simple typo fixes. This makes bisecting much easier.
Also, and this may or may not be relevant, maybe some people are reluctant to spam the central repository with their own temporary branches. To avoid this, I have everyone in my team set up a personal, backed up repository. Anyone can pull from these personal repos, but only their owners can push to them. When the temporary branches are done, they can be merged.
I like what Paul Stadig had to say on the topic http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebas...
Really? How? I've always found Subversion branching to be painless, reliable, fast enough, and merges often go flawlessly, and it's really not been that hard to resolve merge conflicts.
