¿Cómo comenzar con Subversion, Git o un sistema de control de versiones similar para mantener un historial de mis archivos? [cerrado]

Me doy cuenta de que esta puede ser una pregunta amplia en la superficie, pero estoy buscando ejemplos específicos de configuraciones / flujos de trabajo que las personas usan para mantener un historial de versiones de archivos editados en un sitio de WordPress. Por ejemplo, cuando desarrollo un sitio (e incluso después de que esté activo), a menudo hago cambios en los archivos CSS y PHP, pero no tengo una excelente manera de volver a las versiones anteriores de esos archivos. Para mis propósitos, hacer cambios en una instalación de desarrollo local y luego copiarlos en el sitio en vivo suele ser más problemático de lo que me gustaría. ¿Alguna sugerencia sobre cómo comenzar a usar una herramienta de control de versiones para rastrear ediciones a archivos en un sitio en vivo?

No estoy seguro de cuánto sabes sobre el uso del control de versiones, ¡pero recientemente cambié de SVN a Git y me pareció genial!

Aunque depende de que el servidor de tu sitio en vivo tenga instalado Git (o te lo permitirá). También tengo una configuración de Git en el servidor en vivo, que se ejecuta en una rama llamada algo así production. Cada vez que termino de implementar / arreglar algo localmente, lo combino en la productionrama, luego SSH en el servidor del sitio en vivo y hago los cambios. Es mejor que arrastrar archivos a través de FTP cuando nunca se sabe si está sobrescribiendo cambios, etc.

Recomendaría dedicar un tiempo a familiarizarse con Git (si aún no lo ha hecho), me parece mucho más fácil y menos complicado que SVN cuando se trata de cambiar / agregar cargas de archivos (y a diferencia de SVN, no es estúpido .svncarpetas en todas partes ).

Estoy en una Mac, lo siento si ninguno de estos se aplica, pero uso Coda como editor de código e instalé Git a través de los puertos (usando Porticus).

Si tuviera que configurar todo de nuevo, haría:

1. Instalar Coda

2. Instale Porticus (que requerirá que instale Puertos, pero hay información en esa página)

3. Una vez que haya instalado Porticus, ábralo, busque "git-core" e instálelo.

4. Descargue e instale GitX 7-5

5. Hay una buena guía sobre cómo configurar un repositorio git aquí , pero por lo que es básico: 1. Abrir terminal. 2. cda donde desea que resida su sitio. $: mkdir mysite && cd mysite3. $: git inity eso es todo! Si agrega archivos a esta carpeta, continúe con el siguiente paso

6. Una vez que haya configurado un repositorio GIT localmente (artículo anterior), si abre ese directorio en GitX, podrá confirmar cosas, etc.

Configurarlo todo en el servidor puede ser un poco complicado, tengo un MediaTemple y una cuenta Dreamhost que tienen GIT listo para usar. El enlace en el paso 5 le dice cómo agregar un repositorio remoto, por lo que no tiene que hacerlo hasta que desee incluir su sitio en vivo en la ecuación. Recomendaría que todo funcione localmente primero (a diferencia de SVN, GIT no requiere un repositorio remoto, por lo que puede hacer todo en su máquina por el momento).

Uso SVN para el control de versiones con todo lo que hago en el desarrollo de WordPress. De hecho, comencé de esta manera porque necesitaba SVN para el desarrollo de complementos ... una vez que comencé allí, era una extensión natural continuar usando SVN para temas y scripts personalizados en sitios de clientes.

Complementos

Dado que los complementos ya están alojados en el servidor de WordPress, solo reviso un complemento directamente en el /wp-content/plugins/directorio de mi instalación local de WordPress (ejecuto WAMP en mi cuadro de desarrollo). Luego hago cambios en mi copia local y, cuando está listo para el showtime, me comprometo con el repositorio. Es un proceso sencillo allí, sin carga / descarga y verificación instantánea de que mis cambios funcionaron.

Temas

Los temas son un poco diferentes, particularmente cuando se construye para un cliente. Creo un repositorio local (tengo una Rpartición en mi disco duro específicamente para este propósito) y reviso el repositorio vacío directamente en mi /wp-content/themesdirectorio. Luego hago los cambios necesarios y los desarrollo hasta que estén listos, y realizo revisiones a medida que avanzo.

Cuando estoy listo para publicar el tema en el servidor de producción de un cliente, exporto el repositorio, lo comprimo y uso los Temas nativos >> Agregar nueva funcionalidad dentro de WordPress. Esto también funciona con complementos personalizados (que no están alojados por WordPress).

Herramientas

Como dije, uso WAMP en mi máquina local para ejecutar una instalación de desarrollo de WordPress. Funciona perfectamente en mi caja y me permite ejecutar tantas instancias de WordPress como necesite para un proyecto en particular.

Para SVN, uso Tortoise SVN . Es gratis, notablemente fácil de usar, y se integra con la estructura de archivos y comandos de Windows. Actualizar, confirmar y exportar son simples operaciones de comando con el botón derecho del mouse, seleccionar. El uso de "Exportar" le permite enviar la carpeta completa (sin las .svncarpetas molestas ) directamente a cualquier ubicación de su elección. Con frecuencia exporto al escritorio. Comprimir la carpeta también es una operación de clic derecho, y WordPress maneja la carga.

La transferencia manual de archivos puede ser una molestia, especialmente si sigue cambiando un archivo pero no todos. Si, en cambio, utiliza FTP en todo el directorio con "sobrescribir todo" seleccionado, es mucho más fácil reemplazar los archivos antiguos (y no tiene que realizar un seguimiento de los cambios y los que no). Es como la antigua instalación de WordPress de 5 minutos que solía tener: simplemente reemplace todo con la nueva versión.

