git: Actualizando twigs que dependen unas de otras

Situación Creo que una image es una mejor explicación:

enter image description here

Como puede ver, tenemos varias twigs, la mayoría de ellas solution-xyz-foo para diferentes numbers xyz . solution-12 basa en la solution-11 y así sucesivamente. También hay algunas desviaciones de esta regla, por ejemplo, la twig hystrix-dashboard-demo .

Motivación El código en las sucursales es utilizado por los participantes del curso en un curso de estilo de class. Como tal, los participantes resuelven los ejercicios y, al final del curso, terminan con un código similar al que proporcionamos en la twig solution-24 . En caso de que un participante supere el ritmo o se enfrente a otro problema, puede consultar fácilmente la sucursal correspondiente y continuar con el rest de los ejercicios.

Además, es posible observar las soluciones de cada ejercicio, que se proporcionan como un compromiso único.

En otras palabras, para los participantes en el curso, las twigs / soluciones que se construyen una encima de la otra tienen una gran ventaja que nos gustaría mantener (esto se basa en la retroalimentación de múltiples cursos realizados hasta el momento).

Como desarrollador del curso (preparando ejercicios y soluciones, presentando el contenido a los participantes, etc.) necesitamos actualizar partes del código de vez en cuando. Por ejemplo, podría ser el caso de que deseemos solucionar un problema en la solution-3 . Para que esta solución sea visible en la solution-4 , etc., debemos fusionar / volver a establecer / seleccionar con precisión la confirmación que contiene la corrección. Para evitar un gran lío, decidimos aplastar todas las actualizaciones de cada solución en una sola confirmación, y luego rebuild la estructura un tanto lineal que se muestra en la image usando algunas rebases.

Problema Como habrás adivinado, hacer las rebases es mucho trabajo. Incluso con un script auxiliar (que vuelve a asociar las twigs a los commits después de una rebase, pero debe mantenerse en caso de nombres de twig nuevos / modificados), aún tenemos que hacer la rebase, arreglar conflictos, volver a adjuntar las twigs, y empuja los cambios nuevamente dentro del repository (usando un empuje de fuerza).

Además del trabajo real involucrado, esto es algo que solo los miembros del equipo con mucha experiencia en git están seguros de poder hacer. En otras palabras, aquellos que no tienen tanta confianza se quejan del procedimiento (que claramente entiendo).

Como nota al margen, perdemos la ventaja obvia de git: no hay historial de cambios (y se pierden versiones antiguas). Además, los desarrolladores deben queueborar y comunicar los cambios al código.

Pregunta ¿Puede recomendar CUALQUIER flujo de trabajo tag / branch / rebase / … que solucione los siguientes problemas?

  • los participantes del curso pueden fácilmente get una solución actualizada para el ejercicio en el que están trabajando actualmente (EDITAR: actualmente, hacer esto con el mouse en Eclipse es la forma preferida)
  • las soluciones para cada ejercicio se proporcionan de una manera conveniente (es decir, una confirmación única)
  • los desarrolladores pueden integrar fácilmente correcciones y actualizaciones a soluciones individuales para que también las soluciones posteriores que se basan en él se actualicen en consecuencia
  • [opcional] se conserva el historial de cambios

Como nota, puede suponer que el código no cambia mientras un curso está en progreso (por lo que no es necesaria la git remote update en las computadoras de los participantes).

En lugar de acceder a cada commit 'solution-xyz-foo' como twigs separadas, intente acceder a él como antepasado buscado de la cadena.

 git checkout -b MyWorkingBranch remotes/origin/LAST_COMMIT_IN_COURSE^\{/solution-xyz\} 

luego, las cajas posteriores a 'rebase –onto IMPROVED_COMMIT' producirán twigs basadas en el IMPROVED_COMMIT

ver

 git help revisions 

si usa tags en lugar de twigs, puede usar

 git filter-branch --tag-name-filter <rename command> 

para actualizar todas las tags que hacen reference a todas las confirmaciones modificadas. Ver 'git help filter-branch'. Una vez más, los estudiantes podían get twigs directamente de los nombres de las tags con 'git checkout -b TAGNAME' y el historial estaría disponible.

Por lo tanto, suena como una rebase quirúrgica en el medio de la cadena para corregir alguna confirmación seguida de otra rebase de los compromisos (previamente) siguientes: en la confirmación recién arreglada. Así que estoy confundido por el comentario "… Incluso con un script auxiliar (que vuelve a asociar las twigs a los commits después de una rebase, pero debe mantenerse en caso de nombres de twig nuevos / modificados) …". Eso parece ser (posiblemente) tan simple como una rebase –en su confirmación actualizada, por lo que no hay necesidad de mantenerla para nombres de twigs nuevas / modificadas – todo eso se lleva a cabo con la rebase, ¿no?