Git: cómo mantener twigs paralelas permanentes

Tenemos proyecto (aplicación PHP), pero la installation para cada cliente varía, a veces muy poco, a veces más. Aún así, gran parte del código fuente es común. Gestionamos instalaciones específicas como sucursales paralelas a la twig principal y tenemos que transferir los cambios desde el maestro a otras twigs. La misma situación se resolvió en Git: ¿cómo mantener (en su mayoría) las twigs paralelas con solo algunas diferencias? La solución más votada fue transferir los cambios entre braches de esta manera:

git pull git checkout local git rebase master 

Como se menciona en la solución, crea impulsos de avance rápido después del rebase, lo que me parece una complicación muy desagradable. Mi PREGUNTA es: ¿por qué no hacer en cambio?

 git pull git checkout local git merge master 

Realmente depende de lo que quieras hacer con la sucursal. Sí, si rebasaste local, creará impulsos de avance rápido después de la rebase. Por otro lado, mantendrás un set de cambios distintos en el futuro y lo que habrá en tu sucursal será un set de cambios COMO SI SE HUBIERAN HECHO AL NUEVO JEFE DE MAESTRO.

Por el contrario, fusionar el maestro con el local mantendrá la marcha local al mismo time que el maestro y registrará el historial tal como sucedió. Si necesita poder rebuild el estado del local en el pasado, querrá hacer esto. La historia nunca cambiará. Pero, tendrás una historia más complicada de la que lidiar.

La idea es que use una twig común y dos (o tantas como necesite) sucursales específicas del cliente. Todos los cambios comunes entran en el maestro, y cada twig de cliente obtiene cambios que pertenecen solo a ese cliente. Periódicamente (cuando se considera que el maestro está en un punto estable), fusionará los cambios del maestro en la twig del cliente ( git checkout custA; git merge master ). Esto trae un código "común" más nuevo en la sucursal del cliente. Nunca se fusionará a la inversa, eso contaminaría al maestro con el código específico del cliente.

Cuando realiza una entrega al cliente A, realiza una compra en la sucursal "custA" y la envía. Y, por supuesto, también para otros clientes.

Ahora digamos que adquiere un nuevo cliente, "C", y un poco más tarde encuentra una característica que los clientes A y C quieren, pero B no. Usted crea (alias "fork") una twig fuera de master ( git checkout -b AC_feature master ), la codifica / testing, realiza commits sobre la git checkout A; git merge AC_feature and similarly for customer C en A y C ( git checkout A; git merge AC_feature and similarly for customer C ). No lo codifica en A y luego confía en fusionar A en C, porque eso haría que todo A pase a C.

Si, en algún momento más tarde, encuentra una falla menor en esa característica, realiza el cambio en la misma twig ( git checkout AC_feature; edit/test/commit ), y luego la fusiona en custA y custC como se indicó anteriormente.

Fuente: Estos artículos refrescantemente claros y útiles del desarrollador de Gitolite – Sitaram Chamarty, escritos en parte con la contribución directa de Junio ​​Hamano (socio de Linus Torvalds en el mantenimiento de Git).

Mantenimiento de sucursales de clientes paralelas:

http://gitolite.com/archived/special-branches.html

Artículo de seguimiento sobre Ramas Comunes y de Clientes "Reparado":

http://gitolite.com/archived/special-branch-fixups.html

La respuesta de Greg a su otra pregunta parece ver diferentes twigs como locales restantes para instalaciones particulares, no empujadas a otros repositorys (énfasis añadido):

Si es local para un sistema , entréguelo a la twig "local" de ese sistema , de lo contrario, comprométalo a "maestro" y empújelo hasta un repository común.

Casi siempre quieres empujar rápidamente hacia las twigs en un repository compartido. La documentation de git rebase explica cómo recuperarse de una rebase en sentido ascendente ( es decir , git rebase luego git push -f ), y no es divertido para nadie involucrado.

Para otro enfoque, consulte Nunca fusionar de nuevo :

Hay casos válidos en los que una vez se bifurca con la intención de nunca volver a fusionarse, pero en general debe esforzarse mucho para mantener los cambios en dicho tenedor al mínimo.

El autor continúa para analizar la política de ramificación para varias versiones de clientes dentro del mismo repository.