Git is sufficiently good at all workflows that "best practices" depend more on your team and code than any tool-enforced limits.

I'm working on moving a dev team from SVN to git myself; the plan that people seem to be happy with is to use git as a drop-in replacement for an iteration or two while people get used to the new tools, and then start introducing people to the more advanced features as and when they seem appropriate, hopefully ending up with a git-flow style workflow.

> Is there any best practice for a large team of 50 developers to work in Git?

Think about how the Linux kernel works. A single person at the top who has final say in the final product, a lieutenant responsible for each smaller group working on one subsystem.

Insist on keeping your history clean. Good commit messages and comprehensible changesets are necessary to make sure the code is understandable by code review, future maintainers, and when different teams' code needs to interoperate.

Unlike Subversion, Git has cheap branching and excellent merging which make branches an easy way to avoid 50 odd developers stamping on each others changes when they commit to master. I recommend checking out Git Flow which is a workflow for managing git branches.

See http://nvie.com/posts/a-successful-git-branching-model/

Using a CI server to test merging branches back to master and running the tests make it a lot easier to know when its safe to merge back to master (I left a comment in the comments earlier about how this can be done).

Shameless plug: http://gitpilot.com (I'm a cofounder). If you're interested, I'd be happy to learn more about the problems you're facing and we could see if Gitpilot would be a good fit or not. You can email me if you're interested: jp@gitpilot.com

That way lies madness.

In SVN is easy to create repositories. Not as easy as on GIT, but very easy.

Also, you can attach different commit-hooks to every repository, related to each project.

In git, I would create a seperate repository for each project. No need to mix up history of several projects into one repsository.

That's possible to do in SVN as well.

You can always use git-svn for local sanity :)

In theory yes, in reality git-svn is driving me insane. I can't wait to move to an all-git solution. Not because I love git but because I can then stop bridging two worlds with git-svn.

You can make git-svn work for non-trivial setups but it took me a lot of trial and error, failed merges and git stashes to make it work for me.

I can feel your pain.

Right now I have this workflow:

  git add filename(s)
  git stash
  git svn rebase
  git svn dcommit
  git stash pop

The worst is failed merges in git svn rebase...