Componentes do fluxo do GitHub

  • 8 minutos

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

  • Ramos
  • Consolidações
  • Pedidos Pull
  • O Fluxo do GitHub
  • Fluxo Git

Componentes do fluxo do GitHub

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 rastrear 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 ramificações, confirmações, solicitações pull e interfaces visuais para colaboração. Vamos começar observando como esses conceitos funcionam no GitHub.

O que são sucursais

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

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

Sua filial é 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 atualizadas na ramificação padrão até que você mescle sua ramificação.

Nota

Como alternativa, você pode criar uma nova filial e fazer check-out usando o git em um terminal. O comando seria git checkout -b newBranchName

O que são compromissos

Na unidade anterior, você adicionou um novo arquivo ao repositório enviando uma confirmação. Vamos rever brevemente o que são compromissos.

Uma confirmação é uma alteração em um ou mais ficheiros num ramo. Cada confirmação é rastreada por um ID exclusivo, carimbo de data/hora e contribuidor, independentemente de ser feita através da linha de comando ou diretamente na interface web do GitHub. As confirmações fornecem uma trilha de auditoria clara para qualquer pessoa que revise o histórico de um arquivo ou item vinculado, como um problema ou solicitação pull.

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

git commit -m "Add a helpful commit message"

Uma captura de ecrã de uma lista de commits do GitHub para uma ramificação principal.

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 Untracked e Tracked.

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

Acompanhado: Um arquivo rastreado é aquele que o Git está monitorando ativamente. 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 a última confirmação, mas essas alterações ainda não foram preparadas para a próxima confirmação.
  • Encenado: O arquivo foi modificado e as alterações foram adicionadas à área de preparo (também conhecida como índice). Estas alterações estão prontas a ser concretizadas.
  • Cometido: O ficheiro está na base 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 pedidos Pull?

Uma pedido de pull é o mecanismo usado para sinalizar que as confirmações de uma ramificação estão prontas para serem integradas em outra ramificação.

O membro da equipe que envia a solicitação pull pede a um ou mais revisores que verifiquem o código e aprovem a mesclagem. Estes revisores têm a oportunidade de comentar as alterações, adicionar as suas próprias ou utilizar o pedido Pull para desenvolver a discussão.

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

Depois que as alterações forem aprovadas (se necessário), a ramificação de origem da solicitação pull (a ramificação de comparação) será mesclada na ramificação base.

Uma captura de ecrã de um pull request e um comentário dentro do pull request.

Agora que você já viu como as ramificações, confirmações e solicitações pull funcionam, vamos mostrar como elas se unem no GitHub Flow.

O fluxo do GitHub

Captura de tela mostrando uma representação visual do fluxo do GitHub em um formato linear que inclui uma nova ramificação, confirmações, solicitação pull e mesclagem das alterações de volta à principal nessa ordem.

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 a sua equipe usando ramificações, pull requests e merges.

Nota

O fluxo do GitHub é um dos vários fluxos de trabalho populares. Outros incluem fluxo Git e desenvolvimento baseado em tronco.

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

  1. Comece criando uma ramificação para que suas alterações, recursos ou correções não afetem a ramificação principal.
  2. Em seguida, faça suas atualizações na filial. Se o seu fluxo de trabalho oferecer suporte a isso, você poderá implantar alterações dessa ramificação para testá-las antes da mesclagem.
  3. Agora, abra um pull request para convidar feedback e começar uma revisão.
  4. Em seguida, revise os comentários e faça as atualizações necessárias com base no feedback da sua equipe.
  5. Finalmente, quando estiver confiante nas suas alterações, obtenha aprovação e mescle o pull request na ramificação principal.
  6. Depois disso, exclua a ramificação para manter o repositório limpo e evite o uso de ramificações desatualizadas.

Fluxo Git

Diagrama ilustrando o fluxo de trabalho do Git com linhas paralelas para ramificações de funcionalidades, develop, ramificações de lançamento, hotfixes e master. Ele mostra como as funcionalidades são mescladas em develop, as ramificações de lançamento são criadas a partir de develop, os hotfixes são ramificados de master e todas as alterações são eventualmente mescladas de volta em master e develop com versões marcadas.

Enquanto o GitHub Flow é um fluxo de trabalho leve projetado para entrega contínua, o Git flow é um modelo de ramificação mais estruturado, frequentemente usado em ambientes orientados por liberação. O fluxo do Git existe há mais tempo do que o fluxo do GitHub, e você ainda pode ver o termo master usado em vez de main como a ramificação padrão.

Tipos de ramificação Git Flow

O Git flow utiliza várias ramificações de longa duração e temporárias.

  • master: Sempre reflete o código pronto para produção.
  • develop: contém o trabalho de desenvolvimento mais recente para a próxima versão.
  • feature/*: Usado para criar novas funcionalidades; ramificado de develop e integrado de volta quando concluído.
  • release/*: Prepara uma nova versão de produção de develop; permite testes finais e pequenas correções de bugs.
  • hotfix/*: Usado para corrigir rapidamente problemas de produção; ramificado a partir de master.

Como funciona o processo de fluxo Git

  1. Os desenvolvedores criam ramificações de develop recursos para criar novas funcionalidades.
  2. Quando chega a hora de um release, um ramo de release é criado a partir de develop. Isso isola o trabalho de preparação da liberação para que o desenvolvimento possa continuar ininterruptamente.
  3. Correções de bugs podem ser adicionadas ao ramo de lançamento, mas os principais recursos devem esperar por uma versão posterior.
  4. Uma vez pronta, a ramificação de lançamento é fundida em master e marcada com um número de versão associado. 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 em develop para mantê-la sincronizada.
  6. Se surgir um bug crítico de produção, uma ramificação de correção urgente será criada a partir de master. Uma vez corrigido, é mesclado em master e develop.

Quando usar o fluxo Git

  • Mais adequado para projetos com versões programadas ou versionadas
  • Ú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 empresariais ou regulamentados)
  • Considerado mais "pesado" do que o GitHub Flow devido ao gerenciamento adicional de filiais

Nota

O fluxo Git pressupõe confirmações de mesclagem para integrar ramificações. O uso de mesclagens de rebase ou squash pode interferir na estrutura da filial e no rastreamento do histórico.

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 lançamento, o fluxo Git pode ser uma opção melhor.

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

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