Advertisement
  1. Code
  2. Tools

Git para diseñadores

Scroll to top
Read Time: 16 mins

Spanish (Español) translation by Esther (you can also view the original English article)

Probablemente estás familiarizado con herramientas como Git y Subversion. Pero, como diseñadores web, es muy posible que, aunque digas que aprovechas el control de versiones en tus proyectos, la verdad es que, la mayoría de las veces, simplemente no lo hagas. Si te ajustas a esta descripción, no te preocupes; no eres el único. De hecho, este autor opina, sin ningún tipo de investigación, que la gran mayoría de los diseñadores web no lo hacen. El dilema es que existe la creencia común de que el control de versiones es estrictamente para los codificadores duros, que pasan sus días en la oscuridad, y que rara vez salen a respirar, excepto cuando suena el microondas, señalando que el bolsillo caliente está listo para ser comido.

En realidad, si codificas para la web, ya sea en el front-end o en el back-end, es tu deber codificar de forma responsable: utiliza el control de versiones.


5 señales de que el control de versiones se ha retrasado

  1. No tienes ni idea de lo que es el control de versiones, ni de por qué puede ser útil.
  2. Codificas localmente y no tienes un sistema de respaldo.
  3. Realizas una copia de seguridad de tus proyectos duplicando esporádicamente el directorio raíz.
  4. Has borrado accidentalmente un archivo de forma permanente y has tenido que volver a codificar desde cero.
  5. Al realizar una serie de ediciones, la aplicación se interrumpe, momento en el que tienes que mantener pulsados Command + Z durante un doloroso número de segundos, mientras ves cómo el editor invierte tus cambios.

Admítelo: todos los desarrolladores se han identificado con uno de los signos señalados anteriormente en un momento u otro de su carrera. Pero recuerda: el primer paso para la recuperación es admitir que tienes un problema.


5 ventajas inmediatas del control de versiones

  1. ¿Has borrado accidentalmente esa clase o PSD? Ejecuta un único comando en el terminal para volver a un estado anterior del proyecto. ¡Desastre evitado!
  2. ¿Alguna vez te has horrorizado al ver que tu sitio web ha desaparecido de tu escritorio? Ayer estaba ahí, pero hoy ya no está. Un servicio gratuito, llamado GitHub, hace que esto no sea un problema.
  3. ¿Quién diablos escribiría este trozo de código que ahora tengo que pasar horas reescribiendo? No hace falta que te preguntes de quién es la culpa; ¡Git te lo dirá!
  4. Codifica con abandono, sabiendo que, con cada confirmación, se guardan "instantáneas" de tu aplicación, por si acaso necesitas volver a ese estado en algún momento del futuro.
  5. Aunque solo sea por eso, acepta que desarrolladores probablemente mucho más experimentados que tú lo hayan considerado una práctica óptima. Es útil imitar a aquellos a quienes admiramos.

¿Git?

Git es el sistema de control de versiones más popular que existe.

Entonces, ¿cómo influye Git en todo este asunto del control de versiones? Bueno, la definición súper nerd es que Git es un sistema de control de versiones distribuido, desarrollado por Linus Torvalds, donde cada directorio de trabajo es su propio repositorio con el historial completo disponible en cualquier punto. Además, Git ofrece la posibilidad de compartir código y crear múltiples ramas (o líneas de tiempo) para tus proyectos, lo que lo hace especialmente adecuado para equipos de desarrollo ágiles.

Una definición más comprensible podría ser: Git es una herramienta de línea de comandos que tú, y cualquier otro desarrollador de tu equipo, utilizan para guardar instantáneas frecuentes de vuestros proyectos. En cualquier momento, ofrece la flexibilidad de revertir los cambios a estados anteriores, con un solo comando.

El libro de Scott Chacon, 'Pro Git', está disponible en su totalidad en el sitio web de Git.


Instalación de Git

Ciertamente, el primer paso para la recuperación de la "codificación vaquera" es descargar Git de git-scm.com. Utiliza cualquiera de las siguientes URLs, dependiendo de tu SO de elección.

  • Mac: https://git-scm.com/download/mac
  • Windows: http://git-scm.com/download/win

A continuación, debemos configurar un poco la instalación, asociando un nombre de usuario y una dirección de correo electrónico. Abre tu consola más cercana (Terminal en el Mac), y ejecuta:

No te preocupes; esto solo tiene que escribirse una vez, después de instalar Git por primera vez. Ahora, para cada acción que realices, Git utilizará esta configuración.

