Fluxos de trabalho do Git para profissionais: um bom guia do Git

O Git pode dar suporte ao seu projeto não apenas com controle de versão, mas também com colaboração e gerenciamento de lançamento. Entender como os padrões de fluxo de trabalho do Git podem ajudar ou atrapalhar um projeto lhe dará o conhecimento para avaliar e adaptar os processos do Git do seu projeto de forma eficaz.

Ao longo deste guia, isolarei os padrões de processo de desenvolvimento de software encontrados em fluxos de trabalho comuns do Git. O conhecimento disso ajudará você a encontrar uma direção ao ingressar, criar ou aumentar uma equipe de desenvolvimento. Os prós e contras de certos tipos de projetos ou equipes serão destacados nos exemplos de fluxo de trabalho que exploramos, para que você possa escolher o que pode funcionar bem para o seu cenário.

Esta não é uma introdução ao uso do Git. Já existem guias e documentação fabulosos para isso. Você se beneficiará deste guia de fluxo de trabalho Git se já tiver experiência em uma equipe de desenvolvimento de aplicativos e tiver enfrentado problemas de fluxo de trabalho, implosões de integração ou git-tastrophes - esses padrões podem esclarecer como evitar essas situações no futuro.

Colaboração

Em termos de processo Git, a colaboração geralmente envolve fluxos de trabalho de ramificação. Pensar no futuro sobre como você irá entrelaçar as árvores de commit ajudará você a minimizar os bugs de integração e apoiará sua estratégia de gerenciamento de lançamentos.

Filial de Integração

Use uma ramificação de integração com equipes de desenvolvimento de software que trabalham para implantar uma coleção de contribuições na produção como uma entidade única. Isso se opõe a equipes que se concentram na implantação de recursos individualmente. Muitas vezes, as equipes podem querer fazer o último, mas as limitações práticas impõem um processo que agrupa seus esforços, e a equipe acaba fazendo o primeiro, portanto, revise seu uso real do Git para ver se você se beneficiaria com esse tipo de colaboração padronizar.

Esse padrão de fluxo de trabalho é um ponto de preparação útil para quando o risco de integrar várias ramificações é alto o suficiente para justificar o teste das contribuições combinadas como um todo.

Uma ramificação de integração geralmente consiste em um recurso principal e várias contribuições menores a serem implantadas juntas. Coloque uma ramificação de integração no processo de sua equipe de desenvolvimento (perguntas e respostas e testes de aceitação, por exemplo). Envie pequenos commits para ele para deixá-lo pronto para produção e, em seguida, use um branch de ambiente ou um branch de lançamento (discutido abaixo) para prepará-lo para implantação.

Esteja ciente de que as contribuições na ramificação de integração precisam ser mescladas no próximo estágio de lançamento antes que outro recurso principal possa ser mesclado na ramificação de integração - caso contrário, você estará misturando recursos em diferentes estágios de conclusão. Isso inibirá sua capacidade de liberar o que está pronto.

Ramificações do tópico

As equipes vão querer usar ramificações de tópicos se for importante manter suas árvores de confirmação em um estado que possa ser lido facilmente ou ter recursos individuais revertidos. Ramificações de tópico significam que os commits podem ser substituídos (usando um push forçado) para limpar sua estrutura e ser reduzidos a um commit de recurso.

As ramificações de tópicos geralmente são de propriedade de um colaborador individual, mas também podem ser um espaço designado para uma equipe desenvolver um recurso. Outros contribuidores sabem que este tipo de branch pode ter sua árvore de commit reescrita a qualquer momento, e não devem tentar manter seus branches locais sincronizados com ele.

Sem utilizar ramificações de tópicos em seu fluxo de trabalho Git, você está restrito a manter os commits que você envia para uma ramificação remota. Forçar o push de uma nova árvore de commit para uma ramificação remota pode irritar outros contribuidores que dependem da integridade mantida da ramificação com a qual eles sincronizam.

É provável que você já use esse padrão de fluxo de trabalho sem perceber, mas vale a pena ter um conjunto compartilhado de definições entre as equipes para reforçar as práticas por trás delas. Por exemplo, você pode achar que a convenção de prefixar o nome da ramificação com as iniciais do criador da ramificação ajuda a sinalizar quais são as ramificações do tópico. De qualquer forma, cabe à sua equipe decidir sobre as convenções internas.

