Learning version control with git first or via SVN?

Currently a group I am a part of uses SVN. We are looking at moving to git. I have used git personally (and am actually using git-svn to bridge back to the main SVN repository), so I am convinced of its benefits.

One concern is that git is more complex than SVN. We have some brand new folk who will 开发者_Go百科need to learn version control from the beginning. Does anyone have any experience teaching version control by jumping straight into git? I am wondering if it would be just too much or if it might be easier not having to unlearn SVN based expectations.

Does anyone have any experience of either approach - jump straight into git, or get familiar with svn first?

Use what you're going to use. There's no reason to waste time picking up habits that aren't applicable to your production environment. Source control isn't brain surgery - don't make it harder than it has to be.

I think it might depend on the number of users and the setup you have, learning Git for a small user base without too many branches or special features is actually very simple and the core concepts of source control are the same. Where it starts to diverge is when you get a more complex project management strategy with multiple branches and development staff.

So, if you have a small team, I would say jump straight into Git.

If you have a larger team and you jump straight into Git then be prepared to realize you might need to reconfigure how you have setup your repositories at a later date once you understand the system better.

The learning curve for git is pure hell. A little learning is easy, but is also dangerous :-) However, in many ways it is a nice tool, and I don't think your users will be well served by learning svn first. Many of the strengths of git (branching and merging, cloning, disconnected commits) don't make sense in a svn context, or they work differently.

Here are some of the things I tell people when I'm teaching them git:

• Start with Git Magic.
• Don't expect everything to make sense.
• At a superficial level, the git commands seem very powerful and orthogonal, such that lots of combinations work. Don't be fooled. Not every combination works; for example, never try to push to a repository that has checked-out working files, especially if they have changes. Instant lossage!
• Stick to the model that git was designed for: each developer maintains a working repo and a public repo. You make changes to your working repo, push them to your public repo, and pull from other developers' public repos.
• Don't forget the pull is not the dual of push; a pull also does a merge.
• Don't forget that you can't merge until all local changes are committed.
• To manage commits and the index, use git-gui :-)

I don't know which is better, but git exposes some 'higher level' thinking about source control that I wish I had known even when all I knew about was svn...

If you can handle the learning curve, I'd recommend git.

I'm in a similar position: using git-svn while others use plain svn. The difference for us is we came off of VSS to SVN. Trying to teach people about atomic commits was hard enough, I don't think we'll ever try forcing git.

If you have fresh people I'd go for straight git because version control is so much more compelling when you have local commits and

rebase -i