¿Cómo se puede mantener un cierto estado del repository git siempre accesible?

Estoy tratando de diseñar reglas para un pequeño grupo de personas que queueboran en el software que se utiliza para el análisis de datos. Es importante tener un medio para reproducir el funcionamiento del código en algún punto del pasado, es decir, volver a un estado en el pasado (algo que el control de versión debería permitir). En el pasado, esto ha sido posible para nosotros con svn. A continuación, podemos labelr nuestros resultados de análisis de datos con el número de revisión svn utilizado para esa ejecución.

Hay historias sobre cómo a través de la bifurcación, la fusión y el rebase, las historias se pierden / se vuelven inaccesibles / una pesadilla para llegar, etc. Al mismo time, el fácil event handling la ramificación para el desarrollo de características experimentales es lo que nos hace considerar un cambio de svn a git.

Entonces, ¿qué reglas deberíamos seguir para asegurarnos de que siempre podremos recuperar un estado de código que se ejecutó para un análisis determinado? ¿Solo usas la twig principal para las ejecuciones de análisis? Si es así, ¿qué operaciones deberían ser rechazadas en la twig principal?

EDIT: dos buenas sugerencias se explican a continuación: El labeldo de commits que son importantes hará que el análisis sea transparente y reproducible (antlersoft). Esto no requiere nuevas reglas más que dejar las tags en paz. Este flujo de trabajo de labeldo no requiere reglas para el rebase y la fusión. La sugerencia de Tom Anderson es útil en el sentido de que un repository central que se supone que alberga todo el código que tiene tags adjuntas (esto sería una convención / regla) podría servir para permitir a otros miembros el acceso a estos bits de código.

La solución a esto no tiene que implicar restringir lo que puede hacer en cualquier twig. Simplemente use las tags git, y no las elimine ni las mueva. Marque la confirmación que usa para ejecutar cada análisis y registre la label de compromiso con el análisis (esto es muy similar a lo que hace en svn, excepto que en lugar de un número de revisión generado por el VCS es un nombre de label que usted suministra). Entonces, la versión para el análisis y toda su historia siempre estará disponible, independientemente de qué más haga (rebase, etc.) en la twig.

La única regla que necesitaría seguir es nunca borrar el historial. Eso significa nunca volver a basar, o usar algunas otras operaciones less comunes.

Más bien, significa nunca volver a basar (etc.) en el repository desde el que ejecuta sus análisis. La gente puede rebase libremente en otros repositorys. ¿Sería posible para usted configurar un repository 'maestro dorado', al cual todos presionan el código, con una política de no rebase, y usarlo para ejecutar sus análisis? Luego, las personas pueden desarrollar código de la forma que prefieran a nivel local, y enviarlo a ese repository cuando esté listo para ejecutarse. Es un flujo de trabajo bastante normal para los equipos que usan un DVCS.

Si las personas necesitan ejecutar análisis (para publicación, por así decirlo) de sus repositorys locales, entonces las cosas son más complicadas. Sugeriría que todos tengan dos repositorys localmente, uno para desarrollo y otro para análisis. Se permite la rebase en el repository de desarrollo, pero el código debe ser enviado al repository de análisis para ser utilizado (y luego al rest del equipo). Eso es un poco más débil, porque es solo una convención lo que impide que las personas realicen cambios en el repository de análisis, mientras que con un repository central que nadie usa directamente, el rebase no es algo que sucederá.

Sé que este hilo es viejo, pero solo quiero dejar una cosa clara …
Rebasing no elimina ningún historial y no elimina ningún commit. Solo agrega nuevas confirmaciones y mueve una reference de twig.
Siempre que un commit sea referencedo por cualquier cosa (twig, label u otro commit) vivirá para siempre.
Solo los objects sin reference se eliminan si son antiguos (creo que son 30 días por defecto) y usted hace una recolección de basura o similar.