Os colaboradores de um repositório particular do Github devem dividir o repositório cada um?

No momento, estou trabalhando em um projeto e temos o código-fonte em um repositório particular no Github, com cada um de nós como colaborador.

O que não sabemos é como separar cada um de nossos trabalhos.

O que acho que precisamos fazer é:

Cada um de nós precisa bifurcar o repositório
Quando estivermos prontos para enviar o código por push, enviaremos uma solicitação de recebimento ao representante do líder do projeto, que poderá, ao mesmo tempo, usá-lo como uma oportunidade para fazer uma revisão do código.

Quando se trata de repositórios particulares, é para isso que o bifurcação deve ser usado ou estou complicando demais a situação?

— JMK
fonte

Sim. Faça como você sugeriu aqui, apenas crie uma equipe e torne o repositório da equipe o repositório "mestre". Todo mundo faz PRs, incluindo o líder do projeto.

— RubberDuck

A clonagem do repositório na máquina local do desenvolvedor já é uma espécie de bifurcação. Se cada desenvolvedor bifurcar o repositório no GitHub, isso servirá apenas para publicar seu estado atual de trabalho.

Isso pode ser apropriado quando houver um repositório principal central e muitos colaboradores não confiáveis com acesso direto a esse repositório. Isso funciona muito bem para projetos de código aberto, onde todos podem contribuir e emitir uma solicitação pull que é então revisada e mesclada por um grupo de mantenedores principais. O uso de vários repositórios impõe um fluxo de trabalho baseado em solicitação de recebimento.

Em uma equipe pequena e confiável, isso não é necessário. Para impedir que pessoas diferentes se interajam, é possível seguir uma estratégia como o Git Flow: Cada recurso pequeno é implementado em um ramo de recurso separado. Quando o recurso é concluído, ele é mesclado na ramificação principal. A maioria das equipes associa isso a uma solicitação pull ou revisão de código por convenção, mas é confiável o suficiente para ignorar isso, se apropriado. Enquanto repositórios separados levariam um desenvolvedor a publicar seu estado atual em repositórios bifurcados, mas visíveis pela equipe, em um único repositório comum, eles enviariam suas alterações para um ramo de recurso separado. Fazer todo o desenvolvimento no mestre / tronco é altamente desencorajado na maioria dos fluxos de trabalho.

A diferença acaba sendo exclusivamente sobre gerenciamento de acesso e não muito sobre o fluxo de trabalho implementado. Você pode executar fluxos de trabalho baseados em solicitação de recebimento com qualquer uma das configurações. De uma perspectiva básica do Git, não há muita diferença entre uma bifurcação e uma ramificação - a abordagem compartilha essencialmente o histórico do projeto e permite que as confirmações sejam adicionadas sem afetar outras ramificações / bifurcações. Considerando isso, seria muito melhor compartilhar um único repositório em um grupo fechado e confiável.

— amon
fonte

Apenas para ecoar rapidamente o que o @amon diz, trabalhei em uma organização em que todos os desenvolvedores precisavam de um repositório principal, o que todos sentimos ser apenas uma etapa extra desnecessária e desajeitada. Eu nunca entendi por que isso era necessário, mas nossa equipe de operações não discutiu isso. O processo foi: commit -> push -> pull request -> wait -> wait some more -> tente chamar a atenção da equipe de operações no IRC -> vá até o pessoal da operação e peça para que olhem para a solicitação pull -> aguarde -> código integrado -> repita.

— DaveyDaveDave #:

Eu realmente desencorajo esse fluxo de trabalho. Eu experimentei conflitos de mesclagem muito ruins com dois desenvolvedores, pressionando diretamente para o repositório canônico. Sem mencionar, ainda é melhor ter alguém para revisar seu código. É muito mais fácil enviar solicitações de recebimento se cada um de vocês tiver uma bifurcação e houver um repositório canônico de projeto. Sim Sim. Eu sei, isso não é "distribuído". Tanto faz. O modelo de garfo e relações públicas funciona melhor em minha experiência.

— RubberDuck

@RubberDuck esse é um bom argumento, suspeito que meu caso seja raro, pois as pessoas responsáveis pelas solicitações de recebimento não estavam em posição de revisar o código, o que o tornou inútil. Sugiro que outras ferramentas dedicadas à revisão de código, como o gerrit, sejam mais eficazes, mas entendo que o bifurcação pode (deve) funcionar da mesma forma.

— DaveyDaveDave

O problema é quem determina quando o recurso está pronto para entrar no mestre? Também acho confuso trabalhar com galhos; Centenas de ramos em um repo e a maioria deles está imersa ou incompleta, por que eles deveriam existir se não estão prontos para serem mesclados? O gerenciamento de acesso é 100% sobre o fluxo de trabalho; essa resposta é apenas metade boa.

— Rudolf Olah

Isso funcionaria, ou você poderia usar um método de ramificação no qual cada contribuição tem suas próprias ramificações, que quando a equipe concorda, são mescladas com o mestre.

— Margeaux Spring
fonte

Obrigado, indo para ir com a outra resposta que tem mais detalhes, mas sim concordo :)

— JMK