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


186

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

Respostas:


247

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.


7
Também Scott Chacon tem um excelente artigo em seu site sobre como fluxo de trabalho do Github com Git funciona - scottchacon.com/2011/08/31/github-flow.html
program247365

71
Eu acho que isso é ótimo, exceto se você cria ramificações de correção de bugs a partir da ramificação de desenvolvimento, você está forçando você não pode mesclá-lo no master e implantá-lo sem também se fundir em tudo o mais "novo" que você ainda não lançou, o que pode ser uma dor real se houver algo nesse ramo que precise de alterações na documentação / banco de dados ou algo mais difícil de fazer. Eu acho que para "hotfixes" urgentes, você deve fazer sua ramificação do mestre.
Richard

5
E se estivermos desenvolvendo 2 recursos separados, F1 e F2, onde F1 será lançado em uma semana, mas F2 será lançado em 2 semanas, assumindo que o desenvolvimento de F1 e F2 coincida? Alguma sugestão sobre isso?
Murat Derya Özen

4
A developé uma 'solução' desnecessária para um problema que o git não tem. Tanto quanto posso dizer, o sucesso se deve a um artigo bem escrito e mal orientado, sem comentários permitidos. Aqui está um contra-artigo barro.github.io/2016/02/…
Tim Abell

5
Na etapa 8, mesclar a ramificação de desenvolvimento ao mestre parece uma péssima ideia, já que parte do código em desenvolvimento pode não estar pronto para entrar em produção. Não seria melhor mesclar a ramificação do recurso no mestre?
Todd

45

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.


Esse é um excelente link! Esse fluxo de trabalho funciona muito bem para nossa pequena equipe, que sempre trabalha remotamente e paralelamente em várias versões ao mesmo tempo. Muito bem documentado. Obrigado Clutch!
precisa saber é o seguinte

Ah, então foi aqui que encontrei esse link :-) Examinei várias estratégias do Git antes de configurar meu primeiro projeto Git (mudei do SCCS para o CVS para o SVN ao longo dos anos e agora queria experimentar o Git para um novo projeto ) e esse foi o que fez mais sentido para mim. Reconheço sua postagem, por isso tenho certeza de que foi aqui que a encontrei. Então, obrigado - funciona maravilhosamente bem!
Boise

4
Morro um pouco por dentro toda vez que vejo alguém pegar aquela publicação no blog. Aqui está uma refutação: barro.github.io/2016/02/…
Tim Abell

Eu compartilho o mesmo sentimento com você @TimAbell; Eu sinto fortemente que não está certo quando o default master branchNÃO é usado com mais frequência como desenvolvedor nisso #A successful Git branching model
Nam G VU

35

(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/


4
Com uma equipe menor e desenvolvedores menos experientes com o git, a simplicidade desse fluxo de trabalho vence. A única coisa que fazemos de maneira diferente é ter uma ramificação de 'teste' entre a ramificação do recurso e o mestre, que atua como um site de controle de qualidade ao vivo para que não desenvolvedores aprovem o recurso em um ambiente semelhante à produção.
Esquadrões

O @ Squadrons parece que você precisa de um polvo para isso, que possui portões embutidos para permitir / negar que as construções cheguem a ambientes diferentes e não poluem seu controle de origem com essas coisas.
Tim Abell

Criar ramificações de recursos fora do mestre e, em seguida, mesclá-las novamente para implantação é bom, desde que você tenha uma tag, para que haja um ponto de reversão seguro. As implantações nem sempre seguem o planejado. Se você acredita em "avançar apenas" não importa muito quando está com problemas de dinheiro.
Navalha

15

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

5
Não se esqueça de mesclar suas 1.0.1alterações de volta paramaster
kwahn

E lembre-se sempre de refazer o 1.1master após a mesclagem 1.0.1- isso ajuda a minimizar a confusão.
Nam G VU

@NamGVU Eu não recomendaria isso. 1.1é um ramo de release e possui tags que representam o estado exato de um ou mais releases. A redefinição desse ramo causaria a perda dessa representação. Eu recomendo fortemente que você defina seus ramos de liberação para negar os impulsos de força para evitar isso.
Leif Gruenwoldt 22/11

1
Não. Não mescle ramificações de liberação novamente no mestre! Isso pode causar todo tipo de dor de cabeça que você não precisa (mesclando apenas material de lançamento, mesclando conflitos com lançamentos mais recentes, quebrando construções, histórico não linear etc.) Acredite, já vi isso acontecer mais de uma vez) . Em vez disso, trate as liberações como garfos. Veja bitsnbites.eu/a-stable-mainline-branching-model-for-git
m-bitsnbites.

4
cherry-pick é uma opção melhor para recuperar liberação transforma em mestre
BartoszKP

4

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 .


3

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.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.