NÃO use ramificações de tópico em repositórios públicos, você causa uma infinidade de conflitos para qualquer um que tenha sincronizado suas ramificações locais com uma ramificação de tópico que teve sua árvore de commit reescrita.

Garfo

Projetos de código aberto prosperam usando esse recurso originado do Github. A bifurcação capacita os mantenedores do repositório com um gateway imposto sobre o envio direto para uma ramificação do repositório de origem, mas, mais importante, facilita a colaboração. Uau!

Você pode se encontrar no cenário em que a criação de um fork de um repositório privado também atende às suas necessidades. Definir o repositório de origem como somente leitura para os contribuidores do repositório fork e rolar com pull requests oferece os mesmos benefícios que a experiência da comunidade de código aberto. Equipes de diferentes organizações podem trabalhar de forma eficaz usando um fork que pode ser a plataforma para comunicação e aderência às políticas do projeto.

O padrão de fluxo de trabalho fork dá às equipes seu próprio espaço para trabalhar da maneira que estão acostumadas com um único ponto de integração entre os dois repositórios - uma solicitação pull. A comunicação excessiva é imperativa na descrição da solicitação pull. As equipes tiveram fluxos de comunicação separados antes que uma solicitação pull fosse emitida e destacar as decisões que já foram tomadas acelerará o processo de revisão.

É claro que um benefício do fluxo de trabalho do fork é que você pode direcionar comentários para os contribuidores do repositório de origem, pois as permissões são em cascata para baixo. Do ponto de vista do repositório de origem, você tem o controle para excluir bifurcações quando elas não forem mais necessárias.

Certifique-se de estar usando uma ferramenta que facilite as solicitações de bifurcação e pull para aproveitar esse padrão. Essas ferramentas não se limitam ao Github: outras opções populares são Bitbucket e GitlLab. Mas existem alguns outros serviços de hospedagem de fluxo de trabalho Git que terão esses recursos (ou similares). Escolha qual serviço funciona melhor para você.

NÃO use um fork de um repositório privado para cada membro de uma equipe. Os vários repositórios bifurcados podem dificultar a colaboração de vários membros no mesmo branch de recursos, e manter todos esses repositórios sincronizados pode se tornar propenso a erros devido ao grande número de partes móveis. Projetos de código aberto têm membros da equipe principal com acesso push ao repositório de origem que diminui essa sobrecarga.

Clone

Uma estratégia comum de terceirização é ter “lugares” de contribuição em um projeto que pode ser preenchido por vários desenvolvedores de software. Cabe à empresa de terceirização gerenciar seu pipeline de recursos para entregar as horas contratadas, os problemas que enfrentam são como integrar, treinar e manter um pool de seus desenvolvedores para os projetos de cada cliente.

O uso de um clone do repositório do projeto estabelece um campo isolado de treinamento e comunicação para que a equipe terceirizada gerencie suas contribuições, aplique políticas e aproveite o compartilhamento de conhecimento - tudo sob o olhar atento da equipe de desenvolvimento do cliente. Uma vez que uma contribuição é considerada padrão e pronta para o repositório principal, ela pode ser enviada para uma das ramificações remotas dos repositórios de origem e integrada como de costume.

Alguns projetos têm grandes expectativas de seguir suas convenções de codificação e padrões de fluxo de trabalho Git definidos para contribuir com seu repositório. Pode ser assustador trabalhar nesse ambiente até que você tenha aprendido as coisas, então trabalhe em equipe para otimizar o tempo de ambas as partes.

NÃO crie uma cópia hospedada do repositório do cliente sem a permissão dele, você pode estar quebrando um acordo contratual, verifique de antemão que esta prática irá beneficiar o projeto com o cliente.

Gerenciamento de Liberação

As etapas entre a colaboração e o lançamento começarão em diferentes pontos do processo de desenvolvimento de cada equipe. Geralmente, você não deseja usar mais de um padrão Git de gerenciamento de versão. Você deseja ter o fluxo de trabalho mais simples possível que permitirá que sua equipe entregue de forma eficaz.

Filiais de Meio Ambiente

Seu processo de desenvolvimento de software pode ser suportado por vários ambientes para ajudar na garantia de qualidade antes de ser implantado em produção. As ramificações do ambiente imitam os estágios desse processo: cada estágio corresponde a uma ramificação e as contribuições fluem por elas em um pipeline.