Hay más opciones de configuración, como especificar qué editor de código debe usarse, cuando Git requiere que escribas un mensaje de confirmación, pero ignora eso por ahora.

Enhorabuena, ¡Git se ha instalado con éxito!


El ciclo básico

Como con cualquier tecnología nueva, hay que aprender un poco.

Uno de los aspectos más difíciles de aprender Git es descifrar a qué se refiere la diversa jerga. ¿Compromisos? ¿Establecer? ¿Rama? ¿Registros? ¿Eh?

Como con cualquier tecnología nueva, hay que aprender un poco. Por suerte, a pesar de lo complejo que puede ser Git, sobre todo como diseñador web, verás que un puñado de comandos te servirá de mucho. A modo de comparación, considera el diccionario inglés y, a continuación, el número de palabras que utilizamos de forma realista en las conversaciones cotidianas. Lo mismo ocurre con Git, a un nivel mucho más bajo. Así que no te sientas abrumado. Toma un comando a la vez.

Para acabar con esta confusa terminología, lo mejor es pensar primero en términos de algo tangible en el mundo real: un camión de reparto.

Imagina que has comenzado un nuevo sitio web estático. Has creado carpetas para los archivos JavaScript y CSS, así como un archivo index.html con un poco de HTML repetitivo. De hecho, ¡haz eso mismo ahora mismo! Cuando termine, es el momento de crear el primer commit.

Vuelve al Terminal y escribe:

Este comando, "inicializar Git", informa a Git de que deseamos el control de versiones para este proyecto. O, "iniciar el encendido". Solo es necesario ejecutarlo una vez, al comienzo del ciclo de vida de un nuevo proyecto.

A continuación, vamos a determinar cuál es el "estado".

Si se trabaja a lo largo, es probable que se vea algo parecido a:

Aunque es algo confuso, si nos tomamos un momento, veremos que, por defecto, estamos trabajando en una "rama", llamada "master". A continuación, tenemos un archivo sin seguimiento: index.html. A partir de esto, somos capaces de descifrar que Git no es mágico; hay que decirle qué archivos debe vigilar, por así decirlo.

¿Tienes curiosidad por saber por qué los directorios JavaScript y CSS no están incluidos en la lista de archivos no rastreados? Git rastrea archivos, no carpetas. Una técnica común, sin embargo, para incluir directorios vacíos en un commit es añadir un archivo .gitignore a cada subdirectorio. ¡Más adelante hablaremos de ello!

Archivos de seguimiento

Para hacer un seguimiento de los expedientes, primero hay que añadirlos a la zona de espera, es decir, ponerlos en el camión.

Ahora, si volvemos a comprobar el estado, veremos:

Excelente; Git está vigilando este archivo en busca de cambios. En este caso, solo hemos añadido un único archivo. Si, en cambio, preferimos añadir todos los archivos al área de preparación, podemos utilizar el símbolo de punto.

Recuerda que el camión aún no ha salido; simplemente hemos cargado un par de cajas (o archivos) en la parte trasera. Para realizar la instantánea, y guardar una copia del proyecto en su estado actual de seguimiento, hay que realizar un commit.

Arriba, hemos creado un nuevo commit, y proporcionado un mensaje de "Primer commit". Con eso, nuestro primer commit se ha completado, y el camión ha salido hacia la fábrica, con una copia del proyecto en la parte trasera.

Para verificar tu trabajo, utiliza un nuevo comando: "registro".

Perfecto, de hecho se ha creado un nuevo commit, y también parece que el commit tiene un id de referencia único. Archiva esto por ahora.

Si, de nuevo, comprueba el estado.

Porque no se han hecho cambios desde la última confirmación, Git nos lo dice:

¡Éxito! El 90% de tu uso de Git seguirá este ciclo.

  • Realiza cambios
  • Añadir archivos al área de preparación
  • Realizar un commit con un mensaje que describa la acción realizada

Aclarar y repetir.

Pasemos al siguiente paso. Como ejemplo fácil, tal vez queramos incluir una simple hoja de estilo de restablecimiento en nuestro proyecto. Escribiremos el más básico (quizás desaconsejable) de los reinicios.

Ahora, vuelve a index.html, e incluye una referencia a este archivo:

Como regla básica, si puedes describir a la persona sentada a tu lado el cambio que acabas de hacer en un proyecto, es probable que merezca un commit. Hazlo a menudo. Hagamos eso ahora; ¡vamos a la Terminal!

Cuando se escriben mensajes de confirmación, generalmente se considera que la mejor práctica es escribir en tiempo presente. Por lo tanto, "agregar archivo" en lugar de "archivo agregado".

