Flujo de trabajo de Git para una tarea de modelado con actualizaciones de datos

Estoy buscando comenzar una tarea de modelado / pronóstico con la ayuda de git. Quiero configurar una architecture git para facilitar esto, pero estoy teniendo algunos problemas.

Objetivo: al final de la tarea de modelado en las filiales de la región / subregión (revisiones humanas necesarias, revisión humana = compromiso), combine hasta maestro para tener todas las previsiones disponibles para su revisión con qué versión del código y el set de datos se ejecutó . Si es necesario realizar revisiones más adelante, un modelador debería poder ramificarse desde el momento en que se completó el pronóstico exacto y trabajar con la versión correcta (posiblemente más antigua) del código.

Problema: los datos y la versión del código pueden cambiar. Es probable que las ejecuciones de models anteriores no sean compatibles con códigos / datos antiguos (por ejemplo, en la región 1, código de versión 1 y datos de la versión 2, pero en la región 2, código 4 y datos 6), y al final de la proyecto, las previsiones deben poder reproducirse.

Mi solución: parece estar en contra de la filosofía de git, pero cada vez que hay un set de datos o actualización de código, colóquelo en el maestro y añada un número de versión al nombre del file. Tener twigs de región / subregión y labelr cada confirmación de finalización de previsión. Luego, cuando se complete la previsión, combínelo con maestro y agregue otro file que indique en qué versión se ejecutó el código y los datos. Si necesita realizar una revisión, busque la label de finalización y remodele con la versión correcta del código, vuelva a fusionar en región y luego a maestro. Si un model necesita ser reproducido, ejecútelo con el código / datos correctos (del file adicional creado).

¿Es esta la mejor manera de usar git para seguir este process, o hay una forma mejor / más simple? ¿Funcionará este process o hay problemas involuntarios que puedan popup debido a esto?

Los datos y la versión del código pueden cambiar

Eso significa que tiene dos sets de files, con un fuerte acoplamiento, pero con su propia evolución dentro de ese acoplamiento.

Ese es un trabajo para los submodules de Git : coloque el código y los datos cada uno en su propio repository de git, y haga reference a un SHA1 fijo para cada uno en un repository padre principal:

parent/ code/ data/ 

De esta forma, desde el repository principal, puede crear una twig en la que cambien el code y los data . Cuando se completa la previsión, lo que está fusionando para master (en primario) es la última SHA1 de code y data .

El interés de los submodules es que usted registre en el repository principal el SHA1 exacto del repo datos que se supone que es compatible con el repository del code .
Y evitas por completo cualquier "hackeo" como renombrar files.