Publicar los complementos de WordPress con Git

Si tienes un complemento alojado en el repositorio de WordPress, estarás 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.

¿Qué es Git?

Git y SVN son ejemplos de sistemas de control de versiones. El repositorio de WordPress utiliza este último (si tienes un complemento alojado en WordPress, estarás familiarizado con el 'registro' para realizar cambios en este repositorio). Ambos te permiten realizar un seguimiento de los cambios en tu código, pero existen 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 desees editar tu complemento, debes hacer una copia local, realizar 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 tu complemento, tienes un clon completo de tu repositorio de complementos, completo con todos sus cambios. El repositorio ahora existe por derecho propio en tu computador. Puedes confirmar y realizar un seguimiento de los cambios, revertir los cambios o "ramificar" tu complemento en diferentes direcciones, todo en tu computador local. Solo una vez que estés feliz de actualizar tu complemento, enviarás los cambios a tu repositorio de WordPress para hacerlos públicos.

En este tutorial, supongo que tienes un complemento alojado en el repositorio de complementos de WordPress, o al menos ha aprobado tu solicitud de alojamiento. Si no estás seguro de cómo obtener tu complemento alojado en WordPress, te sugiero que leas nuestro artículo sobre cómo publicar en el repositorio de complementos de WordPress.

¿Cuáles son las ventajas de usar Git antes que SVN?

