Git Workflow para mantener actualizado el software de código abierto modificado a medida?

Question

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

Actualmente ofrecemos WordPress a través de un script de instalador. El usuario carga la versión estable más reciente y ejecuta un script PHP del lado del servidor a través de SSH. Este script PHP modifica los permisos de archivo de todos los archivos/carpetas, Agrega/elimina algún código en varios archivos y crea algunos archivos nuevos. Este script de instalación es un acto de equilibrio engorrosa 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. Estoy familiarizado con la ramificación y la fusión, pero no estoy seguro de cómo integrar nuestros cambios anteriores cuando se emite una nueva versión.

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

Answer 1

Sugeriría mantener sus cambios en una rama y rebotar esa rama contra lo último de WordPress cada vez que actualiza. En una línea de tiempo aproximada ...

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

Cuando desee actualizar WordPress, cambie a Master y haga una nueva compromiso con la última Souce (o use GIT-SVN para mantener el maestro en sincronización):

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

Ahora puedes hacer un git rebase master custom Para reproducir sus cambios contra lo último, resolviendo cualquier conflicto en el camino. Tu línea de tiempo se vería así:

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

Actualizar: Para proporcionar un poco de justificación ... 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 "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 comprometerse a través de una rebase. Cualquier conflicto significa que probablemente se rompiera una personalización, por lo que la antigua confirmación de personalización es basura de todos modos, es mejor solucionar el problema en su fuente y mantener limpio el historial actualizado.

Después master se actualiza y custom Es rebajado y empujado, los colaboradores simplemente rebotarían su trabajo en progreso contra lo último.

Esta es solo mi opinión, como una firme Rebase> Fusionar proponente. La belleza de Git es que rara vez hay una respuesta correcta. Simplemente siga ajustándose hasta que encuentre algo que funcione para usted.

Answer 2

Mi enfoque general es tener dos ramas, upstream y master. Crea tu repositorio (que te iniciará en el master rama), consulte la última copia del código ascendente que usa y luego cree el upsteram suceder con git branch upstream. Además, cree una etiqueta que indique qué versión ascendente ha importado, como git tag wordpress-1.0. Por lo general, uso etiquetas livianas para esto (las que no tienen anotaciones, básicamente un puntero a una revisión).

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

Ahora, mientras todavía estás en el master sucursal, copie sus cambios y verifiquelos. Ahora tiene dos ramas, upstream que contiene la fuente prístina aguas arriba, y master que contiene sus cambios, con un historial que muestra qué cambios ha realizado a upstream.

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

Haga todas sus modificaciones en el master rama.

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

Cuando aparezca una nueva versión del código ascendente, consulte su upstream rama (git checkout upstream), limpie todo menos el .git directorio y copia en la nueva versión ascendente. Usar git add -A Para organizar todos los cambios en la versión ascendente, confirmárselo y etiquetarlo.

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

Ahora, mira master, y fusionar en sus cambios aguas arriba. En este punto, puede elegir cómo fusionar, como tomar la nueva versión ascendente, tomar su versión o tomar cambios fusionados, tal como lo hace en una fusión normal.

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

Entonces, todos tus cambios ocurren en master, y todas las versiones aguas arriba se comprometen exactamente como es upstream. Eso le permitirá ver más fácilmente cómo su código difiere de la versión aguas arriba, ayudará a realizar un seguimiento de los cambios que ya se ha fusionado con la versión aguas arriba, y así sucesivamente.

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

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