Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nice post, thanks.

I've been using traditional RCSs for years but find that whenever I introduce SVN (or CVS before that) to a team it's very easy for new users to fall into bad habits around branching and committing transitory changes.

I'd like to try git to help manage the mess during the prototyping phase but I'm wondering how suitable it is for new users to learn git vs. learning svn.

Any opions out there on the suitability of git as a first version control system? My team consists of highly experienced engineers (EE/FW) with little or no software engineering experience.



they sound like smart people. why hobble them with svn in 2011?

i put off the transition as long as i could out of inertia (switched from svn in 08 out of desperation when i started needing a lot of branch and merging). but once you go git, you dont look back, not one bit.


When you are used to the SVN/CVS workflow, it takes a long time to get over it. It took me a long time to understand why the distributed approach is better, despite having read a lot about them. In my company we are using git as well, but most developers refuse to work anywhere else than on master. They probably had their share of trouble with branching in other systems.


It's Mercurial-based, not git-based, but you might have them read HGInit, by Joel Spolsky:

http://hginit.com

Really, really approachable guide to how to properly use a DVCS.


I found the thing that tipped the scales for people who were set in their ways was walking them through a merge and showing that tree conflicts don't exist. And that merging doesn't need to take more than 5 minutes.

I work on a codebase that changes pretty fast, and git has hugely reduced time wasted screwing around with tree conflicts and SVN losing its lunch.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: