Main e Master Branch no Git: o que é e por que você precisa de uma branch principal

O que é Main / Master Branch no Git

Main Branch (ou Master — dependendo das configurações do repositório) é a branch padrão criada ao inicializar qualquer repositório Git. É a branch principal do projeto e contém código pronto para implantação em produção.

Ao contrário de develop, onde o trabalho diário com novas funcionalidades está a todo vapor, main é a vitrine do projeto. Cada versão do código em main passou por um ciclo completo: desenvolvimento em uma branch feature, integração em develop, preparação do lançamento em uma branch release e testes finais. Só depois disso as alterações chegam a main.

Princípio chave: main deve ser sempre estável. Se um erro for encontrado em main, significa que um hotfix urgente precisa ser lançado fora de hora. Portanto, em projetos profissionais, main é protegida contra alterações acidentais por regras de proteção de branch.

De acordo com Git Book, main não é uma branch especial com propriedades únicas, mas uma referência normal a um commit que é convencionalmente considerada a principal. O Git não faz distinção entre main e qualquer outra branch no nível do sistema.

Transição de master para main

Historicamente, a branch padrão no Git era chamada master. Em junho de 2020, o movimento Black Lives Matter chamou a atenção para os termos master e slave na indústria de TI. O GitHub anunciou a transição para o termo main para a branch padrão.

Desde outubro de 2020, todos os novos repositórios no GitHub são criados com a branch main. GitLab e Bitbucket também implementaram suporte para main como nome padrão. O Git 2.28 (julho de 2020) adicionou a opção init.defaultBranch para configurar o nome da branch padrão.

Tecnicamente, renomear uma branch existente de master para main é uma operação simples. O principal desafio é atualizar todas as referências nas configurações de CI/CD, documentação e repositórios locais dos desenvolvedores.

Para renomear uma branch em um repositório existente, execute:

# Renomear localmente master para main
git branch -m master main

# Atualizar repositório remoto
git push -u origin main

# Excluir master antigo no servidor
git push origin --delete master

# Atualizar HEAD no servidor
# (via interface web do GitHub: Settings → Branches → Default branch)

Papel do main no Git Flow e GitHub Flow

Git Flow e GitHub Flow definem o papel da branch main de forma diferente. A escolha do modelo depende do tamanho da equipe, frequência de lançamentos e requisitos de estabilidade do código.

Para desenvolvimento mobile, Git Flow é o padrão, já que publicar um aplicativo na App Store e Google Play tem ciclos de lançamento fixos. GitHub Flow é mais adequado para projetos web que podem ser implantados várias vezes ao dia.

GitHub Flow — abordagem simplificada

No GitHub Flow, não há branch develop. Todas as branches feature são criadas diretamente de main e, ao finalizar, são mescladas de volta via Pull Request. Cada mesclagem em main aciona automaticamente a implantação em produção. Este modelo requer um alto nível de automação de testes e disciplina da equipe.

No GitHub Flow, não há branch develop. Todas as branches feature são criadas diretamente de main e, ao finalizar, são mescladas de volta via Pull Request. Cada mesclagem em main aciona automaticamente a implantação em produção. Este modelo requer um alto nível de automação de testes e disciplina da equipe.

Proteção da branch main

Proteção de branch para main é uma configuração obrigatória em qualquer projeto comercial. Sem ela, um push acidental pode enviar código incompleto para produção ou quebrar um aplicativo em funcionamento para todos os usuários.

• Require pull request — push direto para main é proibido. Todas as alterações via PR com revisão.
• Require approvals — mínimo 2 aprovações para mesclar em main (caso um revisor perca algo).
• Require status checks — todas as verificações de CI/CD devem ser bem-sucedidas antes de mesclar.
• Require up-to-date — o PR deve ser baseado no último commit de main.
• Include administrators — a proteção se aplica até mesmo aos proprietários do repositório.
• Require signed commits — todos os commits em main devem ser assinados com chave GPG.

