¿Cómo se pueden evitar los conflictos de combinación cuando se agregan diferentes methods (etc.) en la misma location?

Prefacio: esta no es una pregunta general sobre los conflictos de fusión, sino un caso muy específico que me sigue molestando. Es bastante trivial, pero asciende a una molestia (leve) con la frecuencia suficiente para destacarse. No me preocupa la fusión general, solo se trata de ahorrar unos segundos aquí y allá para una resolución de conflictos muy mecánica, al evitar dicho conflicto en primer lugar. También soy absolutamente consciente de que esto no es un "problema de git" o algo así.

Dicho esto, supongamos que tenemos un file fuente de una class:

class Xyz ... ... def last_method ... end end 

Esto comienza de manera idéntica en el master y en varias twigs de características. Ahora, a medida que implementamos nuestras funciones, agregamos más methods a esta class:

Rama 1:

 class Xyz ... ... def last_method ... end def new_method1 ... end end 

Rama 2:

 class Xyz ... ... def last_method ... end def new_method2 ... end end 

Los nuevos methods no están relacionados y felizmente coexistirán cuando ambas twigs se fusionen de nuevo a master .

Obviamente, esto llevará a un conflicto de fusión. La razón es clara: cambiamos el file de origen exactamente en el mismo lugar, y obviamente git no puede (y no debería) mágicamente decidir por nosotros que este no es un conflicto "real"; git tendría que elegir cuál de los methods debería colocarse primero, etc.

Una forma de evitar el conflicto sería insert los nuevos methods en diferentes lugares del file (asumiendo que el order no importa), pero realmente no queremos gastar mucho esfuerzo (o nada en realidad) para mantener mentalmente rastrea dónde insert cosas o qué sucede en otras características.

La pregunta, entonces: ¿hay alguna otra forma, tal vez alguna convención de encoding, que aplique regularmente, que de alguna manera evite este conflicto de fusión?

Esta es una buena pregunta. Sin embargo, hay forms de mitigar el problema, bajo ciertas condiciones.

En el caso ideal, al momento de diseñar una class, usted decide de qué se va a hacer (variables, methods, etc.) y ya puede elegir los nombres apropiados para esas. En ese caso, debe escribir resguardos de esos methods en la confirmación que introduce la class.

Esos talones actuarán entonces como "anclajes" para un sistema de control de versiones basado en línea como Git:

 class MyClass def initialize # TODO end def get_ID # TODO end def set_ID # TODO end end 

Después de este "primer" compromiso, diferentes contribuyentes son libres de cambiar el cuerpo de diferentes methods: en mi ejemplo, Alice puede implementar get_ID y Bob puede implementar set_ID sin temor a set_ID con un conflicto de fusión más adelante, porque el def y el end las líneas de cada método ya están presentes en la confirmación original.