Fluxo de trabalho Git para pequenas equipes

Estou trabalhando em um fluxo de trabalho git para implementar em uma equipe pequena. As idéias principais do fluxo de trabalho:

Há um mestre de projeto compartilhado no qual todos os membros da equipe podem gravar
Todo o desenvolvimento é feito exclusivamente em ramos de recursos
As ramificações dos recursos são revisadas por um membro da equipe que não seja o autor da ramificação
A ramificação do recurso é eventualmente mesclada no mestre compartilhado e o ciclo recomeça.

O artigo explica as etapas deste ciclo em detalhes:

https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md

Isso faz sentido ou estou faltando alguma coisa?

— janos
fonte

Respostas:

Eu gosto do modelo de ramificação git flow . A ramificação principal é deixada sozinha na maioria das vezes, contém apenas liberações. O ramo de desenvolvimento deve estar estável o tempo todo, e os ramos do recurso podem ser interrompidos.

Você também pode combinar isso com a integração contínua , mesclando develop em seu ramo de recursos e seu ramo de recursos em desenvolvimento. É claro que você só deve mesclar algo em desenvolvimento quando tiver certeza de que as coisas estão funcionando e não quebram.

— Arjan
fonte

Pelo que entendi, o fluxo de Git e a integração contínua são formas alternativas de trabalho e não podem realmente ser combinadas. No fluxo git, o código é mesclado no desenvolvimento somente quando um recurso é concluído. Na integração contínua, todo o código é mesclado em uma ramificação compartilhada pelo menos uma vez por dia, mesmo que não forneça nenhum novo recurso imediatamente.

— Bdsl

Acho que está faltando o tópico Integração Contínua. Deve fazer parte de todas as configurações de desenvolvimento.

Com ramificações de recursos, você tem o problema de não integrar continuamente, mas somente após a conclusão de um recurso.

Se o recurso ramificado tiver vida curta, isso pode ser aceitável, mas é definitivamente algo que se deve considerar.

Outra alternativa é configurar as compilações de IC para cada ramificação de recurso. Isso com certeza ajuda, mas não é integração. Isso se torna óbvio quando você encontra seu primeiro bug que não aparece no Recurso A nem no Recurso B, mas no momento em que você integra o Recurso A&B

Uma terceira alternativa é tornar a mesclagem em alguma ramificação de integração parte da construção do IC. Essa é uma verdadeira integração e, na verdade, funciona razoavelmente bem com o git se o trabalho for um pouco separado, mas causa conflitos de mesclagem durante a compilação, resultando em compilações com falha.

— Jens Schauder
fonte

A ramificação principal pode ser conectada a um IC para rejeitar mesclagens de ramificação de recurso se elas falharem nos testes de não regressão automatizados. Obrigado pela dica, vou adicionar uma seção "Dicas" no final e mencionar isso lá.

— Janos

Claro, mas como disse, isso não é contínuo-integração, mas at-a-end-of-a-recurso de integração que pode ser bom enoug, mas não é o mesmo

— Jens Schauder

Eu acho que os ramos de recursos são muito úteis, porque eles não precisam ser estáveis. Isso significa que você pode confirmar com frequência, em vez de ter um enorme envio.

— Arjan

Um processo de criação automatizado que é executado em uma programação (sistema de IC) é indispensável. Ele precisa ser executado com frequência para que os problemas de compilação possam ser encontrados e corrigidos rapidamente. As equipes de desenvolvimento devem dar às falhas de construção a maior prioridade. É muito mais fácil corrigir esses tipos de problemas quando eles aparecem pela primeira vez.

— Nathan Pilling

Para nossos projetos que usam IC (temos alguns projetos herdados que não podem usá-lo no momento), comprometemos TUDO a dominar o verdadeiro IC, para nossos projetos herdados usamos o modelo de ramificação git flow. As ramificações de recursos são um bloqueador de IC, se você me perguntar, elas dificultam a integração CONTINUAMENTE (não apenas quando termina). Continuamos trabalhando nos recursos e a tarefa final é ativá-lo basicamente, mas o código está sempre no projeto.

— Elliot Blackburn

Você pode se inspirar no gitflow ou no Twgit .

O gitflow resume sua abordagem como:

Extensões Git para fornecer operações de repositório de alto nível para o modelo de ramificação de Vincent Driessen.

Twgit se descreve da seguinte maneira:

O Twgit é uma ferramenta gratuita e de código aberto para gerenciar recursos, hotfixes e versões nos repositórios Git. Ele fornece comandos simples e de alto nível para adotar o modelo de ramificação descrito em nossa documentação. SO suportado: Debian / Ubuntu Linux, Mac OS X.

Ambas as ferramentas estão disponíveis no github .

— Duran
fonte