Un flujo de trabajo de versiones para múltiples implementaciones similares (pero no idénticas)

Actualmente estoy empleado en una pequeña organización no tecnológica y he tenido la function de codificar el website de la organización. Si bien he disfrutado la tarea y he aprendido mucho con el desarrollador web, he encontrado algunos problemas que espero que alguien pueda ayudarme o al less apuntarme en la dirección correcta.

Un poco de historia:

El sitio en el que trabajo tiene subdominios en los que cada uno tiene su propia installation separada de WordPress, ya que este ha sido el panel de administración "back-end" más fácil para el tipo de usuario que se encargará de actualizar el contenido (etc.).

Dentro de la organización, trabajo bajo el Director de Marketing (MM) y el código de acuerdo con su guía de estilo y frameworks alámbricos.

Si bien hemos estado trabajando con un solo subdominio desde el comienzo del año, el proyecto ha sido relativamente simple y directo. Sin embargo, últimamente el flujo de trabajo se está volviendo un poco más complicado ya que nuestro subdominio original se ha copydo a los otros subdominios. Cada uno de los nuevos subdominios recibe ediciones menores de sus hojas de estilo (por ejemplo, diferentes imágenes para el background, colors ligeramente diferentes aquí y allá, etc.).

La cuestión:

Por el momento, manejar todos los diferentes subdominios ha sido "soportable", pero la gota que está frenando el camello en este momento ha sido las ligeras reversiones que el MM ha requerido ahora que el CEO ha visto el producto final. El problema que tengo con las reversiones en las hojas de estilo es que el CEO declarará una semana que le gusta el cambio "X" y luego como el MM y yo continuaremos modificando el sitio (hasta ahora "Z"), otra semana indicará que él quiere que cambiemos "X" a "W" pero manteniendo la mayoría de los cambios realizados en "Y".

Lo que estoy buscando es algo que permite:

  • cambios en el file de seguimiento
  • revertir los cambios realizados (o volver a 'a' desde 'e' pero incluyendo los cambios 'b' y 'c')
  • Cargue fácilmente los files necesarios en su respectiva installation de tema WP

¿Hay algo por ahí que se acerque a abordar estos problemas? ¿Entonces qué?

¡Gracias por cualquier ayuda!

PD: estoy aprendiendo Git en este momento y parece que hace los "cambios al file de seguimiento" bastante bien. Sin embargo, todavía no hemos aprendido sobre el cambio de reversión. Tal vez para mi último punto estoy pensando en crear un guión de shell para upload automáticamente los files a sus carpetas. ¿Git hace esto también?


Adición (alexbbrown)

Tuve un problema similar: ejecuté una versión personalizada de mediawiki donde instalé varias extensiones en el núcleo versionado (con svn). Cada una de las extensiones requiere una sección en el file confitado, pero el file confit también necesita configuration local para cada una de varias implementaciones. Pude haberlo implementado usando includes, pero no serían versionadas; y cambiar las twigs cada vez es una tarea ardua. +50 puntos de experiencia para una buena respuesta en git.

Git te dejará hacer lo que necesites.

Utilizaría un único repository que contiene cada subdominio como una twig, ya que, según mi experiencia, esto le permitirá mover los cambios entre los subdominios de la manera más fácil.

Asumiré una estructura donde tienes una twig core y varias twigs de subdomainX , cada una con sus propios cambios locales para mantener. También asumiré que tienes una twig de develop en la que haces cambios principales.

Hay varias acciones key que deberá poder hacer:

Has realizado un cambio en el desarrollo que debería ir a todos los subdominios

Tire de los cambios del desarrollo en el núcleo

 git checkout core git merge develop 

Aplicar los cambios a las twigs del subdominio. Para cada subdominio ejecutar

 git checkout subdomainX git rebase core 

o si prefieres fusiona sobre rebases (me parece que este caso se vuelve demasiado complicado, pero otros pueden estar en desacuerdo)

 git checkout subdomainX git merge core 

Si tienes muchas twigs de subdominio, yo escribiría esto. Esto reubicará todas las twigs locales que contienen "subdominio" en su nombre en el core .

 for i in $( git branch | cut -b 3- | grep subdomain ) ; do git checkout $i git rebase core end 

Ha realizado un cambio en un subdominio que desea incorporar a todos los otros subdominios

Primero, necesitará el SHA del cambio que desea aplicar (y verifíquelo si aún no lo ha hecho).

A continuación, obtendrá ese cambio en la twig de desarrollo, y luego en el core

 git checkout develop git cherry-pick THE_SHA_OF_YOUR_CHANGE git checkout core git merge develop 

