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

Question

Nuestra Universidad proporciona alojamiento web a los departamentos del campus en los servidores que administramos. La instalación de programas de código abierto de terceros requiere modificar los permisos de los archivos y el código en el programa antes de que se ejecute. (Estamos usando suEXEC, si está familiarizado)

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

Quiero comenzar a usar 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 cambios personalizados más antiguos?

Answer 1

Sugeriría mantener sus cambios en una bifurcación, y volver a basar esa rama con lo último de WordPress cada vez que actualice. En una línea de tiempo en bruto ...

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

Cuando desea actualizar WordPress, el interruptor de dominar y hacer un nuevo commit con la última impulsoras (o utilizar git-svn para mantener en sincronía principal):

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

Ahora puede hacer un git rebase master custom para reproducir sus cambios contra los últimos, resolviendo cualquier conflicto en el camino. Su línea de tiempo podría tener el siguiente aspecto:

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

Actualización: Proporcionar un poco de razón ... me gusta este enfoque para este problema, ya que proporciona una clara diferenciación entre el código de WordPress y 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 se actualice master y custom se vuelva a establecer la base y se presione, los colaboradores solo volverían a ajustar su trabajo en progreso a la última.

Esto es solo mi opinión, como un firme rebase> merge proponent. La belleza de Git es que rara vez hay una respuesta correcta. Solo sigue ajustándote hasta que encuentres algo que funcione para ti.

Answer 2

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

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

Ahora, mientras estás todavía en la rama master, copiar sus cambios y de salida en los. Ahora tiene dos ramas, upstream que contiene la fuente prístina aguas arriba, y master que contiene los cambios, con historial que muestra los cambios que ha realizado en upstream.

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

hacer todas sus modificaciones en la rama master.

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

Cuando una nueva versión del código de aguas arriba viene, echa un vistazo a su upstream rama (git checkout upstream), borrar todo excepto el directorio .git, y copia en la nueva versión de aguas arriba. Use git add -A para organizar todos los cambios en la versión anterior, confirmarla y etiquetarla.

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

Ahora, echa un vistazo a master, y se funden en los cambios ascendentes. 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] 
v v 
*--*--------+ <- upstream 
\   \ 
    +--*--*--*--* <- master 

Por lo tanto, todos los cambios ocurren en master, y todas las versiones de aguas arriba están comprometidos exactamente como es 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] 
v v   v 
*--*--------+--*-+ <- upstream 
\   \ \ 
    +--*--*--*--*----*--* <- master 

Espero que esto ayude, hágamelo saber si usted tiene alguna otra pregunta.