Somos una compañía de productos y estamos brindando soluciones a más de 50 clientes, que están creciendo cada mes y tenemos un model de ramificación bastante simple que me gustaría actualizar si es posible.
Estamos haciendo agilidad, por lo tanto, tenemos sprints y lanzamientos. Cada mes o dos estamos abriendo una nueva versión de la twig maestra que se estabilizará y luego se entregará a los clientes que estén interesados en las características que contiene. Hasta aquí todo bien. Durante el desarrollo se crean nuevos clientes. Digamos que comenzamos a trabajar en un cliente A y decidimos que este cliente vaya con cierta versión, digamos release/1.0 por lo que hacemos el release/A_1.0 twig release/A_1.0 y comenzamos nuestro desarrollo allí, una vez que hayamos terminado, fusionamos release/A_1.0 -> release/1.0 e implementamos en producción desde la release/1.0 este cliente.
Antes de continuar explicando dónde está el problema, estableceré algunas reglas que guardamos:
release está abierta, el master nunca se fusiona allí. release/{client}_{version} twigs release/{client}_{version} se actualizan ocasionalmente con release/{version} branch (los numbers de versión deben coincidir). hotfix se fusionan en la release/{version} twig. release/{version} twig 2-3 versión anterior, las twigs de release se fusionan con el master por lo que todas las revisiones de estas versiones anteriores también están en la nueva versión. release/{version} twig. El problema es mala planificación, pero esto sucede y no se puede evitar. Digamos que negociamos con un cliente (B) y decidimos darles la versión 1.0, que estaría abriendo una sucursal haciendo que sea la release/B_v1.0 mientras desarrollamos este cliente en esta sucursal, el time pasa y nuestro equipo de equipo abre el sprint otra release , por ejemplo 1.1. Algunas veces, el process de desarrollo del cliente toma suficiente time para que el producto abra, si no una, dos o tres nuevas release/{version} . Entonces, si esto sucede, la administración y el cliente pueden decidir lanzar una versión más nueva (digamos 1.3, anteriormente fue desarrollado para 1.0). Ahora lo que se tiene que hacer es que tenemos que abrir la twig de la release/1.3 para este cliente y luego fusionar la twig abierta previamente – eso sería hacer una release/B_1.0 --> release/B_1.3 fusión release/B_1.0 --> release/B_1.3 y esto puede ser DOLOROSO de estar hecho. ¿Por qué?
Debido a que la
release/B_1.0se actualiza ocasionalmente con larelease/1.0esto significa que todas las revisiones de la versión 1.0 estarán en larelease/B_1.0(esto no se puede evitar ya que algunas revisiones son cruciales para el desarrollo del cliente) y cuando llega el momento de fusionar larelease/B_1.0 --> release/B_1.3esto includeá todas estas revisiones de la versión 1.0 en larelease/B_1.3y más tarde cuando serelease/B_1.3 --> release/1.3fusión se includeá en la versión 1.3, que está prohibida.
release/B_1.0 todas las confirmaciones / fusiones, que estaban en la release/B_1.0 y no son las revisiones que salieron de la release/1.0 , en la release/B_1.3 pero esto puede llevar mucho time y se pueden cometer errores también debido a la hecho de cómo funciona la historia de git.
Propuse que estas sucursales de clientes se puedan bloquear para la confirmación, por lo que solo se fusionarán y cuando se pueda realizar este tipo de combinación, puedo seleccionar fácilmente las fusiones de las twigs relevantes (ignorando las fusiones de la release/{version} ) y no preocuparse por dejar los compromisos finales, pero esto significa que todos los que trabajan en esta twig tienen que crear su propia sucursal y fusionarla en ella, lo que en cierto modo ralentiza el process de desarrollo, en mi opinión.
¿Tiene alguna otra sugerencia que facilite tales fusiones?
¿Por qué no administrar estos clientes para diferentes repositorys git?
Administrar todos los clientes en un repo de git parece eficiente, pero en realidad no lo es. Y basado en que todos los clientes tienen los mismos requisitos / errores o debe negociarlos para sincronizar con el otro.
Así que será mejor que los administres por separado. Incluso si dos clientes tienen las mismas funciones, puede usar las funciones de repositorys cruzados fácilmente:
# In repoA git remote add B <URL for repo B> -f gitk --all # find the commit of repoB you want to use in repoA git cherry-pick <commit in repoB>