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 efetuar push das alterações adicionais para corrigir o erro. Suas alterações não serão atualizadas no branch padrão até que você mescle seu branch.

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 confirmação é controlada por uma ID exclusiva, carimbo de data/hora e colaborador, independentemente de ser feita por meio da linha de comando ou diretamente na interface da 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 imagem 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.
• Encenado: O arquivo foi modificado e as alterações foram adicionadas à área de preparo (também conhecida como índice). Essas mudanças estão prontas para serem confirmadas.
• Empenhado: 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 solicitações de pull?

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 dá suporte a Solicitações de Pull de Rascunho, que permitem abrir uma solicitação de pull que ainda não está pronta para revisã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, confirmações e solicitações de pull funcionam, vamos percorrer como eles se reúnem 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, solicitações de pull 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 no branch. Se o fluxo de trabalho der suporte a ele, você poderá implantar alterações desse branch para testá-las antes de mesclar.
3. Agora, abra uma solicitação pull para convidar comentários 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 estiver confiante em suas alterações, obtenha aprovação e mescle a solicitação de pull no branch principal.
6. Depois disso, exclua o branch para manter seu repositório limpo e evite usar branches desatualizados.

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.

Tipos de branch de fluxo do Git

O fluxo do Git usa vários branches temporários e de longa duração:

• mestre: sempre reflete o código pronto para produção.
• desenvolver: contém o trabalho de desenvolvimento mais recente para a próxima versão.
• feature/*: usado para criar novos recursos; ramificado e develop 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 branches de recursos a partir da criação de develop novas funcionalidades.
2. Quando é hora de uma versão, um branch de lançamento é criado a partir de develop. Isso isola o trabalho de preparação da versão para que o desenvolvimento possa continuar ininterrupto.
3. Correções de bug podem ser adicionadas ao branch de lançamento, mas os principais recursos devem aguardar uma versão futura.
4. Quando estiver pronto, o branch de lançamento será mesclado master e marcado com um número de versão. O GitHub pode usar essas marcas para ajudá-lo a gerar notas de versão.
5. O mesmo branch de versão deve ser mesclado novamente develop para mantê-lo em sincronia.
6. Se surgir um bug de produção crítico, um branch de hotfix 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 versões agendadas ou com versão
• Útil se você mantiver várias versões de produção (por exemplo, branches 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 GitHub Flow devido ao gerenciamento de branch 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.