Usando o git corretamente em uma equipe pequena

14

Qual seria a maneira mais fácil de usar o git corretamente em uma pequena equipe de cerca de 5 desenvolvedores, com um servidor executando o aplicativo ao vivo?

version-control git ONOZ
fonte
5
Eu questionaria usando git neste caso. Não há vantagem em usar o controle de fonte descentralizado, quando você tem todas as pessoas em uma sala com um servidor dedicado. E ainda há sobrecarga de puxar / empurrar em cima dos commits.
Euphoric
10
@Euphoric depende de suas ferramentas e fluxo de trabalho.
3
@ONOZ, descreva sua maneira atual de trabalhar com mais detalhes.
22
@Euphoric - Que atitude incrivelmente estreita. Pela facilidade de ramificar e mesclar sozinho gitou hgsupera a maioria dos VCSs centralizados. Eu posso entender as pessoas que ficam irritadas com as pessoas que constantemente reclamam sobre o quão bons são os DVCSs, mas enterram a cabeça na areia e se recusam a reconhecer que você pode desenvolver fluxos de trabalho diferentes e possivelmente mais eficientes com o DVCS do que sem um é tão ruim.
Mark Booth
8
@Euphoric, usar Git não significa que seu controle de origem é "descentralizado". Eu trabalho em uma equipe pequena e usamos o Git, e ainda temos um repositório central. É para isso que você pressiona. O uso de um DVCS geralmente não significa que todas as pessoas estão se afastando de outras pessoas sem um ponto central.
Kyralessa

Respostas:

11

Eu sugiro que você crie um ramo:

  • Produção
  • mestre
  • local

O ramo de produção é "ativo". O aplicativo está em uso no momento.

Quando uma atualização é necessária, um desenvolvedor pode puxar a ramificação principal para a ramificação local. Do que, pode começar a codificar. No final, basta puxar e empurrar da filial local do desenvolvedor para dominar. Um gerente de projeto pode dar uma olhada no ramo principal. Teste-o. E quando estiver pronto, pode mesclar a produção com o mestre. E agora você terá um novo software.

sensorario
fonte
Se você estiver em uma situação de consultoria ou empresa, também poderá ter uma filial para o UAT.
precisa
Concordo, estou usando este fluxo de trabalho.
Cheung
Você poderia explicar por que a diferença entre um ramo local e um mestre? Eu posso ver por que você gostaria de ter uma versão de produção funcionando, mas quando você puxa / empurra as alterações, elas se fundem automaticamente, mesmo sem uma filial local, certo?
Luc
1
Como a ramificação local pode ser nomeada como XXX-feature-name, assim, você tem ramificação mestre como mesclagem de todas as ramificações de recursos que deseja na produção. Sim: porque algum recurso pode não estar incluído.
sensorario 21/10
7

Comece de maneira simples e desenvolva um fluxo de trabalho mais complexo, como e quando necessário.

Seja o que for que você faça, não permita que um modelo de ramificação bem-sucedido do Git seja a primeira coisa que as pessoas veem, isso apenas os confundirá e sobrecarregará. Veja isso mais tarde quando tiver mais experiência.

Eu sugiro que você comece com um gitrepositório central e tenha todos, incluindo sua produção e compilações de teste clonadas a partir disso.

Dentro do seu repositório git, crie um productionramo e um testramo.

Os desenvolvedores devem trabalhar em suas próprias ramificações de recursos locais ou remotas até que sejam concluídas e mescladas master. A partir daqui, eles podem ser mesclados na testramificação para implantação no ambiente de teste e, quando passam nos testes, podem ser mesclados na productionramificação.

Dessa forma, você sempre pode ver o que é novo e não testado, o que é testado, mas ainda não foi implantado na produção e o que realmente está em produção.

Mark Booth
fonte
Opinião interessante, eu consideraria o modelo de ramificação do git um disjuntor do git, por outro lado, pode não ser tão óbvio para os usuários que não são do git.
Wirrbel
@wirrbel Não existe o modelo de ramificação git; você pode implementar o modelo de ramificação que desejar usar gitpara se ajustar ao seu fluxo de trabalho. O que eu sugiro aqui é simples e provavelmente será melhor para gitusuários inexperientes do que um modelo de ramificação bem-sucedido do Git, mas o AsGbm provavelmente será melhor para gitusuários mais experientes , mas não é tão adequado para algumas equipes (pessoas que desejam manter a liberação múltipla) filiais, por exemplo). Como eu disse, o problema com o AsGbm é que ele pode parecer muito complicado.
Mark Booth
Eu entendo o seu ponto. Só para mim, comecei com o AsGbm (ou melhor, adaptei-o às minhas necessidades). Foi perfeito desde que eu podia ver como git poderia ser usado de forma diferente do SVN
wirrbel
7

Temos uma situação semelhante - exceto que temos dezenas de aplicativos da Web, nenhum. Temos usado com sucesso um modelo de ramificação Git bem-sucedido no último ano, aproximadamente, sem queixas significativas.

Wyatt Barnett
fonte
Eu também usei isso para criar modelos de ramificação nos últimos anos. É um modelo fantástico.
precisa
Polegares para cima para o link
Rahul Gautam
0

Você deve ter um repositório principal no servidor de integração e cada desenvolvedor deve cloná-lo. Depois basta puxar e empurrar. Desenvolva novos grandes recursos em ramificações separadas. Nenhuma ciência de foguetes aqui. No servidor ativo - você também deve clonar o repositório principal. E é uma boa prática ter ramificações como "ao vivo" para isso.

Nikolay Fominyh
fonte
2
O git archive é outra opção para implantar no servidor ativo, pressupondo que você realmente não queira editar diretamente coisas no servidor
ativo