Release Branch no Git — o que é, propósito e fluxo de trabalho

O que é uma Release Branch no Git

Release Branch (branch de lançamento) é uma branch temporária no Git Flow, criada a partir de develop quando a equipe decide que o conjunto atual de funcionalidades está pronto para lançamento. Ela existe exatamente pelo tempo que a preparação final da release leva — de algumas horas a alguns dias.

O objetivo principal de uma branch release é congelar um conjunto específico de funcionalidades para o lançamento sem interromper o desenvolvimento das próximas versões. Enquanto a branch release está sendo preparada para implantação, outros desenvolvedores podem continuar mesclando branches feature em develop para a próxima release.

Nenhuma nova funcionalidade é criada na branch release — apenas correções de bugs, atualização de versão do aplicativo, localização e documentação. Após todo o trabalho ser concluído, a branch release é mesclada em main (marcada como release) e de volta em develop (para que as correções cheguem às versões futuras).

De acordo com Atlassian, 2024, as branches release são criticamente importantes para projetos com ciclos de lançamento regulares — elas garantem previsibilidade e estabilidade no processo de publicação.

Ciclo de vida da branch release

O ciclo de vida da branch release, desde a criação até a exclusão, inclui várias etapas. Compreender cada etapa ajuda a equipe a sincronizar ações e evitar erros.

1. Criação — a partir do último commit de develop, uma branch chamada release/2.5.0 é criada. develop continua aceitando branches feature para a próxima versão.
2. Preparação — na branch release, a versão do aplicativo é atualizada em build.gradle, Info.plist e outros arquivos de configuração.
3. Correção de bugs — erros críticos encontrados durante os testes finais são corrigidos. Apenas bugs, sem novas funcionalidades.
4. Testes finais — a equipe de QA realiza testes de regressão na branch release. Novos bugs são enviados para correção na mesma branch.
5. Fusão em main — a branch release é mesclada em main com a flag --no-ff. A tag de release é criada: v2.5.0.
6. Fusão em develop — a branch release é mesclada de volta em develop para que as correções da release cheguem ao desenvolvimento atual.
7. Exclusão — a branch release é excluída local e remotamente, pois sua tarefa está concluída.

O passo 6 — a mesclagem reversa em develop — é frequentemente esquecido, mas é criticamente importante. Sem ele, as correções feitas na branch release não chegarão a develop, e os mesmos erros podem reaparecer na próxima release.

Durações típicas das etapas da branch release

O tempo de vida da branch release depende da complexidade da release e da qualidade do código em develop. Em média, a preparação leva de 2 a 5 dias úteis para um aplicativo móvel de médio porte.

O que é feito na branch release

Na branch release, um conjunto estritamente limitado de tarefas é executado. Qualquer desvio desta lista viola o modelo Git Flow e cria riscos para a estabilidade da release.

A regra de proibição de novas funcionalidades é a mais importante na branch release. Se uma funcionalidade não ficou pronta para a release, ela aguarda o próximo ciclo. Tentar introduzir uma funcionalidade incompleta na branch release é a principal causa de atrasos e bugs em produção.

Atualização de versão em um projeto móvel

Na branch release, o número da versão do aplicativo é obrigatoriamente atualizado. Para Android, são os campos versionCode e versionName em build.gradle; para iOS — CFBundleShortVersionString em Info.plist.

// build.gradle (nível do app) — atualização de versão na branch release
android {
    defaultConfig {
        versionCode 42
        versionName "2.5.0"
    }
}

// Para iOS — atualização de Info.plist
// CFBundleShortVersionString = 2.5.0
// CFBundleVersion = 42

Diferenças entre release e hotfix

Desenvolvedores iniciantes frequentemente confundem as branches release e hotfix, embora seus propósitos sejam fundamentalmente diferentes. Escolher o tipo errado de branch pode atrasar uma correção crítica ou interromper o processo de release.

• Origem — release é criada a partir de develop, hotfix a partir de main. Esta é a principal diferença que determina todo o resto.
• Urgência — release é planejada: a equipe decide quando iniciar a preparação. Hotfix é urgente: um problema em produção requer correção imediata.
• Conteúdo — release pode incluir várias correções e atualização de versão. Hotfix contém apenas uma correção crítica.
• Fusão — release é mesclada em main e develop. Hotfix também é mesclada em main e develop, mas com prioridade.
• Tempo de vida — release vive de 1 a 7 dias. Hotfix vive de 30 minutos a 1 dia.