Avanza rápido hasta mañana, y ahora tu jefe te dice que no quiere usar tu simple archivo de restablecimiento. En su lugar, prefieren utilizar la popular hoja de estilo Normalize, de Nicolas Gallagher.

No hay problema; con Git, esto se arregla fácilmente. Vamos a revertir el commit anterior, y hacer las modificaciones necesarias.

Con Git, la regla es "nunca reescribir la historia".

Este comando revertirá todos los cambios que haya hecho en la confirmación más reciente. Esencialmente, es un commit que hace exactamente lo contrario de lo que hizo el anterior. ¿Por qué revertir, en lugar de deshacer la confirmación por completo? De nuevo, porque estamos siguiendo las mejores prácticas. Con Git, la regla es "nunca reescribir la historia". Revierte los cambios, pero nunca los borres y deshagas.

Al pulsar enter, serás llevado a una nueva pantalla con el texto, "Revert "Add and include reset stylesheet". En este punto, estás en modo Vi (aunque eres libre de configurar Git para usar cualquier editor de código que desees.) Por ahora, ve con los valores predeterminados, guarda y sal. Para ello, escribe :wq (Write and Quit).

Y con ese único comando, los cambios han sido revertidos. Ve y comprueba para asegurarte. El archivo style.css ha sido eliminado, y ya no hay una referencia a la hoja de estilos dentro de index.html. ¡Este es el poder de Git! Debido a que adoptamos un estilo de desarrollo de comprometerse a menudo, cuando se coloca en situaciones, donde las ediciones deben ser revertidas, solo se necesita un solo comando. ¡Ya no hay que pulsar Command-Z para la enternidad!

Siguiendo la petición del jefe, vamos a actualizar el proyecto para utilizar Normalize.css, que hemos descargado y colocado dentro de css/normalize.css.

Dentro de index.html, haz referencia a él:

Y, finalmente, confirmamos los cambios.

Aunque este era un ejemplo sencillo, imagina lo útil que puede ser esta técnica para cambios más grandes, que abarcan varios archivos dentro de tu aplicación. Al agrupar todos los cambios relacionados en una sola confirmación, logramos la máxima flexibilidad y seguridad.


Espacio para experimentar

¿Alguna vez has estado en un punto de un proyecto, cuando quieres experimentar con una idea que puede o no llegar a la aplicación terminada? Si bien es cierto que siempre se puede revertir el commit si las cosas no van de acuerdo con el plan, es una idea más inteligente, por una variedad de razones, aprovechar la ramificación.

La mejor manera de ilustrar el concepto de ramas Git es hacer referencia a Regreso al Futuro 2.

En este sentido, si eres un desarrollador friki y no has visto la trilogía de Regreso al Futuro, deja lo que estás haciendo y mírala.

Continuando, ¿recuerdas la parte de Regreso al Futuro 2, después de que Marty y Doc regresan a 1985 desde el futuro, pero descubren que todo es diferente? Al encontrarse en el laboratorio de Doc, ahora destruido, Doc dibuja un diagrama, describiendo cómo, en algún momento, "la línea de tiempo se desvió hacia esta tangente, creando un 1985 alternativo". ¡Esto es como una bifurcación!

Consideremos nuestro proyecto de demostración actual; ahora mismo, hay una línea de tiempo: una línea recta. En cuanto creamos una rama para trabajar en nuestra idea, nos separamos de esta línea de tiempo y creamos otra. En este punto, ambas líneas de tiempo existen, y pueden contener sus respectivos commits, sin interferir el uno con el otro.

¿Qué utilidad tiene esto? Considera un ciclo de desarrollo ágil, en el que tú o tu equipo desplan actualizaciones varias veces a la semana. Si te quedas con el enfoque de "línea de tiempo única", desplegar, por ejemplo, una simple corrección de errores tipográficos, no sería posible hasta que terminaras de trabajar también en tu idea. Sin embargo, con la bifurcación, tenemos la flexibilidad de tomar todo el tiempo que necesitemos en nuestra idea, mientras seguimos liberando la rama maestra (la predeterminada y principal) para desplegar la corrección de errores.

Para crear una nueva rama, ejecuta:

Alternativamente, combina estos dos comandos en uno solo.

Esto se traduce en: crear una nueva rama, llamada "idea" (sustituirla para que sea más descriptiva de lo que estás trabajando, por supuesto), y cambiar a ella.

A partir de este momento, las modificaciones y confirmaciones que hagas no serán referenciadas dentro de la rama maestra. Adelante, pruébalo. Edita index.html y haz un pequeño cambio:

