Modelo de ramificación Git para proyecto Java cliente-server

Tengo un proyecto de Java que usa un set común de códigos en dos aplicaciones principales que deben distribuirse: un server y un cliente. El proyecto está organizado en los siguientes packages y cada aplicación requiere los packages como se indica.

Packages | Client | Server ------------------------------+--------+--------- com.example.game.server | No | Yes com.example.game.client | Yes | No com.example.game.core | Yes | Yes com.example.game.core.physics | No | Yes com.example.game.ui | Yes | No com.example.game.utils | Yes | Yes com.example.game.networking | No | Yes org.library.sourcecode | Yes | Yes 

Me gustaría distribuir el cliente y el server como flasks con solo los packages relevantes para la aplicación respectiva incluida, y no include ningún código innecesario. Preferiblemente habría una twig git para cada aplicación (server y cliente) donde cada confirmación representa una versión de publicación (ver mi respuesta a continuación). Todo el historial de confirmaciones para el proyecto como un todo (server + cliente) debe ser rastreado en set (es decir, una twig de "desarrollo" con todo el código en ella). ¿Cómo puedo hacer esto?

Tenga en count que no me gustaría usar más de un repository ya que el código del cliente y del server está tan estrechamente vinculado, y debe manejarse en set.

Mi solución

Esta es mi solución al problema; sin embargo, esto parece muy engorroso y difícil de seguir. Mi proyecto es mucho más intrincado y de mayor escala que el ejemplo, y esto no parece una buena solución práctica.

Tenga en count que no soy un experto con Git de ninguna manera.

La twig master contendría todo el código fuente del proyecto (cada package). Se realizarían confirmaciones de desarrollo regulares en esta twig, y ​​las twigs de características y revisiones se fusionarían en esta. Una vez listo para su lanzamiento, la twig master se volvería a establecer en una releaseprep-client o releaseprep-server que serviría como un punto medio donde se eliminarían los packages innecesarios para la aplicación respectiva y se prepararía para su lanzamiento (no se deberían include características). adicional). Una vez preparados para su lanzamiento, estas twigs se networkingistribuirían en sus respectivas sucursales de release-client release-server . Cada compromiso en estas twigs de "lanzamiento" representaría un estado listo para la producción de la aplicación y se labelría con el número de versión.

Aquí hay un gráfico para comprender mejor (soy un progtwigdor, no un artista):

Mi modelo de ramificación de Git