¿Cuándo haces rebase y cuándo haces merge?

Haz rebase de tu propia rama de funcionalidad sobre la rama principal para mantener el historial lineal y resolver conflictos en dosis pequeñas antes de la revisión. Haz merge al integrar esa rama en una rama compartida, y nunca hagas rebase de una rama que otras personas ya se han bajado, porque reescribir historial compartido obliga a todos a una recuperación. En resumen: rebase del trabajo privado, merge del público, y squash cuando el historial de commits no le aporte nada a quien lea después.

Mi regla es rebase del historial privado, merge del historial compartido. Mientras una rama de funcionalidad es mía, le hago rebase sobre main con regularidad, porque mantiene el diff honesto y prefiero encontrarme conflictos en tres dosis pequeñas que uno enorme al final. Cuando entra en main hago merge, normalmente con squash, porque nadie que lea el log dentro de seis meses quiere mis commits de arreglo de erratas. Lo que no voy a hacer es rebase de una rama que otra persona se ha bajado, porque el rebase no mueve commits, crea otros nuevos con hashes nuevos, y la copia de los originales que tiene todo el mundo queda huérfana. Eso significa un force push y alguien perdiendo trabajo. He tenido que guiar a un compañero por el reflog para recuperarse exactamente de eso. Más allá de la regla, sigo lo que ya hace el equipo, porque un historial consistente que todos entienden gana a mi preferencia personal, y esta no es una colina en la que morir en una revisión de código.