Luego, compromete tu trabajo.

Ya hemos hecho nuestro primer compromiso en esta nueva línea de tiempo. Nuestra idea ficticia aún necesita ser trabajada, pero estamos en camino. Pero, ahora, un cliente acaba de informar de un error tipográfico que tenemos que arreglar lo antes posible. Como usamos correctamente las ramas, podemos volver a la rama maestra, arreglar la errata y desplegarla.

Una vez que nuestra idea está terminada, es el momento de fusionarla con la rama maestra.

¡Si todo va según lo previsto, tu rama de características se fusionará con éxito en la rama maestra, resolviendo la segunda línea de tiempo alternativa de 1985!

Dicho esto, no cabe duda de que te encontrarás con situaciones en las que Git parece plantar los pies en el suelo y se niega a continuar como se le pide. En estos casos, Git no está siendo un idiota sin razón. Lo más probable es que el problema esté relacionado con algún conflicto que debe resolverse primero, antes de que Git pueda continuar. Imagina que intentas fusionar un archivo en la rama maestra; el único problema es que, desde que se creó la rama, el archivo se ha editado tanto en la rama de características como en la maestra. En situaciones como ésta, ¿cómo podría Git saber qué versión del archivo debe tener prioridad, al fusionar las dos? No lo sabe, y esto es lo que llamamos un conflicto.

Antes de que Git pueda proceder, debes resolver el conflicto, editando index.html.


Ignorar los archivos

Es probable que llegue un momento en el que determines que es mejor no seguir ciertos tipos de archivos con Git. Algunos ejemplos podrían ser el común .DS_STORE (con el que los usuarios de Mac estarán familiarizados), los directorios de construcción y los activos compilados temporales.

Muy fácil, Git, a través de un archivo .gitignore, nos permite ignorar ciertos tipos de archivos. Para hacer uso de esto, crea un nuevo archivo .gitignore en la raíz (pero sin limitarse a ella) de tu proyecto. Dentro de ella, proporciona una lista de archivos o tipos de archivos para ignorar. Este es un ejemplo básico:


Codificación social

GitHub hace posible la codificación social.

Hasta ahora, has aprendido a confirmar tu código localmente. Pero, ¿cómo se pueden compartir estas modificaciones con tu equipo o con el resto del mundo? Entra en GitHub.

GitHub te permite compartir tu código con el mundo. Es la mayor comunidad de código abierto que existe.

Una vez que te registres en una nueva cuenta en github.com, tendrás que seguir unos pasos para generar una clave especial, con el fin de asociar tu ordenador con tu cuenta de GitHub. No te preocupes; si sigues los pasos, no deberías tener ningún problema.

En este punto, podemos crear un nuevo repositorio, y empujar nuestro pequeño proyecto, para compartirlo con el mundo. Una vez iniciada la sesión, haz clic en el botón "Nuevo Repositorio", dale un nombre a tu repo y haz clic en "Crear Repositorio". A continuación, se te presentarán unos cuantos comandos que puedes pegar en el Terminal. Como ya tenemos un repo existente, necesitamos la segunda opción:

Esto instruye a Git para que añada nuestro nuevo repositorio remoto, y lo alias como "origen". A continuación, empujamos la rama maestra (no la idea) al remoto con el alias de "origen".

Ya está. Vuelve al navegador, actualiza la página y encontrarás tu nuevo repositorio fresco, esperando a ser compartido con el resto del mundo.

Cuando otros miembros de tu equipo deseen incorporar los cambios que has realizado, solo tienen que ejecutarlos:

¡Este comando extraerá las últimas actualizaciones que se hayan enviado a GitHub! Además de compartir código, GitHub también ofrece la posibilidad de seguir y contribuir a proyectos populares de código abierto, así como un rastreador de problemas para los errores y las solicitudes de características. ¡Es la codificación social en su máxima expresión!


Reflexiones finales

Aunque solo hemos arañado la superficie de lo que Git es capaz, lo cierto es que, de nuevo, para el 80% de tu uso de Git, las técnicas referidas en este artículo serán suficientes. Crea una rama de características, escribe algo de código, añádelo a la zona de preparación y envíalo con un mensaje. Cuando esté listo, vuelve a fusionarlo con la rama maestra y despliégalo. A continuación, ¡aclara y repite!

No lo olvides: cuando estés perplejo, StackOverflow es tu mejor amigo. Sea cual sea el problema, otros han estado en la misma situación. Busca allí primero.

TryGit ofrece una experiencia interactiva para aprender Git.

Aprendizaje adicional

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.