As equipes que executam esses processos geralmente têm ambientes de aplicativos configurados para cada estágio do pipeline, por exemplo, “QA”, “Staging” e “Production”. Nesses casos, a infraestrutura está em vigor para dar suporte ao pessoal responsável por assinar um recurso ou contribuição para sua fatia do que significa estar pronto para produção (por exemplo, teste exploratório, controle de qualidade, teste de aceitação), antes de movê-lo para a próxima pessoa etapa. Isso dá a eles seu próprio local para implantar, testar e avaliar em relação aos seus requisitos, com um fluxo de trabalho Git para registrar sua jornada pelo túnel de aprovação.

Ter uma ramificação para cada estágio do processo é bom para equipes pequenas que podem trabalhar para um lançamento como uma unidade. Infelizmente, um pipeline como esse pode facilmente engarrafar ou se amontoar e deixar lacunas. Ele acopla seu processo Git à sua infraestrutura, o que pode causar problemas quando os recursos exigem aumento e ambos os processos precisam ser dimensionados.

NÃO use este padrão sem considerar primeiro os benefícios de longo prazo de outros padrões.

Liberar Filiais

Uma equipe que envia uma coleção de contribuições para seu aplicativo de produção como uma unidade em sprints sucessivos pode encontrar ramificações de lançamento como um ajuste favorável.

Uma coleção de commits quase “prontos para produção” recebe pequenas correções de bugs em uma ramificação de lançamento. Use uma ramificação de integração para combinar e testar os recursos antes de mover sua árvore de confirmação para uma ramificação de lançamento. Limite a responsabilidade de uma ramificação de lançamento a ser uma verificação final antes da implantação no aplicativo de produção.

As ramificações de versão diferem das ramificações de ambiente porque têm uma vida útil curta. As ramificações de lançamento são criadas apenas quando necessárias e destruídas após sua árvore de confirmação ter sido implantada em produção.

Tente evitar o acoplamento de ramificações de lançamento ao seu roteiro de desenvolvimento de software. Restringir-se a seguir um plano pré-determinado atrasa a implantação de uma versão até que todos os recursos planejados estejam prontos para produção. Não atribuir um número de versão ao roteiro antes de criar uma ramificação de lançamento pode aliviar esses tipos de atrasos, permitindo que os recursos prontos para produção sejam colocados em uma ramificação de lançamento e implantados.

Use uma convenção de nomenclatura de número de versão para o nome da ramificação de lançamento para tornar óbvio qual versão do repositório foi implantada na produção.

Implante a ramificação mestre e não a ramificação de lançamento. Para encorajar pequenas correções em ramificações de lançamento antes de mesclar com a ramificação master, use um gancho Git na ramificação master para acionar após uma mesclagem para implantar automaticamente a árvore de confirmação atualizada na produção.

Permitir que apenas uma ramificação de lançamento exista em um determinado momento garante que você evitará a sobrecarga de manter várias ramificações de lançamento sincronizadas umas com as outras.

NÃO use ramificações de lançamento com várias equipes trabalhando no mesmo repositório. Mesmo que as ramificações de lançamento sejam de curta duração, se a verificação final demorar muito, isso impedirá a outra equipe de liberar. Uma equipe apoiando-se na ramificação de lançamento de outra equipe provavelmente introduzirá bugs e causará atrasos para ambas as equipes. Observe o padrão de lançamento com carimbo de data/hora abaixo, que funciona melhor para um número e grupos maiores de colaboradores.

Lançamentos com carimbo de data/hora

Aplicativos com restrições de infraestrutura geralmente agendam suas implantações durante períodos de baixo tráfego. Se o seu projeto se deparar com filas regulares de recursos prontos para serem implantados, você pode se beneficiar do uso de versões com carimbo de data/hora.

Uma versão com carimbo de data/hora depende do processo de implantação para adicionar automaticamente uma marca de carimbo de data/hora à última confirmação na ramificação mestre que foi implantada na produção. As ramificações de tópico são usadas para colocar um recurso no processo de desenvolvimento antes de ser mesclado na ramificação mestre para aguardar a implantação.

A marca de carimbo de data/hora deve incluir um carimbo de data/hora real e um rótulo para indicar que representa uma implantação, por exemplo: deployed-201402121345 .

