Como atualizar sua branch no git de forma apropriada
Em fluxos de desenvolvimento de software com mais de uma pessoa desenvolvedora, é bastante comum precisarmos atualizar nosso branch de feature com as mudanças mais recentes no branch principal (main).
Nesse artigo vou mostrar uma forma mais apropriada de fazer esse processo, visando sempre termos um histórico limpo de commits no git, o que vai nos trazer muitos benefícios no longo prazo ✨
Mas qual o problema?
Quando fazemos o seguinte:
- git checkout my-branch
- git pull origin main
Por baixo dos panos o git irá executar um `git merge` , o que por sua vez cria um novo commit de merge.
Como estamos trabalhando em uma funcionalidade nova, em breve o nosso branch será integrado (merge) no branch main, e isso fará com que nosso histórico fique muito mais poluído, com commits de merge desnecessários.
Isso pode parecer uma preocupação desnecessária a princípio, mas uma linha do tempo limpa no git facilita muito nossa vida em diversos aspectos:
- Facilidade de interação no projeto: Novas pessoas podem entender mais claramente o histórico de commits e mudanças do projeto
- Histórico claro e limpo: Podemos olhar anos de histórico do projeto de forma limpa e compreensível
- Identificação de problemas: Podemos também identificar quando determinadas mudanças aconteceram com mais facilidade, já que não temos commits desnecessários poluindo o histórico.
Atualizando um branch local com as alterações da main
Agora que entendemos os problemas causados pelo git merge em branches de feature, vamos entender como evitar os problemas.
Evite fazer o seguinte:
git checkout my-branch
git pull origin main #← this creates a merge commit that we don’t wantO comando git pull irá criar um novo merge commit. Se tratando de um branch de desenvolvimento que posteriormente será integrado à branch principal, não é interessante termos esses commits poluindo o histórico.
Este é um caminho preferível:
git checkout my-branch
git pull origin main --rebase # ← avoids duplicated merge commitsA diferença é pequena, mas ao adicionar ` — rebase` no git pull, não iremos criar um merge commit
O que o `git rebase` faz na prática é “recortar” todos os commits da nossa branch, fazer uma atualização com a branch main, e só então “colar” os commits novamente. Essa operação basicamente reescreve o nosso histórico de commits da branch de feature, sem a necessidade de um merge commit extra.
Regrinhas de ouro
Temos duas diferenças principais nos comandos mencionados:
- git merge (git pull origin main): Esse comando deixa explícito o momento exato em que o merge aconteceu. Isso é ideal para branches públicas/protegidas, como a `main` ou `production`
- git rebase (git pull origin main — rebase): Esse comando faz um merge implícito, ou seja, “esconde” o momento exato do merge. Isso é ideal para branches que serão integradas na branch principal, pois não deixará merge commits descenessários.
Ao fazer o rebase, também é necessário fazer um force push `git push origin my-branch — force`, pois como mencionei, nosso histórico de commits foi totalmente reescrito. E é sempre bom lembrar, não é recomendado fazer force push em branches protegidas (main, production) pois isso pode gerar todo tipo de efeito colateral indesejado.
Conclusão
Uma boa política de versionamento é a base para muitas operações no fluxo de desenvolvimento, tais como compreensão das mudanças de código, automações, devops e também a possibilidade de ter várias pessoas trabalhando na mesma base de código.
Com isso, ao termos commits relevantes e bem feitos no histórico, temos uma base sólida para todas as operações que vem a seguir, por isso precisamos caprichar nessa etapa.
Dito isso, vale lembrar também que não é necessariamente errado fazer o merge nos branches de feature. Isso vai depender muito dos objetivos e acordos do time, mas essencialmente podemos dizer que o git rebase oferece algumas vantagens que o merge não oferece, conforme explicado no artigo.
Qualquer dúvida ou sugestão fiquem a vontade nos comentários do post 🙌👇
