Estratégia de ramificação Git para equipe de desenvolvimento pequena [fechada]

Temos um aplicativo da web que atualizamos e lançamos quase diariamente. Usamos o git como nosso VCS, e nossa atual estratégia de ramificação é muito simples e quebrada: temos uma ramificação principal e verificamos as mudanças nas quais 'nos sentimos bem' nela. Isso funciona, mas apenas até verificarmos uma alteração de última hora.

Alguém tem uma estratégia de ramificação git favorita para equipes pequenas que atende aos seguintes requisitos:

1. Funciona bem para equipes de 2 a 3 desenvolvedores
2. Processo leve e não muito
3. Permite que os desenvolvedores isolem o trabalho com correções de erros e recursos maiores com facilidade
4. Permite manter uma filial estável (nos momentos em que precisamos de nossos servidores de produção)

Idealmente, eu adoraria ver seu processo passo a passo para um desenvolvedor trabalhando em um novo bug

Você pode se beneficiar do fluxo de trabalho que Scott Chacon descreve no Pro Git . Nesse fluxo de trabalho, você tem dois ramos que sempre existem, dominam e se desenvolvem .

master representa a versão mais estável do seu projeto e você só implanta na produção a partir desta ramificação.

develop contém alterações que estão em andamento e podem não estar necessariamente prontas para produção.

Na ramificação de desenvolvimento , você cria ramificações de tópicos para trabalhar em recursos e correções individuais. Quando seu recurso / correção estiver pronto, você o mesclará no desenvolvimento ; nesse momento, poderá testar como ele interage com outros ramos de tópicos nos quais seus colegas de trabalho se fundiram. Depois que o desenvolvimento estiver em um estado estável, mescle-o ao master . Sempre deve ser seguro implantar na produção a partir do mestre .

Scott descreve essas ramificações de longa duração como "silos" de código, onde o código em uma ramificação menos estável acabará "se graduando" em um considerado mais estável após o teste e a aprovação geral da sua equipe.

Passo a passo, seu fluxo de trabalho nesse modelo pode ficar assim:

1. Você precisa corrigir um bug.
2. Crie uma ramificação chamada myfix baseada no desenvolvimento ramo de .
3. Trabalhe no bug nesta ramificação de tópico até que seja corrigido.
4. Mesclar myfix no desenvolvimento . Execute testes.
5. Você descobre que a sua correção está em conflito com outro tópico do hisfix, no qual seu colega de trabalho se mesclou ao desenvolver enquanto você trabalhava na correção.
6. Faça mais alterações na ramificação myfix para lidar com esses conflitos.
7. Mesclar myfix em desenvolver e executar testes novamente.
8. Tudo funciona bem. Mesclar se tornar mestre .
9. Implante a produção a partir do mestre a qualquer momento, porque você sabe que é estável.

Para mais detalhes sobre esse fluxo de trabalho, consulte o capítulo Fluxos de trabalho de ramificação no Pro Git.

Depois de entrar como um novato, tentando encontrar uma estratégia direta para ensinar a outros desenvolvedores que nunca usaram o controle de origem. Esse é o que se encaixa http://nvie.com/posts/a-successful-git-branching-model/ Tentei usar o fluxo de trabalho padrão do GIT que está nas páginas de manual, mas isso me confundiu um pouco e meu público completamente.

Nos últimos 6 meses, só tive que corrigir conflitos duas vezes. Eu adicionei etapas para sempre testar após uma mesclagem e 'buscar e mesclar "ou' pull --rebase" muito (uma vez pela manhã e à tarde) durante o desenvolvimento de recursos. Também usamos o github.com como o local central para obter o código mais recente.

(Fiz meu comentário acima, é a própria resposta, como eu deveria ter feito inicialmente.)

De Scott Chacon, do Github:

Como fazemos Então, o que é o GitHub Flow?

