La estructura del repository de Git para dos aplicaciones iOS donde una aplicación deriva fuertemente de la otra

El escenario es el siguiente. Estoy trabajando en una empresa que comenzó con una aplicación de iOS. Ahora, la empresa está interesada en crear una segunda aplicación de iOS que comparta gran parte de la misma base de código. La aplicación original no se escribió con la intención de ser reutilizable, ya que no se sabía en ese momento que se crearía una segunda aplicación similar. En el futuro, puede haber incluso más aplicaciones similares que se basan en la base de código existente.

Estamos tratando de determinar la "mejor" opción con respecto a cómo mantenemos el código fuente en el futuro. Así que algunas de las opciones que estamos contemplando incluyen repository único con biblioteca compartida, un repository para biblioteca compartida y un repository que contiene todas las aplicaciones iOS, un repository para biblioteca compartida y un repository por aplicación iOS, etc. etc. También está el cuestión de si usar submodules de git o no si se usan múltiples repositorys, etcétera.

Actualmente, las dos aplicaciones + biblioteca están todas en un repository git. Una de las ventajas de esto es que un desarrollador puede verificar el compromiso del único repository y esperar que el producto se construya, sin tener que preocuparse de actualizar varios repositorys. Básicamente, el desarrollador no tiene que preocuparse por los múltiples repositorys que necesitan moverse en sincronía entre sí o que requieren una combinación específica de repositorys para que una compilation funcione. El desarrollador tampoco tiene que preocuparse por los casos en que otro desarrollador puede haberse acordado de comprometer un repository, pero no el otro.

Aquí hay algunas cosas más que he considerado:

Submodules

He usado submodules antes, pero no soy un experto. Según entiendo, el repository "super" que contiene un submodule también almacena una reference a una confirmación específica del submodule. Esto se ocupa en parte de garantizar que los repositorys múltiples (es decir, la aplicación + biblioteca) se muevan en bloque, aunque supongo que todavía hay problemas con la necesidad de extraer manualmente los cambios del submodule. Además, los problemas con un submodule confirman que no está disponible para tirar si un desarrollador se olvida de enviar sus cambios y el super repository lo menciona.

Un buen aspecto de los submodules es que crea una separación semántica más fuerte entre la biblioteca y las aplicaciones que usan la biblioteca. Si esto es útil en la práctica, no estoy seguro.

Repositorio único

Como se dijo anteriormente, esto es lo que estamos haciendo actualmente. Dos aplicaciones + código de biblioteca compartida todo en un repository. La mayor preocupación ha sido la relativa inexistencia de la capacidad de aislar los cambios entre el proyecto uno y dos y la biblioteca. Por ejemplo, alguien realiza cambios tanto en algunos códigos de bibliotecas como en códigos de aplicaciones en una única confirmación. Entonces, otro desarrollador solo quiere los cambios en el código de la biblioteca.

Un buen aspecto del repository único es que todo se mueve al unísono: nadie tiene que preocuparse de mantener emparejadas varias versiones del repository. Si usa espacios de trabajo XCode, las refactorizaciones son incluso posibles en las dos aplicaciones.

Derivación

Otra opción es utilizar algún tipo de model de bifurcación, ya sea en repositorys únicos o múltiples, para administrar el código.

En última instancia, solo estamos tratando de descubrir un buen model en el futuro para administrar dos o más aplicaciones de iOS más código de biblioteca compartida. Si esto se logra a través de múltiples repositorys, submodules, models de ramificación u otra cosa. ¿Alguna sugerencia general sobre los pros y los contras de las diversas opciones?

Usa submodules. No necesita ser un experto porque es realmente fácil de usar. Especialmente cuando se combina con una GUI como SourceTree. Tenía exactamente el mismo escenario que tú y eso es lo que hice. SourceTree incluso te advertirá si estás intentando comprometer un repository que tiene cambios sin compromiso en un submodule.

Un único repository es ridículo. Eso significaría que cada vez que alguien nuevo quisiera download un proyecto, tendrían que downloadlos todos.

La ramificación va a ser demasiado complicada para hacer correcciones de errores que se apliquen a todas las twigs relevantes.

La estructura que tengo para mi proyecto actual es:

Repo del proyecto (para el proyecto en el que estoy trabajando personalmente)
-Repo base del proyecto (para código compartido entre miembros del equipo)
– Repo de utilidades (para código que es reutilizable en cualquier proyecto)

Cocoapods , hacen que la administración del código relacionado entre aplicaciones sea simple.

Tuvimos una base similar para un set de aplicaciones e inicialmente nos costó mucho administrarla, pero una vez que se ejecuta cocoapods personalizados, nunca mirará hacia atrás. Debería consultar esto para get una guía de inicio sobre la gestión de sus propios cocoapods.

Es gratis, es poderoso y te preguntarás por qué nunca los usaste antes.