Repositórios, problemas, vários desenvolvedores e bifurcação da organização Github - Melhores práticas de fluxo de trabalho

Um título estranho, sim, mas eu tenho um pouco de terreno para cobrir, eu acho.

Temos uma conta de organização no github com repositórios privados. Queremos usar os recursos nativos de questões / solicitações de recebimento do github (solicitações de recebimento são basicamente exatamente o que queremos, tanto quanto revisões de código e discussões sobre recursos). Encontramos o hub de ferramentas da defunkt, que possui um recurso interessante de converter um problema existente em uma solicitação de recebimento e associar automaticamente seu ramo atual a ele.

Gostaria de saber se é uma prática recomendada que cada desenvolvedor da organização faça uma bifurcação no repositório da organização para fazer seu trabalho de recurso / correções de bugs / etc. Parece um fluxo de trabalho bastante sólido (como é basicamente o que todo projeto de código aberto faz no github), mas queremos ter certeza de que podemos rastrear problemas e receber solicitações de ONE source, o repositório da organização.

Então, eu tenho algumas perguntas:

1. É uma abordagem de bifurcação por desenvolvedor neste caso? Parece que pode ser um pouco exagerado. Não tenho certeza de que precisamos de uma bifurcação para todos os desenvolvedores, a menos que apresentemos desenvolvedores que não tenham acesso direto por push e precisem de todo o código revisado. Nesse caso, gostaríamos de instituir uma política como essa, apenas para esses desenvolvedores. Então, qual é o melhor? Todos os desenvolvedores em um único repositório ou um fork para todos?
2. Alguém tem experiência com a ferramenta de hub, especificamente o recurso de solicitação de recebimento? Se fizermos um fork por desenvolvedor (ou mesmo para desenvolvedores menos privilegiados), o recurso de solicitação de recebimento do hub funcionará nas solicitações de recebimento do repositório principal upstream (o repositório da organização?) Ou ele tem um comportamento diferente?

EDIT
Fiz alguns testes com problemas, garfos e solicitações pull e descobri isso. Se você criar um problema no repositório da sua organização, faça uma bifurcação do repositório da sua organização para a sua própria conta do github, faça algumas alterações e mescle com a ramificação principal do seu fork. Quando você tenta executar, hub -i <issue #>você recebe um erro User is not authorized to modify the issue,. Então, aparentemente esse fluxo de trabalho não funcionará.

É uma abordagem de bifurcação por desenvolvedor neste caso? Parece que pode ser um pouco exagerado. Não tenho certeza de que precisamos de uma bifurcação para todos os desenvolvedores, a menos que apresentemos desenvolvedores que não tenham acesso direto por push e precisem de todo o código revisado. Nesse caso, gostaríamos de instituir uma política como essa, apenas para esses desenvolvedores. Então, qual é o melhor? Todos os desenvolvedores em um único repositório ou um fork para todos?

Depende da escala do seu time, eu acho. Eu trabalhava em uma equipe pequena, onde tínhamos apenas um repositório único e os recursos tinham suas próprias filiais nesse repositório. Isso funcionou muito bem para nós.

No entanto, agora contribuo regularmente para um projeto maior de código aberto, no qual algumas dezenas de pessoas têm acesso ao repositório central. Ainda fazemos todo o desenvolvimento principal em repositórios pessoais e enviamos PRs para recursos, para que o código possa ser revisado, embora as correções possam ser enviadas diretamente. O repositório principal carrega apenas ramificações principais e de liberação, mantendo-o livre de desordem. As ramificações dos recursos estão em repositórios pessoais, para que ainda possam ser vistas por outras pessoas (criar PRs iniciais para eles alertará outras pessoas da equipe de que o trabalho em um recurso está em andamento). Eu posso recomendar esse fluxo de trabalho para qualquer projeto com mais de um punhado de desenvolvedores; a única desvantagem disso é ter que trabalhar com vários controles remotos.

A abordagem de bifurcação por desenvolvedor é uma abordagem muito boa se você valoriza as análises e a qualidade do código. O bom de usar solicitações pull é que ela transfere a responsabilidade do mantenedor para o desenvolvedor.

O desenvolvedor deseja inserir seu código no ramo principal e solicita sua inclusão.

Esse é um contexto muito diferente do modelo antigo em que as pessoas se comprometem e, mais tarde, o revisor teve que dizer a elas "ah, isso que você fez algumas semanas atrás não era tão bom, conserte-o agora".

Usamos esse modelo em nossa empresa. As solicitações pull tornaram viáveis ​​as solicitações de código, incentivam a discussão sobre o código de outras pessoas e geralmente ajudaram na qualidade do código, mesmo com os desenvolvedores que foram os primeiros contra a nova ferramenta. Eu sinto que isso também fez as pessoas levarem as revisões de código mais a sério, porque o revisor precisa mesclar ativamente o código no ramo principal, em vez de apenas dizer 'ok' ou 'não ok' depois que o código já foi confirmado.

Eu não faria todo o garfo e ramificação para tudo. Esse é um bom modelo para gemas de código aberto no github, mas seu modelo está dentro de uma organização que normalmente teria um nível mais alto de confiança sobre as mudanças.

Um ponto importante do controle de origem é que você pode ver, voltar, reverter, etc. mudanças. Fazer um alto número de garfos e filiais na sua situação é um IMHO exagerado.

Eu reservaria ramos para coisas como: atualizações de versão, alterando uma das peças de tecnologia, trabalhando em um submódulo por 3 meses que tem pouco em comum com a base principal.

Talvez eu não seja bifurcado em uma organização. Esse modo parece mais adequado para projetos de código aberto de natureza diferente dos projetos internos.

Eu mudaria seu foco para testes e revisões de código. As pessoas estão escrevendo testes? Eles são bons? As revisões de código são feitas?