• Qualquer coisa na ramificação principal é implantável
• Para trabalhar em algo novo, crie uma ramificação descritivamente nomeada fora do master (por exemplo: new-oauth2-scopes)
• Confirme essa ramificação localmente e envie regularmente seu trabalho para a mesma ramificação nomeada no servidor
• Quando você precisar de feedback ou ajuda, ou achar que a filial está pronta para a fusão, abra uma solicitação de recebimento
• Depois que alguém tiver revisado e assinado o recurso, você poderá mesclá-lo ao mestre
• Depois de mesclado e enviado para 'mestre', você pode e deve implantar imediatamente

Veja o artigo inteiro para mais detalhes: http://scottchacon.com/2011/08/31/github-flow.html

Observe que "solicitações de recebimento" são uma invenção do Github, e é algo incorporado ao site deles, e não o próprio Git: https://help.github.com/articles/using-pull-requests/

Use a masterramificação como sua ramificação de desenvolvimento e crie ramificações de liberação para executar correções de erros.

Quaisquer novos recursos continuarão masterdurante a janela de desenvolvimento (confirmada diretamente ou como ramificações de tópico com solicitações de recebimento, até você - não mostradas no gráfico). Depois que todos os recursos planejados forem implementados, insira o congelamento de recursos e execute o teste. Quando estiver satisfeito, marque o lançamento mastercomo v1.0.

Com o tempo, seus usuários encontrarão erros, v1.0então você desejará criar uma ramificação a partir dessa tag (por exemplo, nomeie-a após o lançamento 1.0) e corrija esses erros na ramificação. Quando você tiver bugs suficientes corrigidos e achar que isso merece uma nova versão, marque-a como v1.0.1e junte-a novamente master.

Enquanto isso, uma nova janela de desenvolvimento pode estar acontecendo no masterramo, que será marcado como v1.1.

Enxágüe e repita.

Isso segue a lógica de numeração do controle de versão semântico .

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

Em um VCS, ter apenas uma ramificação "principal" mostra rapidamente seus limites, porque você não pode realizar todo o esforço de desenvolvimento ao mesmo tempo em uma ramificação.
Isso significa que você precisa saber quando ramificar .

Mas em um DVCS (como no VCS "descentralizado"), você também tem um problema de publicação , com ramificações que você mantém local nos repositórios e ramificações para as quais está empurrando ou puxando.

Nesse contexto, comece identificando seu esforço de desenvolvimento simultâneo e decida um processo de publicação (push / pull). Por exemplo (e esse não é o único caminho):

• prod é um ramo público somente leitura com o código em produção. Todo mundo poderia usar isso para:
  • rebase seu desenvolvimento atual sobre ele (para testes locais ou para integrar no repositório local de desenvolvedores um hotfix feito no repositório de produtos na filial de produtos)
  • ramificar para fazer novos recursos (de um código estável conhecido)
  • branch para iniciar o próximo branch de release (aquele que deve estar em produção)
    ninguém deve enviar diretamente para prod (daí o somente leitura)
• release é um ramo de consolidação de leitura e gravação, em que as confirmações relevantes são escolhidas para fazer parte do próximo release.
  Todos podem pressionar para liberar para atualizar o próximo lançamento.
  Todos podem retirar-se do referido release para atualizar seu processo de consolidação local.
• featureX é uma ramificação privada de leitura e gravação (na medida em que não precisa ser enviada ao repositório central de produtos) e pode ser empurrada / puxada entre os repositórios de desenvolvimento. Representa um esforço de médio a longo prazo, diferente do desenvolvimento diário
• master representa o dev atual e é empurrado / puxado entre os repositórios de dev.

Existem outros processos de gerenciamento de release, como atesta essa pergunta do SO .

Leia as equipes Git Workflow for Agile da ReinH aqui: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

Isso funciona muito bem para equipes pequenas. O objetivo aqui é garantir que tudo o que possa ser potencialmente instável vá para um ramo de algum tipo. Volte ao master somente quando estiver pronto para que todos que trabalham fora do ramo de recursos o usem.

Nota: essa estratégia dificilmente é específica para o git, mas o git facilita a implementação dessa estratégia.