it-swarm-es.com

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

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, al desarrollar un sitio (e incluso después de que esté activo), a menudo realizo cambios en los archivos CSS y PHP, pero no tengo una gran manera de volver a las versiones anteriores de esos archivos. Para mis propósitos, realizar cambios en una instalación de desarrollo local y luego copiar esos cambios en el sitio activo a menudo es más problemático de lo que me gustaría. ¿Alguna sugerencia sobre cómo comenzar a utilizar una herramienta de control de versiones para realizar un seguimiento de las ediciones en archivos en un sitio en vivo?

31
Travis Northcutt

No estoy seguro de cuánto sabe acerca del uso del control de versiones, pero recientemente cambié de SVN a GIT y ¡encuentro que es genial!

Aunque depende de tu servidor en vivo, el servidor tiene GIT instalado (o te lo permitirá). También tengo una configuración GIT en el servidor en vivo, ejecutando una rama llamada algo como production. Cuando termino de implementar/arreglar algo localmente, lo fusiono en la rama production, luego SSH en el servidor del sitio en vivo y presento los cambios. No es necesario arrastrar archivos a través de FTP cuando nunca se sabe si está sobrescribiendo cambios, etc.

Recomendaría dedicarle un poco de tiempo a tener un GIT (si aún no lo ha hecho), lo encuentro mucho más fácil y menos complicado que SVN cuando se trata de cambiar/agregar un montón de archivos (y, a diferencia de SVN, no es estúpido. carpeta .svn en todas partes ).

Asi que:

Claro, estoy en una Mac, lo siento si no se aplica ninguno de estos.

Editor de código: Coda GIT instalado a través de puertos (usando Porticus) Git: GitX

Si tuviera que configurar todo 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. Descargar e instalar GitX 7-5

  5. Hay una buena guía sobre la configuración de un repositorio git aquí , pero en su versión básica: 1. Abrir Terminal. 2. cd a donde desea que resida su sitio. $: mkdir mysite && cd mysite 3. $: git init y eso es todo! Si agrega archivos a esta carpeta, continúe con el siguiente paso

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

Configurar todo en el servidor puede ser un poco complicado, tengo un MediaTemple y una cuenta de Dreamhost que ambos tienen GIT fuera de la caja. El enlace en 5. le dice cómo agregar un repositorio remoto, no tiene que hacerlo hasta que quiera llevar su sitio en vivo a la ecuación. Yo recomendaría que todo funcione localmente primero (a diferencia de SVN, GIT no requiere un repositorio remoto, por lo que puede bloquear todo en su máquina por el momento)

14
Joe Hoyle

Uso SVN para el control de versiones con todo Lo 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í, fue una extensión natural seguir usando SVN para temas y scripts personalizados en los sitios de los clientes.

Plug-ins

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

Temas

Los temas son un poco diferentes, especialmente cuando se construyen para un cliente. Creo un repositorio local (tengo una partición R en mi disco duro específicamente para este propósito) y reviso el repositorio vacío directamente en mi directorio /wp-content/themes. Luego realizo los cambios necesarios y desarrollo hasta que esté listo, realizando las 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 Zip, y utilizo la función Add Add >> nativa de Themes >>. Esto funciona con complementos personalizados (que no están alojados por WordPress) también.

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, muy fácil de usar y se integra con la estructura de archivos y comandos de Windows. La actualización, la confirmación y la exportación son simples operaciones de comando con clic derecho y selección. El uso de "Exportar" le permite enviar la carpeta completa (sin las molestas carpetas .svn) directamente a cualquier ubicación de su elección; frecuentemente exporto al escritorio. Zipear la carpeta también es una operación de clic derecho, y WordPress se encarga de la carga.

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

8
EAMann

Personalmente, creo que es un ejercicio divertido instalar SVN/GIT y administrarlo, pero si puedes pagar $ 15 por mes, Beanstalk vale cada centavo. Ellos gestionan todo el servidor por ti. http://beanstalkapp.com/ Las herramientas de implementación de FTP son impresionantes. El mío implementa automáticamente la versión en mi servidor de pruebas 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, rastrea 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. Por supuesto, esto no hace trunks, fusiones, etc., pero sí hace que sea muy fácil para un equipo distribuido trabajar en un sitio web. Simplemente no puedes trabajar en los mismos archivos a la vez.

Mantenemos nuestra copia de trabajo SVN en Dropbox, luego confirmo los archivos cuando se escribe el tiempo. Mis diseñadores no enviarán archivos ni se ocuparán de SVN, así que esta es la solución.

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

3
Andrew

Me gusta Aptana mucho, tiene Subversion integrado y puede conectarse a su servidor con ftp/sftp fácilmente y subir archivos, otra gran característica que tiene es que si crea un nuevo proyecto php e incluye La carpeta "completa" de WordPress (con wp-admin, wp-includes) le permite completar el código en sus archivos de temas.

En mi configuración el repositorio es local.

2
Amit

Pides "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 mencionas productos :)

Obtiene una respuesta en la lista de herramientas y algunas de las mejores prácticas, pero me centraré aquí en los flujos de trabajo: NO SON ESPECIALES DE WORDPRESS:

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

Para empezar: HAY patrones CM, muy independientes de las herramientas. Google en CM Patterns, una gran cantidad de libros por ahí, 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 en 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. Es realmente 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 haya hecho eso (herramienta independiente). Los requisitos se pueden completar, creo, con cualquier herramienta.

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

el plan de 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 la versión (!), etc. ..). Este es un buen comienzo. Luego decide cuáles quieres incluir en CM.

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

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

Solo más tarde busque una herramienta para hacer CM en un lado (que incluye la administración de versiones como una de las herramientas) y el cambio de herramientas de administración en el otro lado (que lo mantiene sano).

Creo que ese es el mejor flujo de trabajo para comenzar ya que, en lo que respecta a Google, nadie lo ha hecho todavía. Creo que una vez que la primera persona ha escrito un Plan de WordPress CM (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 tiene una empresa o no: puede ahorrarle un gran esfuerzo algún día para tener un buen plan de CM.

1
edelwater

Estoy en un host compartido, así que no puedo instalar SVN ni nada de eso. Utilizo Mercurial para el 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.

0
CAD bloke

estoy usando git. es sencillo. solo tiene que entender un comando simple como clonar, comit, Push, pull y ya 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 verdaderas cuando suceden cosas.

0
justjoe