6 ms·

Is there any best practice for a large team of 50 developers to work in Git? We have about 20 separate (almost completely separate) projects. We currently hav

Is there any best practice for a large team of 50 developers to work in Git? We have about 20 separate (almost completely separate) projects. We currently have everything under one big SVN directory. I use git for personal stuff so it's always a pain to work in SVN.

Shish2k 14y ago
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.
groby_b 14y ago
You can always use git-svn for local sanity :)
- zwieback 14y ago
  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.
  - Shorel 14y ago
    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...
csense 14y ago
> 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.
i386 14y ago
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/ 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).
jonpaul 14y ago
Shameless plug: http://gitpilot.com 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
_ikke_ 14y ago
In git, I would create a seperate repository for each project. No need to mix up history of several projects into one repsository.
- Shorel 14y ago
  That's possible to do in SVN as well.
Shorel 14y ago
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.

Shish2k 14y ago

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.

groby_b 14y ago

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

zwieback 14y ago
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.
- Shorel 14y ago
  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...

csense 14y ago

> 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.

i386 14y ago

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/ 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).

jonpaul 14y ago

Shameless plug: http://gitpilot.com 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

_ikke_ 14y ago

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

Shorel 14y ago
That's possible to do in SVN as well.

Shorel 14y ago

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.