Configurar todas as seis regras é o padrão para projetos mobile com audiência de 10.000+ usuários. Para projetos pequenos, as três primeiras regras são suficientes.

Comparação de níveis de proteção para diferentes tipos de projeto

O nível de proteção do main depende da escala do projeto. Uma startup pode se virar com proteção mínima, enquanto um aplicativo empresarial requer restrições máximas.

Lançamentos e tags em main

Tagging é a prática de criar referências nomeadas para commits específicos em main. Cada tag corresponde a uma versão do aplicativo lançada em produção. Isso permite alternar rapidamente para qualquer versão anterior para depuração ou correção.

O padrão de nomenclatura de tags no desenvolvimento mobile é SemVer (Versionamento Semântico): v1.2.3, onde o primeiro número é a versão principal (mudanças significativas), o segundo é a versão secundária (novas funcionalidades) e o terceiro é o patch (correções).

Uma tag é criada após a mesclagem da branch release em main. Este commit é então compilado no CI/CD, assinado e enviado para a loja de aplicativos. Se um erro for encontrado na tag, uma branch hotfix é criada a partir dessa tag.

# Criar tag de lançamento anotada
git tag -a v2.4.1 -m "Release version 2.4.1"

# Enviar tag para o servidor
git push origin v2.4.1

# Ver todas as tags no repositório
git tag -l "v2.*"

# Criar branch hotfix a partir de uma tag específica
git checkout -b hotfix/crash-fix v2.4.1

Hierarquia de branches do Git Flow

Entender a hierarquia de branches no Git Flow é a base para organizar adequadamente o desenvolvimento colaborativo. Cada tipo de branch tem sua própria fonte, propósito e regras de mesclagem.

• Main (Nível 1) — a branch raiz, contém apenas versões de lançamento. Criada ao inicializar um repositório.
• Develop (Nível 2) — criada de main no início do projeto. Contém código de integração de todas as funcionalidades.
• Feature (Nível 3) — criada de develop. Desenvolvimento isolado de funcionalidades individuais.
• Release (Nível 2) — criada de develop. Preparação de um lançamento específico para publicação.
• Hotfix (Nível 2) — criada de main. Correções urgentes de erros críticos de produção.

Regra importante: feature nunca é mesclada diretamente em main. feature → develop → release → main é a cadeia de mesclagem correta. Violar esta regra anula o propósito de todo o modelo Git Flow.

Exemplos de comandos para trabalhar com main

Considere um cenário: a equipe concluiu a preparação do lançamento v2.5.0. A branch release foi revisada e está pronta para ser mesclada em main. Após a mesclagem, uma tag é criada e o lançamento é publicado.

# Alternar para main e atualizar
git checkout main
git pull origin main

# Mesclar branch release verificada
git merge --no-ff release/2.5.0

# Criar tag de lançamento
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# Enviar main e tag para o servidor
git push origin main --tags

A flag --no-ff (sem avanço rápido) garante a criação de um commit de mesclagem, mesmo que a mesclagem pudesse ser feita simplesmente movendo o ponteiro. Isso preserva a informação de que as alterações vieram de uma branch release, facilitando a análise do histórico.

Trabalhando com hotfix através de main

Se um erro crítico for descoberto em produção, o processo difere de um lançamento normal. Um hotfix é criado a partir de main e, após a correção, é mesclado tanto em main quanto em develop.

Se um erro crítico for descoberto em produção, o processo difere de um lançamento normal. Um hotfix é criado a partir de main e, após a correção, é mesclado tanto em main quanto em develop.

# Criar branch hotfix a partir de main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# Corrigir e fazer commit
git add src/fix/
git commit -m "Fix crash on login screen"

# Mesclar hotfix de volta em main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# Mesclar hotfix também em develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# Excluir branch hotfix
git branch -d hotfix/2.5.1-crash-fix