Se um bug for encontrado durante a preparação da release (na branch release) — é uma correção normal. Se um bug for encontrado em produção (em main) — é um hotfix, e é criado a partir de main, mesmo que a branch release já exista.

Regras de nomenclatura das branches release

Um padrão unificado de nomenclatura das branches release simplifica a navegação no repositório e permite que sistemas CI/CD detectem automaticamente que uma branch pertence ao processo de release.

• release/X.Y.Z — formato padrão do Git Flow, onde X.Y.Z é a versão da release. Exemplo: release/2.5.0.
• release/nome — formato alternativo com um nome codificado da release. Exemplo: release/merlin.
• release/data — formato com a data da release. Raramente usado, pois a versão é mais importante que a data. Exemplo: release/2024-12-01.

O formato release/X.Y.Z é o preferido, pois vincula explicitamente a branch ao número de versão que será atribuído à release. Isso simplifica a busca e o processamento automático por scripts CI/CD.

Estratégia de mesclagem reversa em develop

A mesclagem reversa (merge back) da branch release em develop é uma das operações mais importantes e, ao mesmo tempo, uma das mais frequentemente ignoradas. Sem ela, todas as correções feitas na branch release permanecem apenas na versão de lançamento e não chegam ao próximo ciclo de release.

O processo de mesclagem reversa é realizado após a branch release já ter sido mesclada em main. Primeiro, release é mesclada em develop, depois é excluída. Isso garante que develop contenha todas as correções feitas durante a preparação da release.

Após a mesclagem reversa, podem ocorrer conflitos — especialmente se novas branches feature que modificaram os mesmos arquivos já apareceram em develop. O desenvolvedor responsável pela release resolve esses conflitos e envia develop para o servidor.

Algumas equipes usam rebase em vez de merge para a mesclagem reversa, para manter um histórico linear. No entanto, merge é mais seguro para develop, pois não reescreve o histórico de commits que outros desenvolvedores já podem estar usando.

Exemplos de comandos para trabalhar com release

Vamos examinar o ciclo completo de trabalho com uma branch release: desde a criação até a exclusão após uma release bem-sucedida de um aplicativo móvel versão 2.5.0.

# 1. Criar branch release a partir de develop
git checkout develop
git pull origin develop
git checkout -b release/2.5.0

# 2. Atualizar versão e correções
git add build.gradle
git commit -m "Bump version to 2.5.0"

# 3. Corrigir bugs (apenas bugfixes)
git add src/fix/
git commit -m "Fix crash on payment screen"

# 4. Enviar branch release para o servidor
git push origin release/2.5.0

# 5. Mesclar release em main
git checkout main
git pull origin main
git merge --no-ff release/2.5.0
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin main --tags

# 6. Mesclagem reversa em develop
git checkout develop
git merge --no-ff release/2.5.0
git push origin develop

# 7. Excluir branch release
git branch -d release/2.5.0
git push origin --delete release/2.5.0

Os comandos 5 e 6 — a fusão dupla — são criticamente importantes. Primeiro, main recebe o código de release e a tag, depois develop é sincronizada com as correções de release. Se o passo 6 for ignorado, as correções da release não chegarão ao próximo ciclo de desenvolvimento.

Automatização do processo de release

Para projetos móveis com releases regulares, o processo de criar uma branch release e atualizar a versão pode ser automatizado por meio de scripts CI/CD. O GitHub Actions permite criar um workflow que, ao clicar em um botão, cria uma branch release com atualização automática de versão.

Para projetos móveis com releases regulares, o processo de criar uma branch release e atualizar a versão pode ser automatizado por meio de scripts CI/CD. O GitHub Actions permite criar um workflow que, ao clicar em um botão, cria uma branch release com atualização automática de versão.

# GitHub Actions — automatização da criação de branch release
name: Create Release Branch

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Release version (e.g. 2.5.0)'
        required: true

jobs:
  create-release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create release branch
        run: |
          git checkout develop
          git checkout -b release/${{ inputs.version }}
          git push origin release/${{ inputs.version }}