git workflow para mantener actualizado el software de código abierto modificado a medida

Nuestra Universidad ofrece alojamiento web a los departamentos del campus en los serveres que administramos. La installation de progtwigs de código abierto de terceros requiere modificar los permissions de los files y el código en el progtwig antes de que se ejecute. (Estamos usando suEXEC, si está familiarizado).

Actualmente ofrecemos WordPress a través de un script instalador. El usuario carga la última versión estable y ejecuta una secuencia de commands PHP en el server a través de SSH. Este script PHP modifica los permissions de files de todos los files / carpetas, agrega / elimina algunos códigos en varios files y crea algunos files nuevos. Este script de instalador es un acto de equilibrio engorroso cuando se lanza una nueva versión estable.

Quiero comenzar a utilizar el control de versiones (específicamente git) para rastrear nuestros cambios personalizados en lugar de confiar en un script para realizar los cambios, pero no estoy seguro del flujo de trabajo que utilizará. Estoy familiarizado con la bifurcación y la fusión, pero no estoy seguro de cómo integrar nuestros viejos cambios cuando se emite una nueva versión.

¿Cuál debería ser mi flujo de trabajo de git para integrar los nuevos cambios desde el núcleo de WordPress, pero también preservar nuestros antiguos cambios personalizados?

Sugeriría mantener sus cambios en una sucursal, y volver a basar esa twig contra lo último de WordPress cada vez que actualice. En una línea de time difícil …

+-- WordPress 1.0 v [master] --*--* \ [custom] *--*--* <- your customizations 

Cuando desee actualizar WordPress, cambie a master y realice una nueva confirmación con la última versión de souce (o use git-svn para mantener Master en synchronization):

  +-- WordPress 1.0 | +-- WordPress 1.1 vv [master] --*--*--*--* \ [custom] *--*--* <- your customizations 

Ahora puedes hacer una git rebase master custom para reproducir tus cambios contra lo último, resolviendo cualquier conflicto en el path. Su línea de time se vería así:

  +-- WordPress 1.0 | +-- WordPress 1.1 vv [master] --*--*--*--* \ [custom] *--*--* <- your customizations 

Actualización: para proporcionar un poco de fundamento … Me gusta este enfoque para este problema porque proporciona una clara diferenciación entre el código de WordPress y sus personalizaciones. Cuando obtienes una nueva versión de WordPress, realmente no estás interesado en la "integración". Está interesado en volver a aplicar sus personalizaciones a la nueva versión de WordPress. En mi opinión, esa recustomización se realiza más fácilmente commit por commit a través de una rebase. Cualquier conflicto significa que una personalización probablemente se rompió, por lo que la antigua confirmación de personalización es basura de todos modos, es mejor arreglar el problema en su origen y mantener limpio el historial actualizado.

Después de que el master se actualiza y la custom se actualiza y se envía de nuevo, los queueboradores solo volverán a calcular su trabajo en progreso con respecto a lo último.

Esta es solo mi opinión, como una empresa rebase> fusionar proponente. La belleza de Git es que rara vez hay una respuesta correcta. Solo sigue ajustándote hasta que encuentres algo que funcione para ti.

Mi enfoque general es tener dos twigs, upstream y master . Cree su repository (que lo iniciará en la twig master ), verifique la última copy del código de upsteram ascendente que utiliza y luego cree la twig upsteram con git branch upstream . Además, cree una label que indique qué versión ascendente ha importado, como git tag wordpress-1.0 . Usualmente uso tags livianas para esto (las que no tienen annotations, básicamente son un puntero a una revisión).

 [wordpress-1.0] Key: [tag] v branch * <- upstream * commit ^- master 

Ahora, mientras todavía está en la twig master , copie los cambios y verifique los cambios. Ahora tiene dos twigs, upstream , que contiene la fuente prístina aguas arriba, y el master que contiene los cambios, con el historial que muestra los cambios que ha realizado para upstream

 [wordpress-1.0] v * <- upstream \ +--* <- master 

Realice todas sus modificaciones en la twig master .

 [wordpress-1.0] v * <- upstream \ +--*--*--* <- master 

Cuando aparece una nueva versión del código de flujo ascendente, consulte la twig upstream ( git checkout upstream ), borre todo less el directory .git y copie en la nueva versión ascendente. Use git add -A para organizar todos los cambios en la versión anterior, confirmarla y labelrla.

 [wordpress-1.0] | [wordpress-1.1] vv *--* <- upstream \ +--*--*--* <- master 

Ahora, echa un vistazo a master , y combina tus cambios upstream. En este punto, puede elegir cómo fusionar, como tomar la nueva versión original, tomar su versión o tomar cambios combinados, tal como lo hace en una combinación normal.

 [wordpress-1.0] | [wordpress-1.1] vv *--*--------+ <- upstream \ \ +--*--*--*--* <- master 

Por lo tanto, todos sus cambios ocurren en el master , y todas las versiones anteriores se comprometen exactamente igual que upstream . Esto le permitirá ver con más facilidad exactamente cómo difiere su código de la versión original, le ayudará a realizar un seguimiento de los cambios que ya ha fusionado con la versión original, y así sucesivamente.

 [wordpress-1.0] | [wordpress-1.1] | | [wordpress-2.0] vvv *--*--------+--*-+ <- upstream \ \ \ +--*--*--*--*----*--* <- master 

Espero que esto ayude, avíseme si tiene más preguntas.