tl; dr - Parece que é hora de avançar para as grandes ligas. Colocar batom em um porco não a torna mais bonita, a menos que você goste desse tipo de coisa ...
O problema das pessoas
O primeiro problema é a sincronização de confirmação. Se você tiver várias pessoas trabalhando no mesmo código ao mesmo tempo, precisará de apenas uma regra para evitar problemas:
Rule 1: Always pull before you merge/rebase
No que diz respeito ao DVCS, é difícil fazer alterações em uma filial remota (ou seja, o repositório principal) e muito fácil fazer alterações no local. Cada pessoa é responsável por ajustar suas próprias adições de código ao todo maior, sem problemas. A menos que duas pessoas se comprometam exatamente ao mesmo tempo, você não deve experimentar. O acesso confirmado ao mestre de origem / remoto deve ser limitado a apenas alguns desenvolvedores e eles devem receber alterações dos outros desenvolvedores por meio de ramificações de rastreamento remoto.
O problema do código
Como você sabe que as alterações feitas não quebram o código?
Resposta simples ... Faça testes para provar que não. Se você ignorar a escola de pensamento TDD (Design Orientado a Testes), o objetivo principal dos testes é adicionar um nível de verificação que permita alterar o código sem quebrá-lo.
Rule 2: Don't make assumptions, write proofs (ie tests).
Além disso, toda a gama de testes deve ser executada antes de você enviar para o mestre de origem / remoto.
Mantenha seus commits tão pequenos e concisos quanto possível. Dessa forma, se você precisar fazer o backup de uma alteração que quebrou algo mais tarde, você evitará a necessidade de reimplementar as partes que não quebraram o código.
Você pode precisar de alguma reestruturação organizacional primeiro
Se as soluções acima não puderem ser facilmente aplicadas, provavelmente há alguns problemas com a estrutura de desenvolvimento que precisam ser resolvidos primeiro.
O proprietário do projeto deve ser o gatekeeper. Se houver problemas de sincronização de confirmação, provavelmente haverá muitas pessoas com acesso de confirmação. Mesmo em projetos maciços como o kernel do Linux, apenas alguns desenvolvedores têm acesso confirmado ao repositório principal de origem / remoto. Na verdade, existem vários níveis de repositórios para gerenciar confirmações. Em vez de um modelo de consolidação de camada única, onde todos estão enviando suas alterações para a origem, o modelo hierárquico possui gatekeepers que realizam alterações e verificam sua qualidade antes da inclusão no projeto. O modelo hierárquico de confirmação pode ser dimensionado muito maior e mais eficaz que o modelo de camada única sem sacrificar a qualidade.
Para os devs que não se cometem acesso, eles devem aprender a criar o seu próprio remotas ramificações de controle (git e Gitorious são bons para isso) para que os devs que fazer se o acesso de submissão pode facilmente puxar / integrar filiais na origem. Se as alterações forem pequenas, os patches também funcionarão.
A capacidade de obter alterações antes de fazer uma mesclagem / rebase pressupõe que você não esteja desenvolvendo em sua ramificação principal local. A maneira mais fácil de lidar com isso é fazer um puxão inicial antes de começar a codificar e, em seguida, fazer todo o seu trabalho nesse ramo. A maneira mais difícil é ramificá-lo antes de mesclar e reverter o mestre.
Defina o estilo de codificação do projeto em geral e faça com que os desenvolvedores o sigam. Os desenvolvedores contribuintes devem escrever um código que esteja em conformidade com os padrões / normas do projeto para minimizar a limpeza. O estilo de codificação pode ser uma grande barreira do ego em um projeto aberto. Se nenhum padrão for definido, todo mundo codificará em seu próprio estilo preferido e a base de código ficará muito feia muito rapidamente.
O mito do "Mês do Homem Mítico"
Acredite ou não, os projetos de código aberto maiores / mais bem-sucedidos não são executados como uma democracia. Eles são executados como uma hierarquia. Afirmar que um projeto não pode crescer efetivamente além de 8 a 10 desenvolvedores é ingênuo. Se isso fosse verdade, megaprojetos como o Linux Kernel não existiriam. A questão mais profunda é que dar a todos acesso de confirmação apenas dificulta a comunicação eficaz.
O problema do mítico homem mês pode realmente ser superado. Você só precisa executar seu projeto como os militares. Existem muitos níveis na hierarquia, porque é do conhecimento geral que pessoas individuais são realmente efetivas apenas no gerenciamento de comunicações com um punhado de pessoas. Desde que nenhum indivíduo seja responsável por gerenciar o trabalho de mais de 5 a 7 pessoas, o sistema poderá ser escalado indefinidamente.
Pode limitar os desenvolvedores melhores / experientes a fazer mais integração e design / planejamento de nível superior, mas isso não é uma coisa ruim. Parte da ampliação é tomar a decisão de decidir que o projeto precisa de um plano de longo prazo. As pessoas dos níveis mais altos que têm o maior investimento (o tempo também é um recurso) no futuro dos projetos devem ser encarregadas de tomar as grandes decisões.
É bom ouvir sobre um projeto de código aberto passando por dores de crescimento. Parabéns e boa sorte.