Usa Git tanto si creas un plugin o tema a medida como si modificas uno preexistente

Si estás desarrollando tu primer plugin o tema, o bien te ha tocado hacer un child de un tema padre para retocar cuatro cosas o mil, o bien llevas años dándole caña a la programación, pero aún no te habías metido con Git, sigue leyendo.

Te voy a intentar convencer para que mañana mismo empieces a usarlo.

¿Qué es Git?

Git es un sistema distribuido de control de versiones que usan la mayoría de los desarrolladores del mundo, según datos de 2022. Hay otros sistemas como Subversion (SVN)  y Mercurial, aunque no tienen la misma popularidad que Git.

Git fue creado por Linus Torvalds en 2005, y como Linux, es de código abierto y gratuito. Así que puedes bajarlo a tu ordenador muy fácilmente siguiendo las instrucciones que se dan en la guía de instalación de Git.

Pero, ¿qué es eso del control de versiones?

La idea es controlar tu código y sus cambios a lo largo del tiempo. Normalmente, trabajas en tu máquina en local, con tu instalación en WordPress montada sobre un MAMP, XAMP, LocalWP o similar para tener tu servidor y base de datos sobre los que WP pueda correr nuestra web.

Y tienes en un hosting el servidor con tu web, o de tu cliente.

El control de versiones trata de tener controlados todos los ficheros de tu proyecto y sus cambios.

Con Git, tendrás una copia de todos ellos en tu máquina local y otra en el repositorio remoto. Con lo que, además, tienes siempre una copia de seguridad actualizada en el repositorio.

Eso sí, cada vez que hagas un cambio vas a tener que enviarlo al repositorio y luego bajar la última versión de este si estabas en otra rama. 

Voy a explicarlo con un ejemplo práctico. Imagina tu tema child básico. Con su style.css y su functions.php.  Estos dos ficheros son tu primera versión de tu proyecto. Los tienes en tu máquina local en la rama principal y los subes al repositorio. 

Luego te piden que le quites la palabra “categoría” del título del archivo de categorías. Para ello necesitas un pequeño snippet como este que debes poner en el fichero functions.php:

Ahora tu fichero functions.php ya no es igual que antes, ha cambiado. Subes este cambio al repositorio y ya tienes una segunda versión del proyecto.

Esta es una explicación muy rudimentaria para entender bien el funcionamiento del control de versiones de Git ve a la página de Fundamentos de Git, donde lo explican con detalle.

Y así sucesivamente, a medida que vas añadiendo estilos, funciones, templates, patterns… se van añadiendo versiones.

Si en algún momento te equivocas, o por la razón que sea los cambios que has subido al pasar los ficheros a la web de producción, rompen el tema, puede que necesites volver a una versión anterior a ese cambio que lo ha roto todo.

Con git puedes hacerlo; puedes volver a la versión inmediatamente anterior o a una que esté tantas versiones atrás como necesites.

Trabajo en equipo

Otro gran objetivo del control de versiones distribuido es permitir que varias personas trabajen con el mismo software a la vez. Eso te permite trabajar en equipo si en algún momento necesitas que alguien colabore contigo. 

Por ejemplo, imagínate que vas muy cargado de trabajo y que te piden una nueva funcionalidad que no puedes atender. Le pides a una colega que te la desarrolle. Le das permisos para que trabaje con el repositorio del proyecto y ella podrá crear una rama para esa funcionalidad y trabajar sin interferir en tu trabajo hasta que la tenga terminada. 

Servicios de repositorios de Git

Para alojar esos repositorios en la nube, hay diversos servicios con planes gratuitos y de pago. Puedes investigar y escoger el que más te guste, todos puedes usarlos gratuitamente mientras no tengas proyectos gigantes y muy concurridos.

Vale, me has convencido ¿cómo empiezo?

• Lo primero es crear una cuenta en alguna de plataforma que facilite este servicio.
• Crear el repositorio con el nombre que quieras.
• Escoger si lo quieres privado o público y si quieres que te creen un fichero readme.md de entrada y/o un gitignore.
• Puedes consultar con detalle el proceso en la página de creación de cada servicio. No es difícil encontrarla.

Caso de uso: todavía no he creado mi plugin/tema en local

En este caso, en tu máquina tienes únicamente tu WordPress instalado con el tema que sea y los plugins que sean, pero no has creado aún tu carpeta del plugin que quieres desarrollar. 

Clonando

Yo estoy usando Github, pero puedes usar el servicio que creas más conveniente.

Pasos a seguir:

1. Copiar la url que el servicio te haya dado al principio del Quick setup
2. Crear la carpeta del plugin con el nombre que le quieras dar
3. Entrar en ella desde la consola (cd ..)
4. Escribir git clone y copiar la url que hemos copiado en el paso uno
5. Poner un espacio al final y un punto (esto hace que el repositorio se cree en esa carpeta, sino se creará otra carpeta dentro de la misma)

Esto inicializa git en esa carpeta y si habías añadido el readme y el gitignore te lo pondrá también. Sino, te advierte que has clonado un repositorio vacío, pero no pasa nada. 

Fíjate en el prompt, ahora aparece en rojo el nombre de la rama en la que estoy. Yo tengo git configurado para que mi rama por defecto se llame main, aunque a menudo también se llama master. 

Después de clonar el repo, podemos crear un primer fichero y subirlo así:

 cd plugin_or_theme_folder
 git clone https://servicio.com/nuriarai/testing-new.git .
 touch README.md
 git add README.md
 git commit -m "add README"
 git push --set-upstream origin master