Personalmente, creo que es un ejercicio divertido instalar SVN / GIT y administrarlo, pero si puede pagar $ 15 por mes, Beanstalk vale cada centavo. Administran todo el servidor por ti. http://beanstalkapp.com/ Las herramientas de implementación de FTP son increíbles. El mío implementa automáticamente la versión en mi servidor de ensayo cuando me comprometo, por ejemplo

Otra forma de obtener algunas versiones de archivos personales es usar el cuadro desplegable. Cada vez que guarda un archivo en su Dropbox, realiza un seguimiento de la versión, y puede restaurar a cualquier versión anterior más adelante. Usted y otro desarrollador o grupo pueden compartir una carpeta de buzón. De acuerdo, esto no hace troncales, fusiones, etc., pero hace que sea muy fácil para un equipo distribuido trabajar en un sitio web. Simplemente no puede trabajar exactamente en los mismos archivos a la vez.

Mantenemos nuestra copia de trabajo SVN en Dropbox, luego confirmo los archivos cuando es el momento de escribir. Mis diseñadores no enviarán archivos ni tratarán con SVN, así que este es el tamaño comprimido.

Prefiero SVN porque no necesito todos los enlaces troncales para los que GIT es tan bueno y hay mejores herramientas GUI disponibles de SVN.

Aptana me gusta mucho, tiene subversión integrada y puedes conectarte a tu servidor con ftp / sftp fácilmente y subir archivos, otra gran característica que tiene es que si creas un nuevo proyecto php e incluyes el "todo" WordPress carpeta (con wp-admin, wp-includes) obtiene la finalización del código en sus archivos de tema.

En mi configuración, el repositorio es local.

Usted pregunta "pero estoy buscando ejemplos específicos de configuraciones / flujos de trabajo que la gente usa para mantener un historial de versiones de archivos editados en un sitio de WordPress", pero también menciona productos :)

Puede obtener una lista de herramientas y algunas prácticas recomendadas, pero me centraré aquí en los flujos de trabajo: NO SON ESPECÍFICAS DE WORDPRESS:

Pero para los ejemplos generales / configuraciones / flujos de trabajo:

Para empezar: hay patrones CM, tan independientes de las herramientas. Google en CM Patterns, muchos libros, incluso comunidades de wiki, por ejemplo, http://www.cmcrossroads.com/forums .

También hay guías sobre cómo configurar una estrategia de transmisión válida (estrategia de transmisión de Google), etc.

No creo que haya nada especial sobre las implementaciones de WordPress en comparación con CM Management, incluido el desarrollo paralelo distribuido en grandes fábricas de Siebel, SAP, Informatica, Java, etc. Realmente es casi por defecto.

Lo que falta, creo, es que nadie ha escrito un CMplan para el desarrollo de WordPress (todavía) (IEEE). Una vez que alguien ha hecho eso (herramienta independiente). Los requisitos se pueden completar, creo, con cualquier herramienta.

Creo que la razón por la que el plan no se ha escrito es que casi todas las implementaciones de WordPress todavía son realizadas por 1 persona con una configuración simple de desarrollo y producción, por lo que no con múltiples desarrolladores / diseñadores en la fase de construcción que tienen que implementar diferentes versiones que se ejecutan en el entorno de prueba, por ejemplo.

El plan CMP comienza con la identificación de todos los CI en otras palabras: haga una lista de todos los tipos de CI presentes en una implementación de WordPress, incluidas las aplicaciones, complementos, bases de datos, documentación, ayuda, contenido, archivos de configuración, notas de lanzamiento (!), etc. ..). Este es un buen comienzo. Luego, decida cuáles quiere traer bajo CM.

Luego, decida qué causa los cambios en estos CI, por ejemplo, una llamada del cliente para una corrección de errores, o una actualización que se necesita. Si se hace bien, esto lleva a una situación en la que tiene la sensación de que las cosas están bajo control.

Decisiones como la fusión de la producción al desarrollo y la forma de manejar eso es parte de ese capítulo (2 patrones principales aquí) (aunque, por supuesto, debe intentar minimizar estas revisiones).

Solo luego busque una herramienta para hacer CM en un lado (que incluye la administración de versiones como una de las herramientas) y herramientas de administración de cambios en el otro lado (lo que lo mantiene cuerdo).

Creo que ese es el mejor flujo de trabajo para empezar, ya que, hasta donde busqué en Google, nadie lo ha hecho todavía. Creo que una vez que la primera persona ha escrito un Plan CM de WordPress (según IEEE), cualquier otra persona de WordPress en el mundo puede copiar ese plan y hacer ajustes e implementar los patrones en sus herramientas.

No es demasiado trabajo / demasiado pesado: depende de si tienes una empresa o no: un día puede ahorrarte mucho tener un buen plan CM.

Estoy en un host compartido, así que no puedo instalar SVN ni nada de eso. Uso Mercurial para control de versiones en mi máquina doméstica. Utilizo la sincronización FTP de Beyond Compare para mantener sincronizadas las carpetas locales y remotas.

Estoy usando git. es simple. solo tiene que comprender comandos simples como clonar, comit, push, pull y está listo para comenzar. Eso es lo básico.

aunque, si usa git it más, como coordinar un equipo para trabajar en un producto, entonces es otro nivel. pero al final valió la pena usar git o cualquier control de versión. hay realiable cuando suceden cosas.