Share
Si tiene un complemento alojado en el repositorio de WordPress, entonces estará bastante familiarizado con SVN y algunos de sus comandos. En este tutorial, te mostraré cómo puedes usar Git, otro sistema de control de versiones popularizado por GitHub, para publicar y mantener tu complemento..
Git y SVN son ejemplos de sistemas de control de versiones. El repositorio de WordPress usa este último (si tiene un complemento alojado en WordPress, estará familiarizado con el 'registro' para realizar cambios en este repositorio). Ambos te permiten hacer un seguimiento de los cambios en tu código, pero hay grandes diferencias entre ellos sobre cómo lo hacen..
SVN se basa en un único "repositorio central" del código (en nuestro contexto: el repositorio de complementos de WordPress). Cada vez que desee editar su complemento, debe hacer una copia local, hacer los cambios y luego 'registrar' estos cambios en el repositorio de WordPress.
Git es un sistema de control de versiones descentralizado. En lugar de tener solo una copia local de su complemento, tiene un clon completo de su repositorio de complementos, completo con todos sus cambios. El repositorio ahora existe por derecho propio en su computadora. Puede confirmar y hacer un seguimiento de los cambios, revertir los cambios o "derivar" su plug-in en diferentes direcciones, todo en su computadora local. Solo una vez que esté contento de actualizar su complemento, puede enviar sus cambios a su repositorio de WordPress para hacerlos públicos.
En este tutorial, asumo que tiene un complemento alojado en el repositorio de complementos de WordPress, o al menos ha aprobado su solicitud de alojamiento. Si no está seguro de cómo WordPress puede alojar su complemento, le sugiero que lea nuestro artículo sobre cómo publicar en el repositorio de complementos de WordPress..
Existen numerosos argumentos a favor y en contra del uso de Git sobre SVN (así como los sistemas de control de versiones descentralizados en general). Muchos de estos se derivan de las formas fundamentalmente diferentes en que Git y SVN rastrean los cambios. Se puede encontrar un excelente análisis en profundidad de Git y SVN en el artículo Git vs SVN de CodeForest, pero para el desarrollador de WordPress:
Una de las desventajas de usar Git, es lograr que funcione bien con un repositorio SVN. En realidad no es tan difícil gracias a git svn, Y este artículo está aquí para guiarte a través de él..
Si aún no lo has hecho, querrás instalar Git. La forma de instalar Git se cubre bastante bien en el libro Git Community y en el libro Pro Git (ambos excelente recursos si eres nuevo en Git). La instalación de Git dependerá de su sistema operativo, al igual que los programas GUI disponibles para usted. En este tutorial, haré todo a través de la línea de comandos, y te animo a que hagas lo mismo. Al final del artículo, sugeriré algunos programas GUI que puedes usar, pero generalmente, solo los uso para ayudar a visualizar las ramas del repositorio..
Como se mencionó anteriormente, con Git no 'verifica' una copia de su plug-in: clona el repositorio, completo con un historial de los cambios realizados, y todas sus ramas y etiquetas. El paso 1 luego es clonar el repositorio alojado de WordPress de su complemento. Como ejemplo, voy a publicar un complemento de "Enlace de archivos de tipo de publicación" basado en un tutorial anterior. Entonces (una vez que haya sido aceptado en el repositorio de WordPress) abra su interfaz de línea de comandos y navegue hasta donde desee almacenar la versión local de su complemento. Voy a ponerlo dentro de una carpeta llamada 'Complementos'. Una vez allí, queremos decirle a Git dónde encontrar nuestro complemento. Al momento de escribir este documento, hay casi 20,000 complementos alojados en el repositorio de WordPress, y más de 500,000 revisiones. No queremos esperar a que Git rastree cada uno de ellos para encontrar nuestro complemento. Entonces, en primer lugar, encontramos en qué revisión comienza nuestro complemento (queremos que sea todo su historial). Para hacer esto, obtenemos el primer registro de su complemento (cuando se agregó originalmente al repositorio):
svn log -r 1: HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name
Pensará por un tiempo y luego deberías ver algo como esto:
r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (lunes, 19 de marzo de 2012) | 1 linea
Ese primer número, '520657' para mi complemento, es la primera revisión. Lo usaremos en el siguiente comando que le dice a Git que clone la historia de nuestro complemento. Reemplace XXXXXX con su número de revisión.
git svn clone -s -rXXXXXX --no-minimizar-url http://plugins.svn.wordpress.org/your-plug-in-name cd su nombre de complemento git svn fetch git svn rebase
Los '-s'le dice a Git que espere el diseño estándar (Etiqueta, Tronco, Ramas) de un repositorio SVN. Los '--no-minimizar-url'deja de mirar fuera de su carpeta de plug-in. Asegúrate de que no falte. Si lo deja fuera, podría terminar copiando todo el repositorio de complementos de WordPress. los -rXXXXXX le dice a Git qué revisión buscar. Si deja eso fuera, Git tendrá que buscar en todo el historial del repositorio. Eso es más de 500,000 revisiones. Dejé esto fuera una vez y me tomó cerca de dos horas. Con ello, solo debe llevar unos minutos..
Una vez hecho esto, deberías encontrar que ha creado una carpeta llamada 'su nombre de plug-in'dentro de su carpeta' Complementos '. Vamos a explorar un poco. Navegue a la 'su nombre de plug-in'carpeta y ejecute un comando para ver qué' ramas 'existen:
rama git -a
Esto mostrará una lista de todas las sucursales, locales y remotas. La única rama local debe ser Master (el asterisco indica que esta es la rama en la que se encuentra). Las otras ramas son el 'troncal' y, si tiene alguna, una rama para cada etiqueta (SVN trata las etiquetas como ramas, pero Git es un poco más inteligente que eso).
Ir a tu 'carpeta local', 'plugins / nombre de tu plugin', deberías ver tus archivos de plug-in (si hubiera alguno). Antes de crear o editar cualquier archivo allí, vamos a crear una rama separada para trabajar.
Actualizar: Los comandos anteriores se han actualizado debido a un problema señalado en los comentarios a continuación por Neerav y John Eckman. El código de arriba ahora refleja la recomendación de Stephen Harris.
Una de las ventajas de usar Git es que puede mantener fácilmente una versión de su complemento en GitHub. Esto hace que su complemento sea más accesible para otros desarrolladores, que pueden sugerir mejoras o incluso realizar sus propias modificaciones, las cuales podría incluir en su propio repositorio. Si ya está configurado con GitHub, es posible que en este momento desee insertar su complemento en su cuenta. Para hacer eso, primero create un nuevo repositorio en tu cuenta de GitHub, y luego agrega esto como una rama remota a tu repositorio local:
git remoto agregar origen [email protected]:/ .git
'su nombre de usuario'se refiere a su nombre de usuario de GitHub y'tu nombre de repo'se refiere al nombre del repositorio que ha creado en GitHub. Luego simplemente presionas tu repositorio local:
git push master master
Vamos a crear una nueva rama 'trabajo'. Es dentro de esta rama que alteraremos nuestro complemento, haremos cambios y agregaremos características, etc. Esto significa que nuestra rama 'Maestra' se mantiene en su estado original. Esto nos permite volver a la rama maestra y volver a derivar. En particular, suponga que se encuentra un error importante en su plug-in mientras está trabajando en algunas características nuevas en su rama de "trabajo". Puede volver a su rama "maestra" (que no incluye ninguna de las funciones en las que está trabajando actualmente), cometer una solución para el error y luego enviarla al repositorio de WordPress. Luego puede volver a la rama de trabajo y continuar donde lo dejó. (Nota: Git no crea copias de sus archivos: siempre habrá un solo conjunto de archivos en su carpeta local. El contenido de estos archivos dependerá de la rama en la que se encuentre.)
De hecho, es una buena idea crear una rama para cada nueva función que esté agregando a su complemento. Cuando haya terminado, simplemente fusione estos de nuevo en la rama maestra. Si esto causa algún "conflicto", se le pedirá que lo resuelva manualmente.
Primero crea una rama llamada 'trabajo':
git rama de trabajo
Luego 'echa un vistazo' (ir a) rama 'trabajo':
git checkout work
Un mensaje le dirá que ha cambiado a la rama 'trabajo'. Ahora use su editor de texto favorito para abrir los archivos de su plug-in en su carpeta local (o créelos si aún no los hay). Una vez que haya hecho algunos, es posible que desee ver qué archivos ha cambiado. Haces esto con el simple comando:
estado de git
Esto listará los cambios de rastreado y sin seguimiento archivos. Es posible que haya archivos que no desea que Git moleste en el seguimiento (como los archivos temporales), pero si ha agregado algún archivo nuevo a la carpeta, deberá indicarle a Git que los rastree. Puedes hacer esto con el comando:
git añadir
He creado dos archivos 'post-type-archive-links.php'y'metabox.js'en mi carpeta local, así que los agregué para decirle a Git que los rastree. Debe asegurarse de que está siguiendo su readme expediente.
También puede ver los cambios desde su último compromiso (aquí es donde un programa GUI se vuelve muy útil)
git diff
Una vez que quiera confirmar los cambios en su repositorio local:
git commit -a -m "Hizo abc a xyz"
proporcionando undetallado) Mensaje de los cambios contenidos en la confirmación..
En el proceso de hacer cambios, puede (y debería) comprometerse con la mayor frecuencia posible, pero de una manera lógica, preferiblemente con un compromiso para cada "cosa" que haga. Debe asegurarse de que tampoco haya errores obvios en sus confirmaciones. "Deshacer" un compromiso es rápido e indoloro: haga esto realizando otro compromiso que invierta el anterior:
git revertir HEAD
(Se le solicitará un mensaje para describir este compromiso).
Supongamos que ahora se encuentra en una posición en la que desea enviar todos sus cambios al repositorio de SVN. Antes de hacer esto, necesitamos tener algo en mente. Git lo alienta a comprometerse con frecuencia, y es una buena práctica hacerlo ... para desarrollo. Sin embargo, su repositorio de plugins de WordPress está ahí para distribución. No necesita que cada uno se comprometa. De hecho, realmente no querer O bien, como advierte Otto (colaborador principal de WordPress):
"Si te atrapo [presionando cada compromiso por separado], te excluiré de WordPress.org. El SVN solo necesita que tu versión de trabajo final esté comprometida, no todo el historial de los cientos de cambios que hiciste usando Git. Aplanar sus cambios en un solo compromiso ".
Para evitar esto, cuando estemos listos para ingresar al repositorio de WordPress, fusionamos todos los compromisos en un solo compromiso. Hay un par de maneras de hacer esto. Combinaremos (y al mismo tiempo aplastaremos) nuestros cambios de nuestra rama de trabajo a nuestra rama principal. Entonces, todos nuestros cambios aparecen es como un compromiso en la rama maestra. Luego, eliminamos la rama de trabajo y empujamos la rama maestra a la troncal SVN de nuestro complemento..
Primero, queremos volver a la rama Master:
git checkout master
Luego, aplastar y fusionar los cambios de rama de trabajo en el maestro:
git merge --squash work
Si se han realizado cambios en la rama maestra, puede haber conflictos en la fusión. Se le pedirá que resuelva manualmente estos conflictos antes de que se pueda completar la combinación. Una vez fusionados, confirme los cambios (este compromiso contendrá todos los compromisos de nuestra rama de trabajo):
git commit -a -m "Cambios realizados a, b, c, d"
Finalmente, eliminamos la rama de trabajo.
rama de git -D trabajo
Si tiene varias ramas en las que desea fusionarse, puede hacerlo para cada una de ellas. Existen métodos alternativos, que no cubriré, de aplanar su historial (como la reorganización interactiva).
En este punto, podría, si quisiera, enviar sus últimos cambios a su cuenta de GitHub:
git push -u origen maestro
Para ingresar al repositorio de WordPress, primero nos aseguramos de que nuestro repositorio local esté 'actualizado':
git svn rebase
Git luego irá a buscar su repositorio de subversión y fusionará cualquier cambio allí con los cambios que acabamos de hacer. Normalmente, no debería haber ningún cambio en el repositorio de WordPress, por lo que debería ver el mensaje: Actual rama maestro está actualizado.
Ahora podemos empujar nuestros cambios al repositorio de WordPress
git svn dcommit
Git puede pedirte tus credenciales de WordPress.org. Una vez ingresados, sus cambios se confirmarán en el repositorio de WordPress. En breve recibirá un correo electrónico del repositorio de WordPress, informándole de las confirmaciones..
Actualmente, esos cambios se sentarán en el maletero. ¿Qué pasa si queremos etiquetar una nueva versión de nuestro complemento? Al crear la próxima versión para su complemento, debe haber actualizado el archivo Léame, de modo que la etiqueta estable apunte a su nueva versión (digamos '2.0'). También debería haber actualizado la información del encabezado de su plug-in en su tu-plug-in-nombre.php expediente. Si ha olvidado hacer esto, simplemente ejecute el procedimiento anterior, después de haber realizado esos cambios..
Una vez que su 'troncal' esté completamente actualizado (incluida la información de la última versión), simplemente necesitamos crear la nueva etiqueta en el repositorio de WordPress:
git svn etiqueta "2.0"
Esto copia todo en tu baul en etiquetas / 2.0 (Lo que normalmente logras en SVN con svn cp etiquetas de tronco / 2.0).
Si desea etiquetar el lanzamiento en su repositorio local:
git tag -a 2.0 -m "Etiquetado 2.0"
De forma similar a lo que hicimos con el repositorio de WordPress, asegúrese de que nuestros repositorios estén de acuerdo, luego presione nuestros cambios y etiquetas:
git pull - origen de referencia master git push origen master git push origen --tags
Finalmente, hay un par de "hojas de trucos" de Git que pueden ser útiles: aquí y aquí.
Accentsconagua