A inclusão de metadados de implantação, na forma da marca de carimbo de data/hora na árvore de confirmação da ramificação mestre, ajudará você a depurar regressões lançadas no aplicativo de produção. É improvável que a pessoa encarregada de procurar a causa do problema saiba muito sobre cada linha implantada no aplicativo de produção. A execução de um comando git diff nas duas últimas tags pode fornecer rapidamente um instantâneo de quais commits foram implantados pela última vez e quem são os autores de commit que podem ajudar a resolver o problema.

Ramos com carimbo de data/hora são mais do que parecem na superfície. Um mecanismo simples para registrar uma implantação de recursos enfileirados requer uma quantidade surpreendente de bons processos para conduzi-lo. O processo pode ser dimensionado e também funciona bem com uma pequena equipe de colaboradores.

Para que esse padrão de fluxo de trabalho do Git seja realmente eficaz, ele precisa que o branch master esteja sempre implantável. Isso pode significar coisas diferentes para sua equipe, mas essencialmente todos os commits devem ter passado pelo processo de desenvolvimento de seus projetos antes de terminarem no branch master.

Novos commits que chegam ao branch master vão acontecer várias vezes ao dia. Este é um problema para ramificações de tópicos que passaram pelo processo de desenvolvimento e não foram sincronizadas com a ramificação principal durante esse período. Infelizmente, tal cenário pode introduzir regressões no branch master quando os conflitos de merge são tratados incorretamente.

Se surgirem conflitos de mesclagem entre um branch de tópico e o branch master, o risco de introduzir um novo bug deve ser discutido com sua equipe antes de atualizar o branch master remoto. Se houver alguma dúvida de que uma regressão possa ocorrer, a ramificação do tópico poderá ser colocada de volta no processo de garantia de qualidade com os conflitos de mesclagem resolvidos.

Para reduzir bugs de integração, os desenvolvedores que estão trabalhando em partes relacionadas do repositório podem colaborar na melhor hora de mesclar e sincronizar suas ramificações de tópico com a ramificação mestre. As ramificações de integração também funcionam bem para resolver conflitos de ramificações de tópicos relacionados - elas devem ser submetidas ao processo de teste antes de serem mescladas na fila na ramificação principal com implantação pendente.

Projetos de desenvolvimento de software com muitos colaboradores precisam lidar com processos de colaboração e gerenciamento de lançamentos com abordagens práticas e eficientes. Os metadados adicionais na árvore de confirmação que ganhamos com o uso de versões com carimbo de data/hora são um indicador da previsão das equipes que estão se preparando para responder a problemas de produção.

Ramificação da versão

Se você tem um repositório que você não apenas executa em produção, mas que outros usam para seus próprios aplicativos hospedados, o uso de ramificações de versão pode fornecer à sua equipe a plataforma para oferecer suporte a usuários que não querem ou não podem ficar na vanguarda dos desenvolvimentos de seu aplicativo .

Um repositório usando ramificações de versão terá uma ramificação por versão secundária do aplicativo. Versões principais, secundárias e de patch são explicadas na documentação de controle de versão semântica. As ramificações de versão normalmente seguem uma convenção de nomenclatura para incluir a palavra “stable” e eliminar o número do patch da versão do aplicativo: por exemplo 2-3-stable para tornar sua finalidade e confiabilidade óbvias para os usuários finais.

As tags do Git podem ser aplicadas até o número da versão do patch do aplicativo, mas os branches de versão não são tão refinados. Um branch de versão sempre apontará para o commit mais estável para uma versão secundária suportada.

Quando surgirem patches de segurança ou a necessidade de funcionalidade de backport, reúna os commits necessários para trabalhar com versões de aplicativos mais antigas que você suporta e envie-os para seus branches de versão, respectivamente.

NÃO use ramificações de versão a menos que você suporte mais de uma versão do seu repositório.

Resumo

Quando sua equipe muda de tamanho, ou seu projeto desenvolve seus processos por meio de avaliação contínua, não deixe de avaliar também seu processo Git. Use os padrões neste tutorial como ponto de partida para ajudá-lo a seguir o caminho da justiça do fluxo de trabalho do Git.

O padrão neste guia pode ajudá-lo com alguma previsão na adaptação do seu sistema de controle de versão distribuído para trabalhar para você. Se você quiser ler sobre os fluxos de trabalho do Git, verifique o Gitflow, o Github Flow e, o mais importante, a incrível documentação do git-scm!