What's a typical team size using a Git repo?

Question

We've been using Git as our version control but as the team grows, there are more and more pains when it comes to getting all our changes onto a single branch ready for a deployment.

I'm wondering if maybe we're outgrowing Git as an effective collaboration tool. I know there are large OSS projects with many developers that use Git but there also tend to be some gatekeepers responsible for the merging of branches into the final build/deployment branch.

In an office environment, where the developers are relatively independent and can be trusted to merge their own changes, how many people can effectively collaborate on Git?

Additionally, are there any tips for effective use of Git? We've been using the rebase workflow, I'm not entirely convinced switching to a merge based workflow would improve the situation but then, I haven't seen a formal description of how a large group would work together in a merge workflow (It seems like the history would just turn into merge hell).

Addendum:

So that it's easy to find for anyone else wondering:

• We're using a feature branch strategy
• The code base is well organized and pretty clean. It's Python (with some HTML/JS), MVC via pyramid for the web app, separate package (different top level folder in same repo, itself split up into well defined layers) for a large chunk of the non-web specific application functionality.
• We experience pain as far as merging code because developers are frequently making changes in the same files, like, one dev owns auth, so they're touching the views, etc... related to auth, but another dev is handling internationalization, so they're touching all the views, etc.

Answer 1

Well, git is up to the task to handle the linux kernel, right? It worth a look to feel the number of patches, branches, contributors....

Based on that I don't think there is a size limit. Also I doubt there exist any better source control system these days, so even if it had, nothing to switch to.

However I feel for your problems, those are definitely real. You need project organization. You need check-in rules, code policies, branching policy, culture, and a lot of other teamwork related things for good results. git is merely a database with convenient features to store and manipulate sources and history. It never pretended as a "system" or replacement for one. Or a general collaboration tool.

For non face-to-face collaboration there are actually good supplement tools like bugzilla, wikis, project planners. We use FogBugz with Kiln -- the latter just learned git, and it allows to streamline many workflows related to assigment of tasks, verification and especially reviews. You need to assemble some system like that. And certainly keep up real people interactions and a learning environment.

For git history handling, yes, I also suggest rebasing for most times, especially single patches. But use branch merges, even on top with --no-ff if for a single topic. Before integration to master make the code reviewed and consolidated (rebasing on self) to meld fixups and post-review work. Don;t be afraid to fix the master if it goes out of shape.

To avoid "upstream reabase" related problems my rule is to create an amend_NN branch on the old and fixed_NN on the new state with matching numbers, so anyone can easily discover that his work must be rebased and avoiding resurrect of dropped things.

The branching policy must be based on the general work and release approach. I keep a single master but you can find more elaborate schemas that have a separate development master.

NOTE: By 'bugzilla' I meant the tracker genre in general not the particular product directly, in decision making I got great help from tracker compare wiki . OTOH I do have positive experience with Bugzilla itself from previous places too.