¿Puede Git manejar estos casos de uso?

Actualmente estoy migrando de SVN a Git. La base de código es un proyecto Maven de 10-15 modules de gran tamaño. Solíamos tener un repository para cada module.

Me pregunto qué architecture deberían tener mis repositorys Git para manejar los siguientes casos de uso :

  • Un usuario puede pagar 1..N module (s).
  • John se compromete y empuja el module M. Emma saca el cambio de la super-carpeta.
  • John confirma y empuja un cambio de module M desde la super-carpeta. Emma saca el cambio de la carpeta del module.
  • John mueve (con git mv) el file A de M1 a M2, confirma y empuja. Emma edita una actualización del file antes de comprometerse. El file se movió con el cambio de Emma.

Pensé en la architecture de 'repository único', pero no se maneja el CU # 1. El 'submodule', el ' subtree ' y el anterior 'un module-uno-repo' no pueden manejar el UC # 4.

Además, si la mayoría de los casos de uso son manejados por la architecture 'submodule', me gustaría introducir la menor complejidad posible. El submodule introduce conceptos como cabeza despejada y puede inducir a una reparación dolorosa después de errores más frecuentes.

Hice una búsqueda exhaustiva y no estoy seguro de si es posible sin introducir demasiada complejidad, pero espero que algunos de ustedes hayan encontrado una solución alternativa.

Observación: nuestra architecture SVN actual no puede manejar estos casos de uso.

Muchas gracias, Maxime.

Tu análisis es correcto; no hay una forma obvia de abordar todos esos casos de uso a la vez. Sugeriría uno de los 2 enfoques:

  1. El primer requisito de retirar modules individualmente puede no ser realmente necesario. Con git pagará el pago una sola vez cuando haga un clon inicial, pero después de eso las actualizaciones incrementales son muy rápidas.
  2. Si se trata de modules de Maven, quizás cada uno con su propio ciclo de lanzamiento, ¿los modules realmente necesitan una relación de nivel de fuente? De lo contrario, las dependencies del module podrían representarse únicamente en Maven.

En realidad, probablemente debería comenzar con un único repository y luego dividirlo más adelante si lo considera necesario. Pero probablemente no lo harás. 🙂

no puedes tener todo eso. no en GIT y no en SVN.

ya se dio count de que sus requisitos entran en conflicto entre sí e incluso admitió que su configuration actual no cubre todas las situaciones, por lo que debe cambiar la forma en que se aproxima a este problema.

en lugar de exigir ciertas capacidades de la herramienta, intente explicar cuáles son los problemas reales que deben resolverse y permita que las personas sugieran forms de resolverlas, es probable que esas no sean cosas que ya haya considerado.

Trataré ahora de responder a los problemas que ha mostrado en los comentarios e ignoro por completo su request inicial, espero que ayude más con la situación real en la que se encuentra.

no podemos permitirnos una línea de time donde los posts de confirmación de cada (10-15) modules se muestren en el mismo lugar

a diferencia de SVN, en GIT tienes twigs (twigs reales) y cada twig tendrá su propio historial, de modo que mientras tus desarrolladores usen twigs y las combines en lugar de usar rebase, podrás aislar cada logging de twig con los commands apropiados, ver git log --graph para get la idea.

actualmente las fusiones son ansiogénicas y, por lo tanto, los desarrolladores intentan evitar las fusiones tan a menudo como sea posible

no hay una solución real para esto, pero hay forms de mitigar el problema.

Una forma es tener varios clones del repository junto con la copy maestra, si su equipo tiene alnetworkingedor de 40 personas y usted tiene entre 10 y 15 modules, entonces supongo que tiene equipos pequeños que se enfocan en áreas / modules particulares; si ese es el caso, cada subteam debe tener su propio clon del repository y fusionarse localmente allí antes de volver a fusionarse con la copy maestra.

este enfoque divide efectivamente el process de fusión (y la responsabilidad) en dos fases, una que se refiere a los cambios dentro del subequipo y otra que trata de la interacción con el rest de los modules.

Pero debo mantener el caso de uso 4 (mover y editar) para darle a Git una ventaja clara en los ojos del desarrollador y domesticar ese miedo a la fusión

Seré completamente honesto, UC # 4 es imposible *. particularmente en GIT donde la operación mv es en realidad una composition de rm y add .

quizás si la adición ocurre antes del movimiento, algunos (d) VCS pueden resolverlo, pero no creo que ese sea el caso para GIT, aun así creo que estás tomando el path equivocado para "domesticar ese miedo a la fusión", déjame explique.

* @sleske sugiere verificar este hilo para saber cómo hacer UC # 4

la razón por la que las personas temen a la fusión es porque no la entienden y SVN te obliga a fusionarte en sentido ascendente (es decir, en el server) lo que agrega presión, el problema con tu enfoque es que al intentar ayudarlos a evitarlo estás reforzando la idea de que las fusiones son algo oscuro y peligroso que debe evitarse, no hagas eso.

si quieres que superen el miedo, tienes que entrenarlos para que tengan las herramientas para enfrentar la situación, en otras palabras, no ayudarlos a evitar el problema, obligarlos a resolverlo, enseñarles sobre todas las fusiones y conflictos. styles, cuéntales sobre el rerere , incluso enseñales la fusión del pulpo que nunca he usado, ¡pero qué demonios les enseñará a ellos también! y luego HAGA que practiquen para que se convierta en algo que saben y pueden manejar.

las fusiones en GIT no son tan estresantes como con SVN porque también son locales, así que puedes hacerlas tantas veces como quieras sin temor a arruinar el entorno de otro peoiple, solo las presionarás una vez que estés absolutamente seguro de que ' re ok

eso es todo por ahora, si tiene preocupaciones adicionales, agregue un comentario y veré si tengo una idea, ¡buena suerte!