¿Qué pasa con las asignaciones de fusión?

Veo muchas preguntas en las que la gente pregunta cómo puede evitar confusiones de fusión "sin sentido".

¿Qué es exactamente malo acerca de la fusión? Los encuentro útiles, ya que puedes ver exactamente dónde comenzaron a trabajar dos desarrolladores, y dónde el trabajo se fusionó. Parece que volver a basar, como sugieren muchas respuestas, destruye esta información y se pierde gran parte de la historia del proyecto.

¿Hay algo que me falta que hace que una combinación se vuelva indeseable?

Hay dos types diferentes de confianzas de fusión:

  • Combinaciones de fusión explícitas, que resultan, por ejemplo, de una fusión explícita de una twig de entidad en la twig principal
  • y compromisos de fusión implícitos, que dan como resultado, por ejemplo, haciendo una git pull antes de intentar empujar

Las asignaciones de fusión explícitas suelen ser perfectamente correctas. Por lo general, incluso se aplica ese tipo de confianzas de fusión diciendo git merge --no-ff .

Los implícitos son simplemente ruido, como la situación típica es que un desarrollador cambió un file y luego otro desarrollador trabaja en otro file pero se olvidó de tirar antes de hacer los cambios, y un git pull combinará implícitamente ambos commits creando un fusión ruidosa commit. La historia más lógica sería simplemente un compromiso de un autor y un compromiso del otro autor. Haciendo git pull --rebase exactamente hará eso.

Por supuesto, hay excepciones. Si ambos autores realmente trabajaron en el mismo file, podría ser mejor tener un compromiso de fusión en este punto. – Pero incluso en este caso, tal vez una rebase sea mejor, ya que hace que los cambios contra el primer compromiso sean más explícitos y, por lo tanto, less propensos a errores.