Git – Fusionando cambios de una twig de característica a otra entre desarrolladores

En general, nuestro código es bastante modular, por lo que los desarrolladores no realizan cambios en los mismos files al mismo time. Pero me he encontrado con una situación y veo dos forms de resolverlo, así que estoy buscando opiniones sobre cuál es la mejor manera y por qué (o soluciones adicionales). Mi compañero de trabajo realizó cambios en algunos files en su twig de características que me gustaría usar en mi twig de características. Estas son funciones separadas, no una twig de característica compartida. Veo dos soluciones:

1) Él puede fusionar su twig característica en desarrollar y empujar al origen. Luego puedo extraer la twig de desarrollo y volver a establecer la base de mi twig de características localmente.

2) Puedo fusionar su twig característica directamente en la mía.

Realmente no me gusta esto último porque simplemente parece estar apagado; fusionar una twig de características en una twig de características directamente cuando las dos características en sí mismas no se relacionan, solo un par de las dependencies lo hacen. Entonces, fui con el primero, pero para reference futura tengo curiosidad de cómo otros manejarían esta situación.

Lo que haces en git es solo un reflection del process de desarrollo.

1) No necesita volver a establecer la base de su trabajo en la twig de desarrollo simplemente fusionar la twig de desarrollo en su twig de trabajo. Si rebase, no puede compartir su trabajo.

2) Necesita incorporar su trabajo pero no está listo para impulsarlo y no hay ningún problema técnico con la fusión de su trabajo. ¡Solo tenga en count que puede estar incorporando el trabajo beta!

Este no es un problema de git, solo depende de un trabajo que aún no ha terminado, sucede todo el time, solo necesita mantenerse regularmente fusionándose en el trabajo del otro desarrollador hasta que termine.

Entiendo su instinto de preferir la primera solución, y creo que es la correcta, porque:

  • El otro desarrollador fusionará sus propios cambios en el develop . Esto es muy natural: fusiona sus propios cambios y, si es necesario, resuelve sus propios conflictos .
  • Cuando rebase el develop , fusiona efectivamente sus propios cambios y, si es necesario, resuelve sus propios conflictos . Nuevamente, esto es muy natural e intuitivo.

En la otra alternativa, fusionarás su sucursal con la tuya, y tal vez tendrás que resolver sus conflictos. Y eso es en realidad solo la punta del iceberg, porque incluso si la fusión pasa sin conflictos, ¿qué pasa si se rompe la construcción? ¿O qué pasa si la construcción todavía está bien, pero ahora el progtwig tiene un comportamiento extraño? El otro tipo sabría mejor cómo manejar estos problemas.

Cuando los desarrolladores originales fusionan sus propios cambios, son responsables de mantener todo funcionando: resolver conflictos, hacer que la construcción pase, hacer que las testings pasen, validar los cambios, lo que resulta en un package que está listo para ser utilizado por otros y totalmente funcional. De esta forma, el próximo desarrollador que trabaje sobre la twig bien validada puede asumir con security que si algo no funciona después de su cambio, la causa debe ser sus propios cambios.

Lo uso a diario Me siento muy cómodo fusionando mis propios cambios o los cambios de mi equipo, porque sé de qué se tratan. Odio fusionar los cambios de otros equipos (si es que alguna vez tengo que hacerlo), porque no sé de qué se tratan y cómo probar el resultado.