Componentes do fluxo do GitHub

Nesta unidade, estamos revisando os seguintes componentes do fluxo do GitHub:

• Ramificações
• Confirmações
• Solicitações de pull
• O fluxo do GitHub
• Fluxo do Git

Componentes do GitHub Flow

Antes de entrarmos em fluxos de trabalho específicos do GitHub, é útil entender que o GitHub Flow se baseia diretamente nos conceitos fundamentais do Git.

O Git fornece ferramentas para controlar e gerenciar alterações em seu código ao longo do tempo. O GitHub se baseia nisso facilitando o uso dessas ferramentas com recursos como branches, confirmações, solicitações de pull e interfaces visuais para colaboração. Vamos começar analisando como esses conceitos funcionam no GitHub.

O que são branches?

Na última seção, criamos um novo arquivo e um novo branch em seu repositório.

Branches são uma parte essencial da experiência do GitHub. Eles permitem que você faça alterações sem afetar o branch padrão.

Seu branch é um lugar seguro para experimentar novos recursos ou correções. Se você cometer um erro, poderá reverter suas alterações ou enviar mais alterações para corrigir o erro. Suas alterações não serão refletidas no ramo padrão até que você mescle seu ramo.

O que são commits

Na unidade anterior, você adicionou um novo arquivo ao repositório enviando um commit. Vamos revisar brevemente o que são commits.

Uma confirmação é uma alteração em um ou mais arquivos de um branch. Cada commit é controlado por um ID único, marca temporal e colaborador, independentemente de ser feito por meio da linha de comando ou diretamente na interface web do GitHub. Os commits fornecem uma trilha de auditoria clara para qualquer pessoa que revise o histórico de um arquivo ou item vinculado, como um problema ou uma solicitação de pull.

Você pode criar uma confirmação usando o Git em seu terminal com:

git commit -m "Add a helpful commit message"

Dentro de um repositório git, um arquivo pode existir em vários estados válidos à medida que passa pelo processo de controle de versão. Os estados primários de um arquivo em um repositório Git são Não rastreado e Rastreado.

Não rastreado: Um estado inicial de um arquivo quando ele ainda não faz parte do repositório Git. O Git desconhece a existência dele.

Rastreado: Um arquivo rastreado é aquele que o Git está monitorando ativamente. A entidade pode estar em um dos seguintes subestados:

• Não modificado: O arquivo é rastreado, mas não foi modificado desde a última confirmação.
• Modificado: O arquivo foi alterado desde o último commit, mas essas alterações ainda não foram preparadas para o próximo commit.
• Preparado: o arquivo foi modificado, e as mudanças foram adicionadas à área de preparo (também conhecida como índice). Essas mudanças estão prontas para serem confirmadas.
• Comitado: O arquivo está no banco de dados do repositório. Ele representa a versão confirmada mais recente do arquivo.

Esses estados ajudam sua equipe a entender o status de cada arquivo e onde ele está no processo de controle de versão.

O que são pull requests?

Uma solicitação de pull é o mecanismo usado para sinalizar que as confirmações de um branch estão prontas para serem mescladas em outro branch.

O membro da equipe que envia a solicitação pull pede a um ou mais revisores para verificar o código e aprovar a mesclagem. Esses revisores têm a oportunidade de comentar sobre as alterações, adicionar as próprias ou usar a solicitação de pull para uma discussão adicional.

O GitHub também oferece suporte a Solicitações de pull de rascunho, que permitem abrir uma solicitação de pull que ainda não está pronta para avaliação.

Depois que as alterações forem aprovadas (se necessário), o branch de origem da solicitação de pull (o branch de comparação) será mesclado ao branch base.

Agora que você viu como branches, commits e pull requests funcionam, vamos ver como eles se integram no GitHub Flow.

O fluxo do GitHub

O fluxo do GitHub é um fluxo de trabalho simples que ajuda você a fazer e compartilhar alterações com segurança. É ótimo para experimentar ideias e colaborar com sua equipe usando branches, pull requests e mesclagens.

Agora que sabemos o básico do GitHub, podemos percorrer o fluxo do GitHub e os respectivos componentes.

1. Comece criando um branch para que suas alterações, recursos ou correções não afetem o branch principal.
2. Em seguida, faça suas atualizações na ramificação. Se o fluxo de trabalho o suportar, você poderá implantar alterações dessa ramificação para testá-las antes de mesclar.
3. Agora, abra um pull request para solicitar feedback e começar uma revisão.
4. Em seguida, examine os comentários e faça as atualizações necessárias com base nos comentários da sua equipe.
5. Por fim, quando terminar suas mudanças, receba aprovação e mescle o a solicitação de pull na ramificação principal.
6. Depois disso, exclua a ramificação para manter seu repositório limpo e evitar o uso de ramificações desatualizadas.

Fluxo do Git

Embora o GitHub Flow seja um fluxo de trabalho leve projetado para entrega contínua, o fluxo do Git é um modelo de ramificação mais estruturado geralmente usado em ambientes controlados por lançamento. O fluxo do Git existe há mais tempo do que o GitHub Flow, e você ainda pode ver o termo master usado em vez de main como o branch padrão.

Imagem de Vincent Driessen, de 'Um modelo de ramificação Git bem sucedido'

Fluxo Git: tipos de ramificação

O fluxo do Git usa várias ramificações temporárias e de longa duração:

• master: sempre reflete o código pronto para ambiente de produção.
• desenvolvimento: Contém o trabalho de desenvolvimento mais recente para a próxima versão.
• feature/*: usado para criar novos recursos; ramificado a partir de develop e depois mesclado novamente quando concluído.
• release/*: prepara uma nova versão de produção de develop, permite testes finais e pequenas correções de bug.
• hotfix/*: usado para corrigir rapidamente problemas de produção; ramificado de master.

Como funciona o processo de fluxo do Git

1. Os desenvolvedores criam feature branches a partir de develop para construir novas funcionalidades.
2. Quando é hora de um lançamento, uma ramificação de lançamento é criada a partir de develop. Isso isola o trabalho de preparação do lançamento para que o desenvolvimento possa continuar sem interrupções.
3. As correções de bugs podem ser adicionadas à ramificação de lançamento, mas os principais recursos deverão aguardar uma versão futura.
4. Quando estiver pronta, a ramificação de lançamento é mesclada em master e marcada com um número de versão. O GitHub pode usar essas tags para ajudá-lo a gerar notas de versão.
5. A mesma ramificação de lançamento deve ser mesclada novamente ao develop para manter a sincronia.
6. Se surgir um erro crítico de produção, um hotfix branch será criado a partir de master. Uma vez corrigido, ele é mesclado em ambos master e develop.

Quando usar o fluxo do Git

• Mais adequado para projetos com lançamentos agendados ou versionados
• Útil se você mantiver várias versões de produção (por exemplo, ramificações de suporte de longo prazo)
• Ideal para ciclos de desenvolvimento mais lentos e estruturados (por exemplo, ambientes corporativos ou regulamentados)
• Considerado mais "pesado" do que o fluxo do GitHubdevido ao gerenciamento de ramificação adicional

Para muitas equipes que usam o GitHub, o GitHub Flow é mais simples e rápido. Mas se sua equipe valoriza a previsibilidade e precisa de mais planejamento de versão, o fluxo do Git pode ser um ajuste melhor.

Parabéns! Você acabou de percorrer o GitHub Flow completo e explorou como o fluxo do Git oferece uma alternativa estruturada para projetos controlados por lançamento.

Vamos para a próxima seção, onde abordaremos as diferenças entre problemas e discussões.