¿Cuál es la estrategia ideal de ramificación git para el desarrollo de este producto?

Supongamos que quiero agregar un set de funciones relacionadas, pero independientes, a la aplicación para iPhone de Twitter (fuente mágicamente abierta). Mientras está en la aplicación, puede presionar "Domótica" y se le presentará una pantalla llena de botones para controlar las características de su hogar: Luces; Televisión; Temperatura; Sombras; y musica.

¿Cuál es el model de ramificación ideal en Git para desarrollar este set de características?

Aquí hay algunas suposiciones:

  • Una persona (la misma persona) desarrollará todas las características.
  • Twitter fomenta el rebase como su model de integración.
  • Todas las características comparten un código base.

Y aquí están mis cosas agradables para el model, aunque me encantaría escuchar todas las opciones de models:

  • Debería ser fácil para los revisores de códigos revisar cada característica de forma independiente al final. En otras palabras, alguien que revise el código Lights no debería tener que lidiar con ningún cambio realizado mientras implementaba Television.

  • Cada característica debe tener un historial agradable y limpio durante el desarrollo. Cuando miro a foo.m mientras trabajo en Lights, solo debería ver los cambios realizados para implementar Lights, no los cambios realizados para implementar Television.

  • Todavía puedo comstackr y probar luces incluso si he dejado la televisión en un estado desorderado / roto.

Un requisito para el model es que necesito generar comstackciones de testing de manera regular que tengan todas las características integradas, tal como se presentarán a los usuarios. En otras palabras, cuando ejecuto mi versión de testing, veo una pantalla de Automatización del hogar que contiene todas las características.

Mi instinto original aquí fue establecer las twigs de esta manera:

Twitter \ Automation \ Lights \ Television \ Temperature \ ... 

En otras palabras, me ramificaría desde Twitter para crear la twig "Automatización", que contiene el código compartido que utilizan todas las funciones de automation del hogar, incluido el código de resguardo para la interfaz de usuario general desde la que se accede a las funciones (es decir, la "pantalla de botones "referencedos arriba". Y luego crearía una serie de twigs de Automatización, una para cada característica.

Sin embargo, en este model, tengo problemas para entender cómo produciría mis comstackciones de testings totalmente integradas en este mundo. Imagino que necesitaría crear alguna otra twig que combine regularmente las twigs Lights / Television / etc. Pero habrá conflictos obvios en esta fusión.

Por ejemplo, imagine que el código de UI compartido en la twig de Automatización tiene una function num_buttons_to_render que devuelve el número de botones para representar en la IU de num_buttons_to_render . La twig de Automatización devolvería 0 aquí, ya que no implementa ninguna de las características en sí. Cada sucursal infantil (Luces, Televisión, etc.) devolvería 1, ya que solo están implementando sus propios flujos de trabajo respectivos y no se preocupan por las otras características. Pero la twig de testings querría devolver 5 aquí, ya que quiere renderizar las 5 funciones de automation (Luces, Televisión, Temperatura, Sombras y Música). Así que me gustaría arreglar ese conflicto en la twig de testing una vez y luego continuar integrando los cambios posteriores de todas las twigs de características a lo largo del time. Pero ni siquiera está claro para mí que pueda hacerlo, ya que todas las twigs de características están utilizando un model de rebase según lo dictado por los estándares de desarrollo de Twitter.

Soy nuevo en git, así que espero tener algo de sentido aquí. Si no, estaré aquí para responder proactivamente a cualquier pregunta de seguimiento. ¡Muchas gracias por su ayuda!

Imagino que necesitaría crear alguna otra twig que combine regularmente las twigs Lights / Television / etc.

Eso suena plausible.

Pero habrá conflictos obvios en esta fusión.

Así que lidiar con ellos. Mejor hacerlo más temprano que tarde.

Pero la twig de testings querría devolver 5 aquí, ya que quiere renderizar las 5 funciones de automation (Luces, Televisión, Temperatura, Sombras y Música). Así que me gustaría arreglar ese conflicto en la twig de testing una vez y luego continuar integrando los cambios posteriores de todas las twigs de características a lo largo del time.

¿Por qué debería ser eso un conflicto?

¿Por qué no hacer que cada function llame a una function para registrarse, lo que incrementa el recuento de características? Si ninguna function llama a la function, el recuento es cero. Si uno lo llama, el conteo es uno. Si cinco lo llaman, el recuento es cinco. Eso parece mejor que tener un contador codificado en alguna parte, que tiene un valor diferente en diferentes twigs.

No veo ningún problema con su model de bifurcación sugerido, el único problema que ha descrito no está relacionado con git y puede resolverse mejorando el layout del código.

Pero ni siquiera está claro para mí que pueda hacerlo, ya que todas las twigs de características están utilizando un model de rebase según lo dictado por los estándares de desarrollo de Twitter.

Tal vez me esté perdiendo algo, pero no veo por qué eso es un problema. Si rebase periódicamente la Automatización desde el código en sentido ascendente, luego rebase cada twig de características desde la Automatización (no desde la stream ascendente), entonces no habría ningún problema con la fusión de las twigs de características a la twig de Automatización.