Sin clonar

Podemos hacer el proceso sin clonar. Creando primero la carpeta y los ficheros y vinculando el repo remoto de esta manera. El comando git init es el que se encarga de inicializar git en esa carpeta.

 cd plugin_or_theme_folder
 echo "# testing-new" >> README.md
 git init
 git add README.md
 git commit -m "first commit"
 git branch -M main
 git remote add origin https://servicio.com/nuriarai/testing-new.git
 git push -u origin main

Caso de uso: ya tengo mi proyecto empezado en local

Si ya tienes tu plugin o tu tema desarrollados o a medias, entonces hazlo así:

 cd plugin_or_theme_folder
 git init --initial-branch=main
 git remote add origin https://servicio.com/nuriarai/testing-new.git
 git add .
 git commit -m "Initial commit"
 git push --set-upstream origin master

Caso de uso: ya tengo un repositorio anterior que quiero subir al nuevo

Imagina que has clonado tu repo de otro repo antiguo, o es una versión anterior que ahora quieres meter en un repo nuevo. Es decir, se trata de una carpeta que ya está vinculada a un repo existente. Lo que tienes que hacer es lo siguiente: 

 cd plugin_or_theme_folder
 git remote rename origin old-origin
 git remote add origin https://servicio.com/nuriarai/testing-new.git
 git add .
 git commit -m "Initial commit"
 git push --set-upstream origin master

¿Y qué versiono: todo WP o únicamente mi plugin o tema?

Personalmente, suelo versionar solamente el plugin o el tema que esté desarrollando. Si en un mismo proyecto tengo que desarrollar diversos plugins y un tema, cada uno lo tengo en un repositorio separado, puesto que son piezas separadas que, aunque compartan el mismo proyecto web, tienen sus propias peculiaridades y procesos.

Pero es igualmente válido tenerlos en el mismo repositorio. En ese caso Git se debe inicializar en la carpeta wp-content y trabajar muy bien el .gitignore para que solo contemple las carpetas de los plugins y tema que estás desarrollando e ignore todo lo demás. 

Por otro lado, hay quien prefiere tener el site entero versionado. Esto  implica que cada nuevo plugin o cada nueva actualización será contemplada también en el versionado. Por ello es importante en estos casos, recordar crear una rama para las actualizaciones o nuevos plugins, separada de nuestros desarrollos, para que no se nos mezclen unos cambios con los otros, y subirla en seguida. Hay que ser más previsor cuando se está trabajando con todo el site.

La elección también dependerá un poco de si quieres aplicar un workflow que incluya finalmente CI/CD (continuous integration/continuous deployment), de modo que todo lo que subas al repositorio, en cuanto se integre en la rama principal, se despliegue a producción. De todos modos, esto ya es un paso mucho más avanzado y es tarea de los servicios que alojan Git. 

El fichero .gitignore

Este fichero es vital para dejar fuera del control de versiones todos aquellos ficheros que no son necesarios controlar ni subir a producción. Es importante leer bien la documentación de cómo funcionan los patrones para ignorar o aceptar ficheros y/o directorios. 

Hay muchos ejemplos de .gitignore para WP en el propio Git y en artículos en general. Lo mejor es coger alguno de ellos y adaptarlo a tus necesidades en concreto, ya que dependiendo de qué carpeta estés versionando te hará falta ignorar más o menos ficheros y carpetas. 

Este es un .gitignore muy básico si tienes el git inicializado en la raíz de la instalación de WordPress:

 /wp-admin/
 /wp-content/index.php
 /wp-content/languages
 /wp-content/plugins/index.php
 /wp-content/themes/index.php
 /wp-includes/
 /index.php
 /license.txt
 /readme.html
 /wp-*.php
 /xmlrpc.php

 # Configuration
 wp-config.php

 # Example themes
 /wp-content/themes/twenty*/

 # Example plugin
 /wp-content/plugins/hello.php

 # Uploads
 /wp-content/uploads/

 # Log files
 *.log

 # htaccess
 /.htaccess

Si es en tu tema o plugin donde tienes git, lo más normal es que tu .gitignore tenga más esta apariencia.

 node_modules/

 # Log files
 *.log

 # Package files
 *.jar

 # Maven
 target/

 # JetBrains IDE
 .idea/

 # Visual Studio Code IDE
 .vscode/
 *.code-workspace

 # Unit test reports
 TEST*.xml

 # Generated by MacOS
 .DS_Store

 # Generated by Windows
 Thumbs.db

 # Applications
 *.app
 *.exe
 *.war

 # Large media files
 *.tiff
 *.avi
 *.flv
 *.wmv

 # sql files and compressed files
 *.sql
 *.gz
 *.zip

 # localWP file if xdebug is enabled
 local-xdebuginfo.php

Pero recuerda que esto son ejemplos, tienes que adaptarlo a tu caso concreto en cada proyecto. 

Conclusión

Espero haberte animado a empezar con Git si no lo habías hecho todavía. Sus bondades son numerosas y te va a salvar en más de una ocasión de situaciones que, sin él, tendrían difícil solución. Y puesto que quizás la cónsola aún te dé un poco de respeto, piensa que la mayoría de IDEs tienen herramientas de gestión integradas, o con alguna de sus extensiones, para trabajar con Git. 
También tienes SourceTree, una herramienta GUI, una interfaz gráfica, para trabajar con Git sin tener que usar la línea de comandos para nada.