Regras básicas e convenções de nomenclatura para a gestão de branches com várias pessoas no GitHub

Nesta série de artigos, você aprendeu desde os usos básicos do GitHub até como contribuir para o desenvolvimento colaborativo utilizando `Fork` e `Pull Request`. O desenvolvimento individual ou a contribuição para projetos de código aberto já não devem ser um problema para você.

Nesta última parte da série, vamos focar na "gestão de branches" para facilitar o desenvolvimento em equipe. Quando várias pessoas trabalham no mesmo repositório, se não houver regras, a confusão pode instalar-se rapidamente. Vamos aprender as regras básicas para a gestão de branches e as convenções de nomenclatura fáceis de entender para que todos remem na mesma direção e desenvolvam de forma eficiente, e almejar ser um mestre do desenvolvimento em equipe!

Por que são necessárias as regras de gestão de branches?

O que aconteceria se não houvesse regras para a criação de branches numa equipe?

A pessoa A criaria `feature-A`, a pessoa B `fix-B`, e a pessoa C `sato-branch`. Cada um começaria a criar branches com nomes arbitrários. Assim, ninguém saberia para que serve cada branch. Como resultado, proliferariam as branches desnecessárias, os erros de fusão (merge) seriam frequentes e o desenvolvimento mergulharia no caos.

Para prevenir este caos e avançar no desenvolvimento sem problemas, é indispensável contar com umas simples "regras de gestão de branches (estratégia de ramificação)" partilhadas pela equipe. Existem estratégias de ramificação famosas como o "Git-flow", mas para começar, é mais do que suficiente aprender os fundamentos de um "fluxo de trabalho de feature branch" mais simples.

Tipos de branches básicas e os seus papéis

No desenvolvimento em equipe simples, costumam-se utilizar principalmente dois tipos de branches. Vamos entender bem o papel de cada uma.

• Branch `main` (antiga branch `master`)

  Esta é a branch sagrada para guardar o "código do ambiente de produção que funciona sempre corretamente". É absolutamente necessário evitar editar esta branch diretamente ou que se misture código instável nela.

  【Regra】: Ninguém deve fazer commit ou push diretamente para a branch `main`. Todas as alterações devem ser fundidas através de Pull Requests a partir de feature branches, que se explicam a seguir.

• Feature Branch (Rama de funcionalidade)

  Esta é uma branch de trabalho que se cria para realizar uma tarefa específica, como o desenvolvimento de uma nova funcionalidade, a correção de um erro ou uma pequena melhoria. Às vezes também se lhe chama "rama de tópico". Ramifica-se a partir da branch `main` e, uma vez completado o trabalho, funde-se de novo na branch `main`. É uma branch de vida curta que se elimina uma vez que o trabalho terminou.

  【Regra】: Por muito pequena que seja a correção, comece sempre por criar uma nova feature branch.

Convenções de nomenclatura fáceis de entender para as branches

Para que qualquer pessoa possa entender as feature branches, é importante ter uma convenção de nomenclatura coerente. Geralmente, utiliza-se o formato " `prefixo/descricao-do-trabalho` ".

Tipos de prefixos e exemplos concretos:

• feature/: Quando se adiciona uma nova funcionalidade.
  • Exemplo: feature/add-login-page (Adicionar página de início de sessão)
• fix/: Quando se corrige um erro.
  • Exemplo: fix/correct-header-layout-bug (Corrigir erro de layout no cabeçalho)
• refactor/: Quando se melhora a qualidade do código sem alterar a funcionalidade (refatorização).
  • Exemplo: refactor/optimize-database-query (Otimizar consulta à base de dados)
• docs/: Quando se modifica a documentação (como README.md).
  • Exemplo: docs/update-installation-guide (Atualizar o guia de instalação)

Se partilhar estas regras com a sua equipe, qualquer pessoa poderá saber para que serve uma branch só de olhar para o seu nome.

Na prática! O fluxo básico do desenvolvimento em equipe

Agora, vejamos o fluxo básico do desenvolvimento em equipe baseado nestas regras, juntamente com os comandos.

Passo 1: Obtenha a versão mais recente da branch `main`

Antes de começar a trabalhar, certifique-se sempre de atualizar a sua branch `main` local para o estado mais recente do repositório remoto. Primeiro, mude para a branch `main`.

git checkout main

A seguir, traga a informação mais recente do remoto para o seu local.

git pull origin main

Passo 2: Crie uma feature branch para o seu trabalho

A partir da branch `main` atualizada, crie uma branch de trabalho para si. Desta vez, vamos criar uma branch assumindo que vamos "adicionar um formulário de contacto".

git checkout -b feature/add-contact-form

Passo 3: Realize as modificações/desenvolvimento e faça commit

Na nova branch que criou, modifique e adicione código à vontade. Quando tiver completado uma parte do trabalho com sentido, crie um commit.

git add .

git commit -m "Add basic structure of contact form"

Passo 4: Faça push para o repositório remoto

Faça push da feature branch que criou para o repositório remoto. Esta é a primeira vez que o seu trabalho será visível para os membros da sua equipe.

git push origin feature/add-contact-form

Passo 5: Crie uma Pull Request e receba feedback

Depois de ter feito push, crie uma Pull Request no GitHub dirigida à branch `main`. Peça aos membros da sua equipe que revejam o seu código e lhe deem o seu feedback. (Consulte o artigo anterior para saber como criar uma Pull Request).

Passo 6: Depois da fusão, elimine a branch desnecessária

Uma vez que a Pull Request tenha sido fundida com sucesso, a feature branch que usou para esse trabalho já não é necessária. Para manter o repositório limpo, elimine-a.

Primeiro, elimine a branch remota. Isto normalmente faz-se simplesmente premindo o botão "Delete branch" que aparece na página da Pull Request do GitHub depois da fusão.

[Imagem: O botão "Delete branch" que se mostra depois de uma fusão.]

A seguir, elimine também a branch que resta no seu local. Primeiro, voltemos à branch `main`.

git checkout main

E depois, elimine a branch local que já não necessita.

git branch -d feature/add-contact-form

Com isto, completa-se um ciclo. Quando começar um novo trabalho, repita desde o passo 1.

Conclusão: Umas regras simples salvam a equipe

O segredo para ter sucesso no desenvolvimento com várias pessoas não é aprender regras complexas, mas sim que todos sigam constantemente umas regras simples. Com apenas aplicar rigorosamente na equipe as regras básicas que apresentámos, a eficiência do desenvolvimento aumentará drasticamente e poderão evitar-se problemas desnecessários.

• Proteger sempre a branch `main`.
• Realizar todo o trabalho em feature branches.
• Ser rigoroso com as convenções de nomenclatura claras.
• Fundir com `main` sempre através de uma Pull Request.
• Eliminar com frequência as branches já fundidas.

Com esta série de introdução ao GitHub, você aprendeu desde a criação de uma conta até ao fluxo básico de desenvolvimento colaborativo. Este é um grande passo em frente como criador web. Utilizando os conhecimentos adquiridos aqui como base, encorajamo-lo a utilizar ativamente o Git e o GitHub nos seus projetos reais. Esperamos que a sua vida como desenvolvedor seja mais cómoda e criativa!