Develop Branch no Git — o que é, propósito e princípios de funcionamento

O que é Develop Branch no Git

Develop Branch (branch de desenvolvimento) é um branch de longa duração no Git Flow que serve como hub central para integração de código de todos os desenvolvedores. Os branches feature são mesclados nele após a conclusão do desenvolvimento e revisão de código.

O código no develop está sempre em estado pronto para criar um lançamento, embora ainda não implantado em produção. Isso significa que todas as funcionalidades no develop passaram por revisão, testes e verificações de integração, mas ainda aguardam seu ciclo de lançamento.

Ao contrário do main, onde cada versão de código é um lançamento, develop contém um fluxo contínuo de alterações. Commits no develop aparecem à medida que branches feature são mesclados, o que pode acontecer várias vezes ao dia.

De acordo com Vincent Driessen, 2010, develop é um elemento-chave de um modelo de ramificação bem-sucedido, pois separa o trabalho em rascunho das versões prontas para lançamento.

Diferenças entre develop e main branch

Entender as diferenças entre develop e main é fundamental para um fluxo de trabalho Git Flow adequado. Esses branches têm funções diferentes e requisitos de estabilidade distintos.

A separação em develop e main permite que a equipe integre continuamente novo código sem arriscar a estabilidade da versão de produção. Os desenvolvedores podem ver seu código no develop imediatamente após a aprovação do PR, mesmo antes do lançamento oficial.

Papel do develop no Git Flow

No modelo Git Flow, develop ocupa um lugar central entre os branches feature (fonte de alterações) e os branches release (preparação para lançamento). Entender essa hierarquia é a base para uma ramificação eficaz.

• Feature → Develop — cada funcionalidade concluída é mesclada no develop via Pull Request com revisão de código.
• Develop → Release — quando alterações suficientes são acumuladas para um lançamento, um branch release é criado a partir do develop.
• Release → Main + Develop — após a preparação final, o branch release é mesclado no main (lançamento) e de volta no develop (correções de bugs).
• Hotfix → Main + Develop — correções críticas são criadas a partir do main e mescladas em ambos os branches.

Essa estrutura garante que develop sempre contenha o código mais recente com todas as novas funcionalidades, enquanto main contém apenas código de produção verificado. Isso é especialmente importante para projetos móveis com longos ciclos de revisão na App Store e Google Play.

Relação do develop com outros branches do Git Flow

Develop atua como o elo central entre branches feature, release e hotfix. Entender as direções de mesclagem é essencial para prevenir conflitos e perda de commits.

Requisitos de qualidade de código no develop

A qualidade do código no develop deve ser alta, mas não absoluta. Ao contrário do main, onde cada erro significa um hotfix urgente, develop permite imperfeições menores que serão corrigidas antes do lançamento.

Requisitos mínimos para o código antes de mesclar no develop:

• Compilação — o código deve compilar sem erros. Uma compilação quebrada no develop bloqueia o trabalho de toda a equipe.
• Testes unitários — todos os testes existentes devem passar. O novo código deve ser coberto por testes em pelo menos 70%.
• Estilo de código — o código deve estar em conformidade com os padrões de formatação e nomenclatura aceitos pela equipe.
• Sem API obsoleta — o uso de métodos obsoletos não é permitido em código novo.

Verificações automatizadas no pipeline CI/CD devem ser executadas em cada push no develop. Se a compilação quebrar, o desenvolvedor responsável deve corrigir o problema em uma hora ou reverter seu commit.

Verificações CI/CD para develop

Configurar GitHub Actions para develop garante que cada PR passe por verificações automatizadas antes da mesclagem. Um pipeline típico inclui compilação, testes e linting.

# GitHub Actions — verificação do develop após mesclagem
name: Develop CI

on:
  pull_request:
    branches: [develop]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Unit tests
        run: ./gradlew testDebug
      - name: Lint
        run: ./gradlew lint
      - name: Build
        run: ./gradlew assembleDebug

Regras de mesclagem no develop

A mesclagem no develop deve seguir regras rigorosas para manter a estabilidade do branch de integração. Violar essas regras leva a conflitos, compilações quebradas e perda de tempo da equipe.

• Apenas via Pull Request — push direto no develop é proibido. Todas as alterações passam por revisão de código.
• Mínimo de uma aprovação — o PR deve ser aprovado por pelo menos um desenvolvedor não envolvido na tarefa.
• Squash merge — é recomendado combinar todos os commits do branch feature em um ao mesclar no develop para um histórico limpo.
• PR atualizado — antes da mesclagem, o PR deve estar atualizado em relação ao último commit do develop (rebase ou merge).

A regra de PR atualizado é especialmente importante. Se um branch feature foi criado há uma semana e o develop avançou 50 commits, a mesclagem direta pode causar conflitos que são melhor resolvidos no contexto do PR do que no develop.

Proteção do develop contra mesclagens incorretas

As regras de proteção de branch são configurações no nível do GitHub, GitLab ou Bitbucket que evitam alterações incorretas no develop. Elas garantem que mesmo um push acidental não quebre o branch de integração.

Regras de proteção recomendadas para develop:

• Exigir pull request — proibir push direto no develop. Todas as alterações apenas via PR.
• Exigir aprovações — mínimo de 1-2 aprovações antes de mesclar o PR.
• Exigir verificações de status — bloquear mesclagem se o pipeline CI/CD não passou.
• Exigir atualização — o branch do PR deve estar atualizado em relação ao develop antes da mesclagem.
• Restringir acesso de push — limitar direitos de push no develop apenas para desenvolvedores seniores.

Configurar a proteção do develop leva 10 minutos, mas previne semanas de inatividade relacionadas a um branch de integração quebrado. Para projetos móveis com equipes multiplataforma, isso é especialmente relevante.

Exemplos de comandos para trabalhar com develop

Vamos considerar um dia típico de um desenvolvedor: pela manhã ele atualiza o develop, cria um novo branch feature e, após concluir a tarefa, mescla as alterações de volta no develop.

# Sincronização matinal do develop
git checkout develop
git pull origin develop

# Criação de um novo branch feature a partir do develop
git checkout -b feature/add-push-notifications

# Trabalhando na funcionalidade...
git add . && git commit -m "Add FCM integration"

# Atualização do develop durante o desenvolvimento
git fetch origin develop
git rebase origin/develop

# Após aprovação do PR — atualizar develop local
git checkout develop
git pull origin develop
git branch -d feature/add-push-notifications

O comando git pull no develop realiza duas operações ao mesmo tempo: git fetch (recupera novos commits do servidor) e git merge (mescla com o branch local). Para o develop, este é o método padrão de sincronização.

Recuperação do develop após uma mesclagem quebrada

Se um código que quebrou a compilação chegar ao develop, é preciso agir rapidamente. Cada hora de inatividade do develop é trabalho bloqueado para toda a equipe de desenvolvimento.

Se um código que quebrou a compilação chegar ao develop, use git revert para criar um novo commit que desfaça as alterações problemáticas. Não use git reset no develop — ele reescreve o histórico que outros membros da equipe já possuem.

# Encontrar o commit problemático
git log --oneline develop

# Cancelar commit via revert (seguro)
git revert a1b2c3d

# Enviar correção para o develop remoto
git push origin develop

# Visualizar alterações em um commit específico
git show a1b2c3d --stat