Quando você faz rebase e quando você faz merge?

Faça rebase da sua própria branch de feature sobre a branch principal para manter o histórico linear e resolver conflitos em doses pequenas antes do review. Faça merge ao integrar essa branch numa branch compartilhada, e nunca faça rebase de uma branch que outras pessoas já baixaram, porque reescrever histórico compartilhado força todo mundo a uma recuperação. Em resumo: rebase em trabalho privado, merge em trabalho público, e squash quando o histórico de commits não acrescenta nada para quem ler depois.

Minha regra é rebase em histórico privado, merge em histórico compartilhado. Enquanto uma branch de feature é minha, eu faço rebase dela sobre a main com frequência, porque isso mantém o diff honesto e eu prefiro bater em conflitos em três doses pequenas do que numa enorme no fim. Quando ela entra na main eu faço merge, geralmente com squash, porque ninguém lendo o log daqui a seis meses quer os meus commits de corrigir typo. O que eu não vou fazer é rebase numa branch que outra pessoa já baixou, já que o rebase não move commits, ele cria novos com hashes novos, e a cópia dos originais de todo mundo fica órfã. Isso significa um force push e alguém perdendo trabalho. Já tive que guiar um colega pelo reflog para se recuperar exatamente disso. Além da regra, eu sigo o que o time já faz, porque um histórico consistente que todo mundo entende vale mais que a minha preferência pessoal, e essa não é uma briga que valha a pena comprar em code review.