Gerenciando várias pessoas que trabalham em um projeto com o GIT

32

Sou muito novo no GIT / GitHub (tão novo quanto a partir de ontem). Gostaria de saber qual é a melhor maneira de gerenciar várias pessoas trabalhando no mesmo projeto com o Github. Atualmente, estou gerenciando um projeto com quatro desenvolvedores.

Como faço para executar o fluxo de trabalho e garantir que tudo esteja sincronizado?

(Nota: todos os desenvolvedores terão uma conta universal.)
Cada desenvolvedor precisa estar em uma ramificação diferente?
Serei capaz de lidar com duas pessoas trabalhando no mesmo arquivo?

Por favor, poste uma resposta detalhada, eu não sou um leitor tímido. Eu preciso entender isso bem.

git github

— badZoke
fonte

7

Uma conta para todos os desenvolvedores? Isso pode funcionar, mas provavelmente não é uma boa ideia.

— Marstato #

1

Veja nvie.com/posts/a-successful-git-branching-model

— Brad Thomas

Pode valer a pena olhar para o GitFlow e o desenvolvimento baseado em tronco . Pessoalmente, tive grande sucesso com este último

— J Lewis

29

Se todos os desenvolvedores tiverem acesso confirmado ao repositório, não será necessário fazer nada de especial. Eles puxam as mudanças do repositório, fazem suas próprias alterações, confirmam localmente e depois retornam ao repositório público quando têm algo funcionando.

Se, por outro lado, você tiver um (ou alguns) desenvolvedores responsáveis por se comprometer com o repo, e os outros estiverem fornecendo patches para eles. Faça com que cada um deles clone o repositório em suas próprias contas e envie solicitações de recebimento quando houver uma alteração desejada no repositório principal.

Também é possível criar clones específicos para trabalhar em recursos específicos, se desejar. Usando o mesmo fluxo de trabalho com solicitações pull para obter alterações no repositório principal quando o recurso estiver concluído.

Se por "Todos os desenvolvedores terão uma conta universal", você quer dizer que todos os desenvolvedores compartilharão uma conta do GitHub e aparecerão como o mesmo responsável pelo repo, isso é uma má idéia. Crie contas separadas e configure-as como colaboradores, se desejar que todas elas tenham acesso de confirmação.

Quanto às suas perguntas específicas:

Não, use branches para recursos, correções, etc, que levarão mais de um commit. Mais de um desenvolvedor pode estar trabalhando no mesmo ramo.
Sim, o git lida com conflitos muito bem, então não há problemas em ter pessoas trabalhando no mesmo arquivo. Sem problemas, exceto, a resolução de conflitos nem sempre pode ser trivial se houver alterações fundamentais em um arquivo que foi editado por mais de um membro. No entanto, isso não pode ser superado conversando juntos. O controle de versão não substitui a comunicação.

Boa sorte!

— harald
fonte

Um par de pontos que você fez, existem realmente reveladores, me fizeram pensar em uma direção diferente todos juntos, obrigado!

— badZoke

Hapy se puder ajudá-lo. Git e DVCS exigem algum tempo para se acostumar, mas são extremamente flexíveis quando você se acostuma.

— Harald

Obrigado por isso. Eu tive uma pergunta específica. Se houver vários desenvolvedores trabalhando no mesmo ramo. Sempre que um dos desenvolvedores faz alterações e envia para o ramo de trabalho, o restante dos desenvolvedores precisa fazer as alterações (para garantir que eles tenham o código mais recente localmente para trabalhar)?

— perfil completo de Eswar Rajesh Pinapala

Não, nem sempre, apenas quando você deseja sincronizar. Considere sua cópia local da ramificação como sua ramificação privada e a ramificação upstream como a que você deseja mesclar. Usar algo como git fetch upstreamseguido por git merge upstream/branchvocê deve sincronizar sem reescrever o histórico de consolidação local. Se isso não for um problema, simplesmente git pull --rebasemova suas alterações locais não pressionadas para a parte superior da ramificação upstream.

— 21713 harald

@badZoke .... o que você fez para lidar com a sua terceira questão (punho 2 pessoas que trabalham no mesmo arquivo) ...

— Moumit

25

Trabalhamos com 2 desenvolvedores e usamos este fluxo de trabalho:

No Github, temos um ramo mestre e um ramo dev
A ramificação principal é igual à produção ou contém código pronto para implantação
O ramo dev está à frente do mestre e contém todo o novo código atualmente sendo trabalhado
Localmente, trabalhamos no ramo dev e pressionamos o github quando algo está pronto
O outro desenvolvedor busca novas alterações no ramo de desenvolvimento antes de enviar seu novo código
Quando o ramo dev é bom, nos fundimos com o ramo mestre
Localmente, temos vários ramos de recursos emitindo ramos etc.

— John
fonte

1

Agradável e simples, muito obrigado! Vou começar com isso, antes de passar para as coisas complexas;)

— badZoke 12/12/12

E se, quando o outro desenvolvedor buscar as novas alterações, antes de enviar seu código, as novas alterações alteram o código que ele já mudou?

— wayofthefuture

+1, este é realmente o mais simples para começar e funciona perfeitamente. O que você está usando é chamado de gitflow simplificado: marcgg.com/assets/blog/git-flow-before.jpg

— Jelle

5

Vejo apenas respostas em texto aqui, então pensei em publicar uma foto de um bom gitflow para começar. Uma imagem descreve mais de mil palavras:

Esse fluxo também funciona bem com a implantação contínua.
Sua ramificação mestre contém o código atualmente em execução no servidor de produção.
Sua ramificação de desenvolvimento contém código atualmente em execução em um servidor de temporariedade / teste.

— Jelle
fonte

+1, fluxo git ou algo semelhante é provavelmente a resposta certa para esta pergunta.

— Maybe_Factor

0

Eu trabalho com outros 3 desenvolvedores e lutamos bastante com isso. Às vezes, os desenvolvedores enviam commits para a produção que ainda não estão prontos para o horário nobre, porque eles inserem outros commits em suas alterações e depois enviam para a produção. As ramificações da versão parecem funcionar bem para nós. Portanto, se a versão 1.0 for a versão estável atual, criaremos um ramo para o v1.1-development. Os desenvolvedores farão alterações neste ramo. Nosso servidor de teste faz check-out dessa ramificação e realiza as alterações necessárias. Quando todos os recursos da v1.1 estiverem prontos e o teste estiver concluído, mesclaremos a v1.1 com master e push. Com filiais, a equipe de desenvolvedores A pode trabalhar na v1.1 e a equipe de desenvolvedores B pode trabalhar com a v1.2. Ambas as equipes podem trabalhar sem se impactar. Se a equipe A desenvolver algo que B possa usar,

Também usamos um ramo de hotfix usado para alterações imediatas.

Aqui está um link para uma imagem de como isso se parece. http://nvie.com/img/git-model@2x.png

— Greg
fonte

Isso não soa para mim como se estivesse realmente implementar fluxo git como foi planejado - que é dividir cada recurso independente ou correção para o seu próprio ramo, ao invés de apenas cada versão

— Brad Thomas