Por que branches: isolando trabalho sem mexer no main

O problema de uma única linha de histórico

Todo commit dos últimos três cursos caiu no mesmo branch, main, um atrás do outro. Isso funciona bem para um exercício de aprendizado sozinho. Isso quebra no momento em que o trabalho real parece assim: você está no meio de uma refatoração arriscada, chega um relato de bug crítico, e o main precisa de uma correção de emergência: agora, sem sua refatoração pela metade em lugar nenhum perto.

Um branch é a resposta do Git: uma linha independente de commits, começando de qualquer ponto do histórico, que o main nunca vê até você deliberadamente trazer de volta.

Um branch não é uma cópia

Este é o mal-entendido mais comum, que vale corrigir imediatamente: criar um branch não duplica os arquivos do seu projeto em lugar nenhum. Um branch é um ponteiro minúsculo e leve: só um nome preso ao hash de um commit específico, nada mais.

                        c1 ─▶ c2 ─▶ c3   (main)
                                      ↑
                                    HEAD

Três commits, um nome de branch (main) apontando para o mais recente, e o HEAD (sua posição atual) apontando para o main. Criar um branch novo só adiciona um segundo nome apontando para esse mesmo lugar:

                        c1 ─▶ c2 ─▶ c3   (main, feature-x)
                                      ↑
                                    HEAD -> main

Nada foi copiado. Dois rótulos, um commit. No momento em que você commita de novo estando no feature-x, os dois nomes finalmente divergem:

                        c1 ─▶ c2 ─▶ c3   (main)
                                      \
                                       c4   (feature-x)
                                       ↑
                                     HEAD -> feature-x

O main continua apontando para o c3, completamente intocado: o isolamento que o cenário da correção de emergência precisava.

Por que isso muda como você trabalha

A convenção em quase toda equipe Rails profissional: o main está sempre pronto para deploy. Toda feature, toda correção, todo experimento acontece no próprio branch e só se junta ao main depois de revisado e pronto.

O que "checkout" significa, e por que está no título deste curso

Mover sua working tree para bater com um branch diferente (ou um commit qualquer) se chama dar checkout naquele branch. O comando que faz isso tem uma história um pouco emaranhada: vale uma nota curta agora, uma aula completa mais adiante: o git checkout historicamente fazia dois trabalhos sem relação (trocar de branch, e descartar mudanças de arquivo: o comando que o git restore do seu curso de Git Workflow substituiu para esse segundo trabalho). Este curso foca no primeiro trabalho: se mover entre branches.

Como este curso está organizado

1. Criando e trocando de branches
2. Inspecionando e comparando o que tem em cada um
3. Renomeando e apagando branches com segurança
4. HEAD desanexado: dando checkout num commit cru em vez de um branch
5. Branches ao lado dos remotos do curso anterior
6. Construindo uma feature de verdade inteiramente no próprio branch

Pontos-chave

• Um branch é um ponteiro leve e móvel para um commit, não uma cópia do seu projeto.
• O HEAD rastreia sua posição atual, geralmente apontando para um nome de branch, que por sua vez aponta para um commit.
• Dois branches compartilham histórico até um deles ganhar um commit novo: é aí que eles divergem.
• A convenção profissional: o main fica sempre pronto para deploy; todo trabalho acontece em branches separados primeiro.