Basically everything is a matter of conventions. Regarding the top-rated answer items: if you have at least one experienced Git person in the team, you can: 1)

Basically everything is a matter of conventions. Regarding the top-rated answer items: if you have at least one experienced Git person in the team, you can: 1) set up a centralized repo and tell people to use it, 2) use fetch + rebase instead of merge to have a linear history, so managers are happy 3) when you have non-technical people, you can just tell them a standard set of commands to use (ok the hard part is to convince them to the command line). You may set up all the repo (remotes, aliases etc.) for them and tell them exactly the workflow. 4) regarding the locking, IMO it's good to have a number of integrators pushing to master (after the code review) instead of everyone in the team, that way locking shouldn't be really necessary. The real things for me are: 1) checking out subfolders in SVN - indeed might be convenient in big code bases. 2) empty directories Not sure about handling blobs, I didn't have big ones yet. Anyway, I don't know what would make me crave using a non-distributed VCS now after nearly 2 years with Git.