A continuación, ejecuta el script anterior para enviar el cambio a todas las twigs del subdominio.

Has recibido algunos cambios que deberían deshacerse en todas partes

 git checkout develop git revert THE_BAD_SHA git checkout core git merge develop 

Luego ejecuta el script.

Quieres comparar dos subdominios.

Si las dos twigs se llaman subdomainA y subdomainB , puedes hacer

 git diff subdomainA subdomainB 

Desea ver qué cambios hay en el subdominio A pero no en el core , es decir, los cambios locales.

Los cambios a los files se pueden get por:

 git diff subdomainA core 

La list real de sets de cambios por

 git log core..subdomainA 

Manejo de distribución

Hay dos forms de manejar esto:

  • Haga un pequeño script para copyr los files de cada twig (usaría rsync para evitar copyr files existentes, etc.). La ventaja de esto es que es rápido y no requiere git en el server en el que se está implementando.
  • Haga que cada file de subdominios sea una copy del repository de git. Su secuencia de commands sería ssh a cada cuadro y tire / fusione los files. Una ventaja de esto es que puede realizar cambios en los serveres en vivo y volverlos a su repository fácilmente. Las desventajas incluyen que necesitará configurar un repository bare como origen para todos los repos, y ocupará más espacio. (Sin embargo, las ventajas de IMO en este caso superan las desventajas y es este enfoque el que usaría).

La respuesta de Michael es buena, pero hay otro punto de vista que creo que debería mencionarse: Branch by Abstraction (BBA) en lugar de la tradicional "Branch by Source Control". Creo que debería reorganizar su código fuente para que el código compartido se cree como código compartido explícitamente en lugar de compartirlo mediante combinaciones mágicas / rebases.

Tal vez valga la pena introducir algunos types de scripts de compilation que reorderarán el código y ejecutarán algunas testings para verificar la corrección.

Buena idea para implementar git! Definitivamente es una herramienta indispensable para tener en el process de desarrollo. Como mencionaste, git definitivamente resolverá tu problema de "cambios en el file de seguimiento" y también puede resolver los otros problemas, simplemente hay más de una curva de aprendizaje. Hay muchos resources geniales en git pero si quieres una mejor idea de qué es git (y qué no lo es) y cómo funciona, recomendaría leer Git de abajo hacia arriba .

La reversión de cambios se puede hacer muy fácilmente con git. En primer lugar, es probable que necesites ver tu historial de confirmaciones para encontrar el que deseas revertir. Esto se puede hacer simplemente usando el command git log (asegúrese de estar en un directory rastreado por git). Hay mucha más información sobre eso aquí . Una vez que conozca el compromiso al que desea volver, todo lo que necesita hacer es utilizar el hash asociado con esa confirmación específica y ejecutar el git reset --hard 6e3e02050a donde 6e3e02050a es el hash exclusivo de su commit. Más información, incluidas algunas cosas interesantes que puedes hacer con eso, aquí . Esto revertirá inmediatamente todos sus files rastreados a esa confirmación específica (también puede revertir files individuales).

Créalo o no, git también puede ayudarlo a enviar su código a sus serveres automáticamente cuando lo desee. Esto es un poco más avanzado y aprovecha un post-receive hook . Esto facilita la implementación desde el desarrollo hasta un sitio de producción. Como mencioné, esto es más avanzado, así que no entraré en detalles sobre eso aquí, pero hay un gran tutorial que incluye exactamente lo que desea en wp.tutsplus.com (paso 4 específicamente).

Ahora, todas estas cosas son bastante sencillas para una sola installation, pero se vuelve un poco más complicado cuando tiene muchos sitios conectados al mismo process de desarrollo. De nuevo, git tiene algunas opciones.

Supongo que en este punto es posible que sepa un poco sobre la branching , si no hay muchos resources por ahí. Las twigs le permiten disparar en proyectos exploratorios o incluso completamente separados de su twig principal "maestra". Parece que esto es exactamente lo que quiere con todas sus diferentes instalaciones, todas basadas en el mismo código maestro. Otro beneficio de la bifurcación es que puede mantener sus sucursales actualizadas con cualquier cambio en el maestro, así como fusionarlas de nuevo si así lo desea. Otra opción es la clonación. Esto es diferente en el hecho de que en realidad está copyndo y repository completo, no solo ramificándose de lo que tiene actualmente. Más información sobre eso aquí .

Puede tomar un time encontrar la mejor manera de configurar todo, pero puedo garantizar que una vez que tenga algún tipo de process en su lugar, estará muy contento con las opciones y la tranquilidad que el git puede brindarle.