Existen numerosos argumentos a favor y en contra del uso de Git antes que SVN (así como 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 análisis excelente y en profundidad de Git y SVN en el artículo Git vs SVN de CodeForest, pero para el desarrollador de WordPress:

• Acceso sin conexión: Puedes realizar y rastrear las confirmaciones en tu propio 'repositorio de desarrollo' personal. Solo cuando desees hacer públicos tus cambios, necesitarás acceder al repositorio de WordPress.
• Una vez que lo aprendas, Git es mucho más fácil de usar: este artículo te guiará a través del flujo de trabajo básico que necesitarás para realizar cambios y actualizarlos en el repositorio. He vinculado algunos recursos en la parte inferior que brindan información más detallada sobre el uso de Git.
• GitHub: Seamos realistas, así es como la mayoría de nosotros hemos oído hablar de Git. Su capacidad para fomentar la 'codificación social' es posible gracias a la naturaleza descentralizada de Git. Puedes guardar una copia de tu complemento en GitHub, animando a la comunidad a participar y realizar mejoras o extensiones que luego puedes incluir. En términos generales, es una buena idea exponer tu complemento a otros desarrolladores.
• Fácil 'bifurcación' de tu complemento: Puedes crear bifurcaciones 'experimentales' en tu copia local para probar posibles nuevas funciones, luego, si funcionan, vuelve a fusionarlas cuando sea el momento de publicar la próxima versión de tu complemento .

Una desventaja de usar Git es hacer 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.

Paso 1 Decargar Git

Si aún no lo has hecho, querrás instalar Git. Cómo instalar Git se explica bastante bien en el libro Git Community y el libro Pro Git (ambos recursos excelentes si eres nuevo en Git). La forma de instalar Git dependerá de tu sistema operativo, al igual que los programas de GUI disponibles para ti. 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 por lo general, solo los uso para ayudar a visualizar las ramas del repositorio.

Paso 2 Clona el repositorio alojado en WordPress de tu complemento

Como se mencionó anteriormente, con Git no 'extraes' una copia de tu complemento: clonas el repositorio, completo con un historial de los cambios realizados y todas sus ramas y etiquetas. El paso 1 es clonar el repositorio alojado de WordPress de tu complemento. Como ejemplo, publicaré un complemento llamado 'Post Type Archives Link' basado en un tutorial anterior. Entonces (una vez que hayas sido aceptado en el repositorio de WordPress) abre tu interfaz de línea de comandos y navega hasta donde deseas almacenar la versión local de tu complemento. Lo pondré dentro de una carpeta llamada 'Plugins'. Una vez allí, queremos decirle a Git dónde encontrar nuestro complemento. En el momento de redactar este artículo, hay casi 20.000 complementos alojados en el repositorio de WordPress y más de 500.000 revisiones. No queremos esperar a que Git revise cada uno de ellos para encontrar nuestro complemento. Entonces, en primer lugar, encontramos en qué revisión comienza nuestro complemento (queremos que sea todo el historial). Para hacer esto, obtenemos el primer registro de tu complemento (cuando se agregó originalmente al repositorio):

1

svn log -r 1:HEAD --limit 1 http://plugins.svn.wordpress.org/your-plug-in-name

Esto pensará por un tiempo y luego deberías ver algo como esto:

1

r520657 | plugin-master | 2012-03-19 03:56:31 +0000 (Mon, 19 Mar 2012) | 1 line

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 el historial de nuestro complemento. Reemplaza XXXXXX con tu número de revisión.

1

git svn clone -s -rXXXXXX --no-minimize-url http://plugins.svn.wordpress.org/your-plug-in-name

2

cd your-plugin-name

3

git svn fetch

4

git svn rebase

La '-s' le dice a Git que espere el diseño estándar (Etiqueta, Troncal, Ramas) de un repositorio SVN. El '--no-minimize-url' evita que busque fuera de la carpeta de complementos (o plugins en mi caso). Asegúrate de que no falte. Si lo omites, podrías terminar copiando todo el repositorio de complementos de WordPress. -rXXXXXX le dice a Git qué revisión buscar. Si omites eso, 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 llevó unas dos horas. Con él dentro, solo debería tomar unos minutos.

Una vez hecho esto, deberías encontrar que se creó una carpeta llamada 'nombre-de-tu-complemento' dentro de tu carpeta 'Plugins'. Exploremos un poco. Navega a la carpeta 'nombre-de-tu-complemento' y ejecuta un comando para ver qué 'ramas' existen:

1

git branch -a

Esto mostrará una lista de todas las ramas, 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 'tronco' y, si tienes alguna, una rama para cada etiqueta (SVN trata las etiquetas como ramas, pero Git es un poco más inteligente que eso).

Al ir a tu 'carpeta local', 'plugins/nombre-de-tu-complemento', deberías ver los archivos de tu complemento (en caso de que haya). Antes de crear o editar archivos allí, vamos a crear una rama separada para trabajar.

Actualización: Los comandos anteriores se han actualizado debido a un problema observado en los comentarios a continuación por Neerav y John Eckman. El código anterior ahora refleja la recomendación de Stephen Harris.

Paso 3 (opcional) Enviar a GitHub

Uno de los beneficios de usar Git es que puedes mantener fácilmente una versión de tu complemento en GitHub. Esto hace que tu complemento sea más accesible para otros desarrolladores, quienes pueden sugerir mejoras o incluso realizar tus propias modificaciones que tú podrías incorporar a tu propio repositorio. Si ya has terminado con GitHub, es posible que en este momento desees insertar tu complemento en tu cuenta. Para hacer eso, primero crea tú mismo un nuevo repositorio en tu cuenta de GitHub y luego agrega esto como una rama remota a tu repositorio local:

1

git remote add origin git@github.com:<your-user-name>/<your-repo-name>.git

'your-user-name' se refiere a tu nombre de usuario de GitHub y 'your-repo-name' se refiere al nombre del repositorio que has creado en GitHub. Entonces simplemente empuja tu repositorio local:

1

git push origin master

Paso 4 Editando tu complemento: Esquema del flujo de trabajo

Crearemos una nueva rama llamada 'work'. Es dentro de esta rama donde modificaremos nuestro complemento, realizaremos cambios y agregaremos funciones, etc. Esto significa que nuestra rama 'Master' se mantiene en su estado original. Esto nos permite volver a la rama Master y volver a ramificarnos. En particular, debes suponer que te encuentras un error importante en tu complemento mientras estás trabajando en algunas características nuevas en tu rama 'work'. Puedes volver a tu rama 'master' (que no incluye ninguna de las funciones en las que estás trabajando actualmente), enviar una solución para el error y luego enviarla al repositorio de WordPress. Luego puedes volver a tu rama 'work' y continuar donde la dejaste. (Nota: Git no crea copias de tus archivos; siempre habrá un solo conjunto de archivos en tu carpeta local. El contenido de estos archivos dependerá de la rama en la que te encuentres).

De hecho, es una buena idea crear una rama para cada característica nueva que agregues a tu complemento. Cuando hayas terminado, simplemente vuelve a fusionarlos en la rama maestra. Si esto causa algún "conflicto", se te pedirá que lo resuelvas manualmente.

Primero crea una rama llamada 'work':

1

git branch work

Luego 'echa un vistazo' (ve a) la rama 'work':

1

git checkout work

Un mensaje te dirá que has cambiado a la rama 'work'. Ahora usa tu editor de texto favorito para abrir los archivos de tu complemento en tu carpeta local (o créalos si aún no hay). Una vez que hayas creado algunos, es posible que desees ver qué archivos han cambiado. Haz esto con el simple comando:

1

git status

Esto mostrará una lista de cambios de archivos rastreados y no rastreados. Puede haber archivos que no deseas que Git se moleste en rastrear (como archivos temporales), pero si has agregado archivos nuevos a la carpeta, deberás decirle a Git que los rastree. Puedes hacer esto con el comando:

1

git add <file-name>

Creé 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. Debes asegurarte de realizar un seguimiento de tu archivo readme.

También puedes ver los cambios desde tu última confirmación (aquí es donde un programa GUI se vuelve muy útil)

1

git diff

Una vez que desees confirmar los cambios en tu repositorio local:

1

git commit -a -m "Did abc to xyz"

proporcionando un mensaje (detallado) de los cambios contenidos en la confirmación.

En el proceso de realizar cambios, puedes (y debes) adjuntar un 'commit' con la mayor frecuencia posible, pero de una manera lógica, preferiblemente con un compromiso por cada "cosa" que hagas. Debes asegurarte de que tampoco haya errores obvios en tus confirmaciones. 'Deshacer' una confirmación es rápido e indoloro: Para ello, realiza otra confirmación que invierta la anterior:

1

git revert HEAD

(Se te pedirá un mensaje para describir esta confirmación).

Paso 5 Enviar los cambios al repositorio de WordPress

Supongamos que ahora te encuentras en una posición en la que deseas enviar todos tus cambios al repositorio SVN. Antes de hacer esto, debemos tener algo en mente. Git te anima a enviar un commit con frecuencia y es una buena práctica hacerlo... para el desarrollo. Sin embargo, tu repositorio de complementos de WordPress está ahí para su distribución. No necesitas todos los commits. De hecho, tampoco lo quieres, como advierte Otto (colaborador principal de WordPress):

"Si te descubro [enviando cada cambio por separado], te prohibiré en WordPress.org. El SVN solo necesita tu versión final de trabajo del commit con él, no el historial completo de los cientos de cambios que realizaste con Git. Acopla tus cambios a un único commit".

Para evitar esto, cuando estemos listos para enviar al repositorio de WordPress, fusionamos todos los cambios en un commit. Hay un par de formas de hacer esto. Fusionaremos (y simultáneamente enviaremos) nuestros cambios de nuestra rama 'work' en nuestra rama master. Luego, todos nuestros cambios aparecen como un commit en la rama master. Luego eliminamos la rama 'work' y enviamos la rama master al tronco SVN de nuestro complemento.

Primero, queremos volver a la rama Master:

1

git checkout master

Luego aplasta y fusiona los cambios de la rama de trabajo en master:

1

git merge --squash work

Si se han realizado cambios en la rama maestra, es posible que haya conflictos en la fusión. Se te pedirá que resuelvas manualmente estos conflictos antes de que se complete la fusión. Una vez fusionado, confirma los cambios (este commit contendrá todos los commits de nuestra rama 'work'):

1

git commit -a -m "Made changes a,b,c,d"

Finalmente, eliminamos la rama 'work'.

1

git branch -D work

Si tienes varias ramas que deseas fusionar, puedes hacer esto para cada una de ellas. Hay métodos alternativos, que no cubriré, para aplanar tu historial (como el rebase interactivo).

En este punto, si quisieras, podrías enviar tus últimos cambios a tu cuenta de GitHub:

1

git push -u origin master

Para enviarlo al repositorio de WordPress, primero nos aseguramos de que nuestro repositorio local esté 'actualizado':

1

git svn rebase

Luego, Git irá a buscar tu repositorio de subversión y fusionará los cambios allí con los cambios que acabamos de realizar. Normalmente, no debería haber ningún cambio en el repositorio de WordPress, por lo que deberías ver el mensaje: La rama master está actualizada.

Ahora podemos enviar nuestros cambios al repositorio de WordPress.

1

git svn dcommit

Por lo tanto, Git puede solicitarte tus credenciales de WordPress.org. Una vez ingresados, tus cambios se enviarán al repositorio de WordPress. En breve deberías recibir un correo electrónico del repositorio de WordPress, informándote de las confirmaciones.

Paso 6 Etiquetando una nueva versión

Actualmente, esos cambios se asentarán en el tronco. ¿Qué pasa si queremos etiquetar una nueva versión de nuestro complemento? Al crear la próxima versión para tu complemento, deberías haber actualizado el archivo Léame o Readme, de modo que la etiqueta estable apunte a tu nueva versión (que diga '2.0'). También deberías haber actualizado la información del encabezado de tu complemento en tu archivo nombre-de-tu-complemento.php. Si olvidaste hacer esto, simplemente ejecuta el procedimiento anterior, después de haber realizado esos cambios.

Una vez que tu 'tronco' esté completamente actualizado (incluida la información de la última versión), simplemente necesitamos crear la nueva etiqueta en el repositorio de WordPress:

1

git svn tag "2.0"

Esto copia todo en tu tronco en tags/2.0 (lo que normalmente logras en SVN con svn cp trunk tags/2.0).

Si deseas etiquetar la versión en tu repositorio local:

1

git tag -a 2.0 -m"Tagging 2.0"

Paso 7 (opcional) Etiquetando una nueva versión en GitHub

De manera similar a lo que hicimos con el repositorio de WordPress, asegúrate de que nuestros repositorios estén de acuerdo, luego presiona nuestros cambios y etiquetas:

1

git pull --rebase origin master 

2

git push origin master 

3

git push origin --tags

Recursos útiles para los comandos de Git

• Referencia de Git (tiene una buena sección sobre 'Cómo pensar como Git')
• Libro de la comunidad de Git
• Libro para ser Pro en Git
• Git listo (menos de una guía, más una colección de 'fragmentos')
• Curso intensivo de SVN a Git (útil si has usado SVN por un tiempo)
• Git mágico (una introducción amistosa a Git)

Por último, hay un par de 'hojas de trucos' de Git que pueden ser útiles: aquí y aquí.

Programas GUI de Git

Windows

• TortoiseGit (un programa popular que se integra bien con el Explorador de Windows)
• msysgit

Mac

• Git Tower
• GitHub para Mac (de aquellos que te trajeron GitHub)

Linux / Multiplataforma

• GitG (esto es lo que uso)
• QGit
• Git Cola (multiplataforma)