Autor: José Manuel Delicado

Última actualización: 29 de junio de 2024

Git es el sistema de control de versiones usado por NVDA y la mayoría de proyectos relacionados, como los complementos. En esta guía aprenderás lo esencial para ponerte en marcha y comenzar a colaborar con la comunidad de desarrolladores.

Índice

¿Qué es Git?

Git es un sistema de control de versiones distribuido que permite gestionar todo tipo de proyectos. Probablemente la definición de control de versiones no te resulte familiar, así que deberíamos empezar por ahí.
Imagina que tienes un archivo en tu disco duro. Por ejemplo, podríamos estar hablando de un documento, una canción o un vídeo que tú mismo has hecho. Imagina que, junto a ese archivo, se almacenan todos los cambios por los que ha ido pasando desde que nació, con una descripción de lo que se hizo en cada cambio, y que además puedes hacer que el archivo «retroceda en el tiempo» y se quede como estaba antes de un cambio en concreto. ¿Te suena esto de Microsoft Word o Dropbox? Pongamos algunos ejemplos de cambios:

  • 25/06/2017: modificado el apartado de introducción para corregir un error ortográfico.
  • 30/06/2018: ahora las voces vuelven a oírse por encima de la música.

Git permite gestionar no sólo un archivo, sino carpetas enteras con ficheros que se añaden y se eliminan. Normalmente se usa para desarrollar software, pero tiene otras muchas aplicaciones prácticas. Para ello, utiliza repositorios. Solemos emplear un repositorio por proyecto. Un repositorio es una carpeta especial donde se almacenan los archivos del proyecto, pero también todas sus versiones y cambios. Se dice que Git es distribuido porque no necesita conectarse a ningún servidor para trabajar, a pesar de que puede hacerlo. De hecho, para dar los primeros pasos con él, vamos a trabajar con repositorios locales sin enviar el resultado a ningún sitio. Por otra parte, a pesar de que puede manejarse con pequeños archivos binarios, Git está pensado para trabajar con texto plano. El código fuente de un programa está formado por ficheros de texto plano (por ejemplo, los que se escriben con el bloc de notas), y pequeños recursos adicionales, como sonidos o imágenes.
A continuación, aprenderemos cómo se instala Git en Windows y cómo dejarlo listo para empezar a trabajar.

Instalación de Git for Windows.

Para instalar Git en Windows, lo primero que haremos será visitar su página de descargas. Al entrar, deberemos elegir la descarga más adecuada para nuestro sistema, que en la mayoría de casos suele ser la versión más reciente para 64 bits. Pulsa el enlace «Click here to download the latest» para descargar el programa de instalación. El instalador se parece mucho al de otros programas, pero debemos prestar atención a algunas de sus pantallas si queremos que nuestra experiencia a ciegas con él sea óptima. Estas son las pantallas por las que pasaremos:

  1. Licencia. Si aparece una casilla llamada «Only show new options», la dejamos desmarcada y nos limitamos a pulsar Next.
  2. Selección de carpeta de destino de instalación. En la mayoría de casos, se puede dejar la ruta por defecto.
  3. Selección de componentes. Puede ser buena idea crear un icono en el escritorio (on the desktop), añadir la extensión de Git Bash al menú contextual (Git Bash here) y hacer que el programa busque actualizaciones a diario (Check daily for Git for Windows updates). Podemos marcar estas casillas, y todas las que queramos, y pulsar Next.
  4. Selección de carpeta en el menú Inicio. Podemos dejar el valor por defecto, y marcar la casilla «Don’t create a Start menu folder» si no queremos ningún acceso directo salvo el del escritorio.
  5. Selección de editor. Es recomendable emplear un editor de consola, como Nano o Vim, ya que nos va a ahorrar ventanas innecesarias. Nano puede ser más cómodo para los principiantes (y no tan principiantes). Podemos elegir el editor en el cuadro combinado, y pulsar Next.
  6. Selección de nombre de rama predeterminada. Si dejamos que Git decida (let Git decide), el nombre será master. Es el que se usará a lo largo de estos tutoriales. La posibilidad de cambiarlo viene por motivos políticos y reclamaciones de ciertos colectivos cuya sensibilidad es herida por la palabra master.
  7. ¿Desde dónde se usará Git? «Use Git from Git bash only» es la opción menos invasiva, ya que no modifica variables de entorno del sistema. Sin embargo, sólo podremos usar Git desde la consola Git Bash. Las otras dos opciones permiten usar Git desde la consola cmd (Git from the command line and also from 3rd-party software, la más equilibrada), o Git y las herramientas que lo acompañan desde la consola cmd (Use Git and optional Unix tools from the Command Prompt, no recomendada).
  8. ¿Qué cliente ssh se utilizará? Git viene con una versión de OpenSSH incorporada (Use bundled OpenSSH), pero a partir de Windows 10, se puede instalar OpenSSH de forma nativa en el sistema y usarlo (Use external OpenSSH). Por motivos de consistencia entre versiones distintas del sistema operativo, se recomienda la primera opción.
  9. Selección de biblioteca SSL. Seleccionamos «Use the native Windows Secure Channel library» y seguimos adelante.
  10. Tratamiento de saltos de línea en los commits. Más adelante veremos qué son los commits. Recomendable elegir la opción «Checkout as-is, commit as-is», ya que siempre los dejará sin modificar.
  11. Selección de programa de consola. Aunque MinTTY ya es accesible con NVDA, ninguna consola se comportará mejor que la nativa del sistema, así que elegiremos «Use Windows’ default console window».
  12. Comportamiento predeterminado de git pull. Más adelante explicaremos qué hace este comando. De momento, lo ideal es elegir el valor «Fast-forward or merge».
  13. Ayudante de credenciales. En principio no nos hará falta, así que elegiremos None (ninguno).
  14. Pantallas con opciones extra y experimentales. Se recomienda dejar los valores por defecto.
  15. Al pulsar el botón Install en la última pantalla de opciones experimentales, Git se instalará en nuestro sistema con las opciones elegidas.
  16. Pantalla de finalización. Contiene casillas para ver las notas de la versión y abrir Git Bash. Podemos desmarcar todas y pulsar Finish.

¡Conseguido! Ya tenemos Git instalado en nuestro sistema. El siguiente paso es configurar nuestra identidad y claves GPG y SSH, que nos vendrán muy bien en el futuro.

Configuración de identidad y algunos parámetros extra

Cuando trabajemos con repositorios, normalmente lo haremos en equipo. Es muy útil saber quién ha hecho cada cambio, especialmente si las cosas no van bien. En esta sección vamos a utilizar la consola Git Bash para ejecutar comandos. Como son algo complicados al principio, puede ser una buena idea copiarlos y pegarlos. Para ello, primero debemos preparar nuestra consola:

  1. Abre el símbolo del sistema (pulsa windows+r, escribe cmd y pulsa intro).
  2. Pulsa alt+espacio para abrir el menú Sistema, y activa la opción propiedades.
  3. Busca la casilla de verificación «Usar Ctrl+Mayús+C o V como Copiar o pegar», y márcala. Pulsa intro para guardar los cambios.
  4. Escribe el comando exit y pulsa intro para salir de la consola.

A partir de ahora, si control+v no pega un comando que hayas copiado al portapapeles, puedes pulsar control+shift+v. Hecho esto, nos olvidamos de cmd y abrimos Git bash, que debería estar en el escritorio. Allí, escribimos los siguientes comandos, reemplazando el texto entre comillas según corresponda:
Configuramos nuestro nombre, se recomienda que sea nombre real con apellidos y acentos donde corresponda: git config --global user.name "nombre y apellidos"
Y ahora, nuestra dirección de correo: git config --global user.email "[email protected]"

Generación de un par de claves SSH y GPG

Estas claves son muy importantes de cara a la seguridad, ya que permiten certificar nuestra identidad y conectarnos fácilmente a sitios externos. Aunque se suelen generar en etapas más avanzadas de aprendizaje, aquí se ha optado por tenerlas en cuenta desde el primer momento. Vamos a generar dos pares de claves públicas-privadas. La parte privada estará cifrada y nunca saldrá de nuestro ordenador, y la parte pública la podremos compartir con los demás.
El siguiente comando genera una clave ssh. Debemos sustituir la parte entre comillas por nuestro correo: ssh-keygen -t ed25519 -C "[email protected]"
El generador es interactivo, y nos hará un par de preguntas. En la primera pide la ruta del archivo donde se almacenará la clave. Pulsamos intro sin escribir nada.
A continuación nos solicitará una «passphrase» para cifrar la clave privada. Se puede dejar vacía, aunque lo ideal es escribir una contraseña suficientemente segura. Hay que escribirla dos veces para confirmarla. Al teclearla en la consola, el lector de pantalla no dirá nada y los caracteres no aparecerán escritos en pantalla.
Ya tenemos la clave ssh generada. Ahora vamos con la clave gpg. Al ejecutar el siguiente comando, también se activará una aplicación interactiva que nos hará preguntas: gpg --full-generate-key
Pulsamos intro en la primera pregunta para aceptar el tipo de clave por defecto.
La segunda pregunta está relacionada con la curva elíptica que se usará para cifrar la clave. Podemos pulsar intro para elegir el valor predeterminado.
En la tercera pregunta, el programa querrá saber cuándo caduca la clave. Pulsamos intro sin escribir nada para que no caduque nunca.
Lo siguiente que debemos hacer es comprobar que los datos son correctos y pulsar la y e intro para confirmar.
A continuación, introduciremos nuestra información de usuario. El programa nos pedirá nuestro nombre, dirección de correo y un comentario que se puede dejar vacío. Los datos deben ser los mismos que introdujimos previamente con git config. Al acabar, pulsamos la letra O para indicar que todos los valores son correctos, e intro para continuar.
Finalmente, aparecerá un diálogo independiente para solicitarnos una passphrase o contraseña con la que se cifrará la parte privada. A diferencia de ssh, donde esto se hacía en consola, aquí estamos en un diálogo estándar de Windows. Tras escribir la contraseña y confirmarla en la segunda ventana que aparece, habremos terminado la generación de claves.
Para acabar este capítulo, asociaremos nuestra clave gpg recién creada a Git. De esa forma, cuando agreguemos cambios al repositorio, podremos firmar dichos cambios y garantizar que nadie suplanta nuestra identidad.
En primer lugar, listamos las claves existentes. Tenemos que hacerlo para extraer un identificador: gpg --list-secret-keys --keyid-format=long
Podemos usar las órdenes del cursor de revisión de NVDA para seleccionar y copiar el texto, o lo que es más fácil al principio: ejecutar el mismo comando y guardar el resultado en un fichero de texto. Por ejemplo: gpg --list-secret-keys --keyid-format=long > resultado.txt
El fichero resultado.txt estará en nuestra carpeta de usuario. En él veremos algo como esto:

[keyboxd]
---------
sec   ed25519/1A703CB73B311567 2024-06-28 [SC]
      20BD343DBF8E8CB133A6DE6E1A703CB73B311567
uid                 [ultimate] Pepe Pérez 
ssb   cv25519/B75DF497708DEFAA 2024-06-28 [E]


El identificador de la clave que nos interesa está inmediatamente debajo de la línea de guiones, justo después de sec ed25519, tras la barra y antes de la fecha de generación. Debemos copiarlo y ejecutar dos comandos más con él.
Primero, indicamos a Git qué clave usar cuando haga firmas (reemplaza este identificador de ejemplo por el tuyo): git config --global user.signingkey 1A703CB73B311567
Después, le decimos que firme siempre, aunque no se lo pidamos de forma explícita: git config --global commit.gpgsign true

Actualización de Git for Windows

Git es un proyecto que se encuentra en constante evolución, y siempre viene bien mantenerlo actualizado para sacar partido a los cambios más recientes.
Desde la consola, se puede ejecutar el siguiente comando para buscar actualizaciones: git update-git-for-windows
Si hay una actualización disponible, se nos preguntará si queremos instalarla. En este caso, basta con pulsar la y, después intro, y aceptar las advertencias del control de cuentas de usuario. Todo lo demás se hace automáticamente.

Creación de nuestro primer repositorio con Git

Como se ha explicado antes, Git permite gestionar los cambios hechos a un proyecto. Para ello, utiliza repositorios, que son un tipo de carpeta especial donde, además de alojar archivos, también se almacena toda su historia. Para trabajar con repositorios Git usaremos la consola, así que nos conviene conocerla un poco mejor.

  • Para leer la consola, utilizaremos las órdenes del cursor de revisión de NVDA: 7 y 9 del teclado numérico para desplazarse por líneas, 4 y 6 para navegar por palabras, y 1 y 3 para hacerlo por caracteres. Si no tenemos teclado numérico, podemos usar las combinaciones equivalentes de la disposición portátil.
  • Para copiar texto de la consola, iremos al principio del texto a copiar con el cursor de revisión, y pulsaremos NVDA+f9. Después, iremos al final y pulsaremos NVDA+f10 dos veces rápidamente.
  • Si pulsamos las flechas arriba y abajo, podremos navegar por el historial de comandos previamente introducidos. Pulsando intro sobre un comando lo ejecutaremos otra vez.
  • Para salir de la consola, podemos escribir exit o pulsar control+d. Control+d imprime el carácter especial de final de archivo.
  • Si pulsamos control+c cancelaremos la ejecución de un comando. Útil si, por ejemplo, tarda mucho o queremos interrumpir una operación.
  • Pulsando control+r, activaremos el modo de búsqueda de comandos del historial. Escribiendo las primeras letras del comando, se autocompletará la coincidencia más próxima.
  • El tabulador nos puede servir para completar nombres de archivo o carpeta en muchas ocasiones. Ahorrará mucho tiempo y pulsaciones de teclado.
  • El comando cd sirve para navegar a otra carpeta. Al abrir la consola, los comandos que escribamos tendrán efecto sobre nuestra carpeta de usuario, y eso es algo que no nos interesa el 90% de las veces. Por ejemplo, si escribimos cd desktop iremos al escritorio, y escribiendo cd .. iremos al directorio de nivel superior. Si queremos cambiar de unidad, lo haremos poniendo una barra y la letra de la unidad a la que queremos ir. Por ejemplo, cd /d para ir a la unidad D. En Bash, el separador de rutas es la barra normal, y no la invertida que se utiliza habitualmente en Windows.
  • La opción de menú «Git bash here» que está en el menú de contexto del explorador de archivos abrirá la consola Git Bash en la carpeta que elijamos, sin necesidad del comando cd.

Para mantenernos organizados, podemos crear una carpeta en la que almacenaremos todos nuestros repositorios Git, preferiblemente en una ruta lo más breve posible. Por ejemplo, podría ser una carpeta llamada git_repos situada en la raíz de la unidad C. Aunque se puede usar el explorador de archivos, ¿qué tal si probamos a hacerlo desde la consola?

  • Navegamos a la raíz de la unidad C: cd /c
  • Creamos la carpeta git_repos con el comando mkdir: mkdir git_repos
  • Entramos en la carpeta: cd git_repos

Ahora, vamos a crear nuestro primer repositorio, y para ello vamos a echarle algo de imaginación.
Recientemente, los administradores de la sala de juegos han comunicado en los foros de todos los idiomas que el reglamento se está quedando obsoleto, y que habría que modificarlo para que se adapte a los nuevos tiempos y necesidades de los usuarios. Sin embargo, no saben qué hacer, así que vamos a crear un repositorio colaborativo para ayudarles con algunas sugerencias. En dicho repositorio, vamos a grabar un par de commits. Los commits son como una especie de confirmación de que hemos hecho un cambio, y que todo lo que se haga a partir de ahora tomará como punto de partida dicho cambio. Nos servirán para que los demás sepan lo que hemos hecho, y para retroceder y dejar todo como estaba en caso de que haya algún problema. Estando en nuestra nueva carpeta git_repos, ejecutamos los siguientes comandos:

  1. Creamos una nueva carpeta para nuestro repositorio: mkdir reglas_sala
  2. Entramos en ella: cd reglas_sala
  3. Inicializamos un repositorio vacío: git init

Al ejecutar este último comando, ya tendremos creado nuestro repositorio. Si entramos desde el explorador de archivos a la carpeta, veremos una subcarpeta llamada .git, que no debemos borrar bajo ningún concepto y que ignoraremos completamente, como si no existiera. Si se borrara, convertiríamos el repositorio otra vez en una carpeta normal y corriente. Ahora, comencemos a trabajar con el reglamento de la sala.

  1. Abre el bloc de notas, y pega en su interior el reglamento de la sala de juegos.
  2. Guarda el archivo dentro de C:\git_repos\reglas_sala. Dale como nombre reglas.txt.

Tener las reglas sin modificar puede ser un buen punto de partida para nuestro repositorio, así que vamos a hacer nuestro primer commit. Asumimos que la consola Git Bash está abierta, y que hemos navegado dentro del repositorio.
En primer lugar, tenemos que decirle a Git qué cambios van a formar parte del commit. Muchas veces basta con decirle que mire el repositorio entero, pero puede interesarnos que sólo se archiven uno o dos ficheros. Para simplificar, le pediremos que añada todos los cambios que se han hecho en el repositorio.
Para ello, podemos usar un comando como este: git add --all
Aunque mucha gente también usa este otro: git add . (poniendo al final un punto en vez de --all).
Con el comando git status, sabremos qué ha cambiado y qué se va a incluir en el commit. Es un comando meramente informativo, así que no hay ninguna obligación de usarlo siempre.
A continuación, hacemos el primer commit de nuestro repositorio. En él, hablaremos un poco de lo que hemos hecho hasta ahora: git commit -m "Agregado fichero con las reglas de la sala"
Al pulsar intro, aparecerá un diálogo preguntándonos la contraseña de la clave GPG que creamos en el capítulo anterior. Tras introducirla, el commit quedará almacenado para siempre y firmado con nuestra clave. En la consola veremos que se ha creado un archivo, y cuántas líneas se han agregado a él.
Ahora, hagamos un cambio para ver qué ocurre.

  1. Abre el fichero reglas.txt con el bloc de notas.
  2. Busca la línea «No spam ni publicidad».
  3. Cámbiala para que diga «Se permite el spam, pero no la publicidad».
  4. Guarda el fichero y cierra el bloc de notas. Vuelve a la consola.
  5. Ejecuta el comando git status. Observa que nos dice que el archivo reglas.txt ha cambiado.
  6. Agrega los cambios al repositorio: git add --all
  7. Haz tu segundo commit: git commit -m "Ahora se permite el spam, muy divertido en mesas libres!"

Observa lo que ocurre. Git nos dice que se ha añadido una línea, y que se ha borrado una línea. Por desgracia, no es tan inteligente como para saber que hemos modificado esa línea, y piensa que la hemos borrado para sustituirla por otra totalmente distinta.

Cómo saber qué cambios se han hecho en un repositorio

Muchas veces nos encontraremos proyectos hechos por otras personas. Para conocer un poco más sobre ellos, puede ser conveniente saber cómo han evolucionado a lo largo del tiempo, y qué nos cuentan los desarrolladores en cada commit. Para ello, utilizaremos el comando git log. Este comando muestra en orden cronológico el historial del repositorio, situando en la parte superior de la ventana el commit más reciente. Pulsando intro, haremos que la pantalla avance. Con el 7 y el 9 del teclado numérico, moveremos el cursor de revisión de NVDA por las líneas de la consola. Para salir del log, pulsaremos la letra q. Hagamos un sencillo ejercicio para ilustrarlo.

  1. Abre Git Bash en la carpeta del repositorio de reglas de la sala.
  2. Escribe o copia y pega este comando, y después pulsa intro: git log
  3. Lee el historial y observa con atención la información de cada commit. Se pueden apreciar la fecha y la hora, los mensajes que introdujimos en el ejercicio anterior, el nombre del autor, y un identificador formado por números y letras parecido a esto: commit ff92c73d4ce8f21a08f61920556f7a566b815860.
  4. Copia los identificadores de los dos commits del repositorio, alguno de ellos podría ser necesario en el próximo ejercicio.
  5. Si el símbolo inferior de la consola es «:» (sin las comillas), pulsa la q para salir del log.

Cómo conocer los detalles de un cambio concreto

En ocasiones no tendremos suficiente con el mensaje que nos haya dejado el responsable del commit, y querremos saber más sobre los cambios que ha hecho, por ejemplo, para evaluar la calidad de su trabajo. Aquí entra en escena el comando git show. Para simplificarlo mucho, este comando se escribe con el identificador del commit que queremos mirar. Al igual que en el caso anterior, cuando terminemos de echar un vistazo, podremos salir pulsando la q.
Si no tenemos a mano el identificador del commit más reciente, podemos usar la palabra clave HEAD. El HEAD es como un cursor que se sitúa en la posición en la que estamos trabajando, aunque no entenderemos realmente para qué sirve hasta más adelante.
Cuando visualicemos los cambios de un commit, encontraremos lo siguiente:

  • La misma información que en el log: identificador del commit, nombre del autor, mensaje, fecha y hora, etc.
  • Un breve párrafo por cada archivo que haya cambiado, con un resumen de las líneas modificadas y su posición.
  • Las líneas modificadas en el commit y un breve contexto para saber dónde están. Cada línea añadida llevará delante el signo de suma (+), y cada línea eliminada llevará el signo de resta (-). Si se modifica una línea, veremos que se elimina y se añade dicha línea.

Queremos saber qué ha cambiado en el fichero de reglas de la sala, porque ha pasado tanto tiempo desde que lo modificamos que ya no nos acordamos.

  1. Abre Git Bash en el repositorio de reglas de la sala.
  2. Escribe o copia y pega este comando: git show HEAD
  3. Lee la consola. Observa que sólo se ha añadido una línea, y se ha eliminado otra. Si es necesario, pulsa la q cuando acabes.
  4. Si tienes a mano el identificador del primer commit que hiciste añadiendo el fichero de reglas, usa el mismo comando con él: git show 1A2B3C4D5E6F…
  5. Fíjate en lo que ocurre. Todas las líneas del reglamento de la sala llevan un signo más delante.

Cómo retroceder a un commit específico

Los administradores de la sala de juegos han visto que estamos modificando sus reglas en un repositorio, y no les ha gustado demasiado la idea. Se han enfadado porque ellos también querían participar, y nos han pedido que les enviemos una copia del archivo original, sin modificaciones. Lo habitual en estos casos es utilizar el comando checkout. El comando checkout modifica nuestra carpeta de trabajo para que quede tal y como estaba en un commit concreto. Más adelante, veremos que checkout también nos sirve para cambiar de rama o desplazarnos a un tag. Copia los identificadores de los dos commits del repositorio de reglas, utilizando git log si es necesario, y sigue los pasos que se indican a continuación:

  1. Si no está abierta, abre la consola Git bash en el repositorio de reglas de la sala.
  2. Abre el fichero de reglas en un bloc de notas. Comprueba que la regla que permite el spam está ahí, y después ciérralo.
  3. Escribe el comando git checkout, seguido del identificador del commit más antiguo. Por ejemplo: git checkout 1A2B3C4D…
  4. Abre el fichero de las reglas otra vez con el bloc de notas. Comprueba que ahora el spam está prohibido, como antes de que hiciéramos el cambio.

Esto no significa que el cambio se haya borrado, sigue ahí guardado en el repositorio. Para regresar donde estábamos, vamos a utilizar otra palabra mágica que más adelante sabremos para qué sirve, y nos ahorraremos copiar y pegar el identificador del commit más reciente.

  1. Teclea o copia y pega el siguiente comando, y pulsa intro: git checkout master
  2. Abre las reglas con el bloc de notas. Ahora, el spam vuelve a estar permitido.

Utilización de tags

Cuando tenemos un repositorio con miles de commits, saberse sus identificadores no resulta práctico. Tenerlos guardados en un archivo o mirarlos con git log, tampoco. En estos casos, lo mejor es recurrir a los tags. Por regla general, un tag es una etiqueta asociada a un commit, de tal forma que podamos viajar hasta él sin conocer su identificador de referencia. Los tags se usan para marcar hitos históricos de importancia relevante, como la liberación de nuevas versiones de un programa. El proyecto NVDA, por ejemplo, tiene tags como estos:

  • release-2021.1
  • release-2021.1rc1
  • release-2020.4

Si escribimos el comando git checkout release-2021.1, nuestro directorio de trabajo contendrá el código fuente exacto de NVDA 2021.1, sin modificaciones posteriores que lleguen por las snapshots alpha. Existen dos tipos de tags:

  • Tags ligeros: contienen una referencia al commit al que etiquetan.
  • Tags anotados y firmados: son objetos completos, con un mensaje explicativo y una firma gpg. Como nos gusta mucho firmar por motivos de seguridad, vamos a usar estos últimos.

Para crear tags firmados por defecto, escribe el siguiente comando en la consola Git Bash. Sólo tendrás que hacerlo una vez: git config --global tag.gpgSign true
Para crear un tag, nos aseguraremos de que el HEAD esté sobre el commit en el que queremos actuar, y escribiremos este comando: git tag -m "Mensaje explicativo de lo que ha pasado" nombre_tag
Hemos llegado a la conclusión de que los administradores de la sala de juegos nos van a pedir regresar al punto de partida en más de una ocasión. En vez de recordar el chorro de números y letras del commit inicial del repositorio, podríamos asociarle un tag para volver a él siempre que haga falta. Abre la consola en el repositorio, y procedamos:

  1. Retrocede al primer commit, que podrás ver mediante git log: git checkout 1A2B3C4D…
  2. Escribe o copia y pega el siguiente comando: git tag -m "Reglas originales de la sala sin modificar" inicial
  3. En la ventana que aparece, escribe la contraseña de tu clave GPG para firmar el tag.
  4. Regresa al commit más reciente: git checkout master
  5. Vuelve al commit inicial, esta vez usando el tag: git checkout inicial
  6. Regresa nuevamente al commit más reciente, ya que lo utilizaremos como punto de partida en el siguiente ejercicio.
  7. Utiliza este comando para conocer todos los tags que contiene un repositorio. Si son muchos, puede ser necesario pulsar la q para salir: git tag --list

Cómo restablecer y limpiar un repositorio

A veces podemos cometer errores terribles que tiren por los suelos todo nuestro trabajo y nos hagan perder horas y horas de nuestro tiempo intentando dejar las cosas como estaban. Por suerte, Git ya sabe cómo estaban las cosas en el commit más reciente (o en el commit hacia el que apunte el HEAD), por lo que nos va a ahorrar tiempo y situaciones incómodas.
El comando git reset devuelve los archivos del repositorio a su estado original, como si no los hubiéramos manipulado después del commit, pero no borra archivos sobrantes.
El comando git clean, por su parte, borrará todos aquellos archivos que no pertenecen al repositorio. Por ejemplo, el resultado de compilar un programa. Para simplificar, los usaremos con algunos modificadores extra.
En el siguiente ejercicio, vamos a convertir el repositorio de reglas de la sala en un cajón de sastre, y después vamos a arreglarlo para que quede como si nunca hubiese ocurrido nada. Prepara la consola, y comencemos!

  1. Abre el archivo de reglas de la sala con el bloc de notas. Selecciona todo su contenido, y bórralo con la tecla suprimir. Guarda y cierra.
  2. Copia dentro del repositorio lo que quieras: dos o tres canciones, varias fotos, algún programa que te guste…
  3. En la consola, utiliza el comando git status. Fíjate en lo que nos dice: el archivo de reglas ha cambiado, y hay un montón de archivos sin seguimiento.
  4. Ejecuta el siguiente comando: git clean -d -f -x
  5. Observa lo que ha ocurrido. Todos los archivos que copiaste en el paso 2 ya no están.
  6. Ejecuta el comando git status otra vez. Ahora nos dirá que el archivo de reglas ha cambiado, pero nada más.
  7. Ejecuta el siguiente comando: git reset --hard
  8. Abre el archivo de reglas con el bloc de notas. Observa que las reglas han vuelto a su sitio, como si nunca las hubieras borrado.

Creación de ramas en Git

Hasta ahora, al trabajar con repositorios, lo único que hemos hecho es agregar commits. Los commits se han apilado unos sobre otros, contando una historia. Podemos imaginarnos esta pila de commits como el tronco de un árbol. Para simplificar, un repositorio Git es un árbol muy poco desarrollado en el que sólo hay ramas. No tenemos hojas, ni flores, ni frutos, sólo ramas. El tronco, por increíble que parezca, también es una rama, y su commit inicial es la «raíz» del árbol.
Las ramas se emplean normalmente para hacer cambios experimentales que no queremos que afecten al desarrollo principal hasta más tarde. Cada rama tiene un punto de partida, situado en un lugar de otra rama, y va evolucionando aparte. Cuando el cambio experimental funciona, se puede fusionar con la rama principal para que forme parte del desarrollo estándar.
Para crear ramas, utilizaremos el comando git branch. Para viajar a ellas, emplearemos el comando git checkout. En el siguiente ejercicio, será necesario crear un repositorio nuevo y hacer varios commits. Consulta los apartados anteriores si necesitas refrescar alguna de estas cosas.
Los miembros del equipo de NVDA en español están hambrientos después de pasarse meses sin comer mientras traducían el libro de formación de PowerPoint. Para saciarse, han decidido comer una ensalada, y quieren que tú redactes una lista de la compra con los ingredientes necesarios. Para ello, debes crear un repositorio y hacer varios cambios en la lista hasta que todos estén satisfechos.

  1. En tu carpeta de repositorios, crea un nuevo repositorio Git llamado lista_compra.
  2. Agrega un fichero de texto llamado ensalada.txt con las siguientes líneas. Deja un par de líneas en blanco entre cada una. Esto último es importante para que más adelante no surjan conflictos:

0,5 kg de lechuga
6 tomate
6 pepino
1 botella de aceite
1 botella de vinagre
1 paquete de sal
1 lata de aceitunas sin hueso
1 lata de maíz

  1. Haz tu primer commit con estos datos.
  2. Cambia la primera línea para que haya 1 kg de lechuga, y vuelve a hacer commit.

Llegados a este punto, parecen satisfechos, pero deciden hacer un experimento y echar pollo crujiente a la ensalada. Para ello, vamos a utilizar una rama independiente, porque no queremos que nuestra ensalada actual se vea perjudicada en caso de que algo salga mal.

  1. Crea una nueva rama llamada pollo. Para ello, ejecuta el siguiente comando: git branch pollo
  2. A continuación, cambia el head del repositorio para comenzar a escribir en esa rama: git checkout pollo
  3. Abre el archivo ensalada.txt. Al final del mismo, deja una línea en blanco y escribe: 1 filete de pollo empanado
  4. Guarda el archivo y haz commit.
  5. Regresa a la rama master: git checkout master
  6. Abre el fichero de texto y léelo. Comprobarás que el filete de pollo no está. Quédate en la rama master, ya que partiremos de ahí en nuestra siguiente actividad.

El comando rebase

Cuando hacemos un experimento en una rama independiente, corremos el riesgo de quedarnos anticuados. El desarrollo principal puede continuar, y pueden cambiar cosas que nos afecten. Para prevenir esta situación, tenemos a nuestra disposición los comandos merge y rebase. El comando merge fusiona los cambios de una rama en otra, ordenando los commits cronológicamente. El comando rebase, en cambio, modifica el punto de partida de nuestra rama para que nuestro trabajo sobre esa rama siga quedando en lo alto del historial de commits. En el ejemplo anterior del árbol, rebase «arranca» la rama del tronco y la ingerta más arriba. Una buena forma de saber dónde se han situado nuestros commits es con el comando git log, que ya vimos antes. Ahora, continuemos preparando nuestra ensalada. Queremos experimentar añadiendo pollo, pero sobre las modificaciones más recientes, y no sobre la ensalada del principio:

  1. Abre el fichero ensalada.txt.
  2. Cambia la primera línea para que diga 2 kg de lechuga. Guarda y haz commit.
  3. Cambia la línea de las latas de aceitunas para que sean 2 en vez de una. Vuelve a guardar y hacer commit.
  4. Cambia a la rama pollo. Para ello, utiliza este comando: git checkout pollo
  5. Abre el fichero de texto. Comprobarás que todo está como antes de empezar este ejercicio. El filete de pollo se encuentra abajo del todo.
  6. Cambia la línea para que haya 2 filetes de pollo en vez de uno. Guarda y haz commit.
  7. Usa el comando rebase para introducir todos los cambios de la rama master dentro de nuestra rama pollo: git rebase master
  8. Abre el fichero ensalada.txt de nuevo. Observa lo que ha ocurrido. Conservamos los filetes de pollo, pero ahora hay 2 kg de lechuga y 2 latas de aceitunas.
  9. Ejecuta el comando git log. Mira cómo han quedado los commits.
  10. Vuelve a la rama master: git checkout master

El comando merge

Cuando ya hemos terminado de experimentar en una rama independiente, si los cambios han salido bien, hay que fusionarla en la principal para que nuestros valiosos aportes contribuyan con lo que se esté desarrollando en ese repositorio. Para ello, tenemos a nuestra disposición el comando merge. Merge, a diferencia de rebase, toma todos los commits de la rama y los fusiona con los commits de la otra rama. De esta forma, hay commits cuya presencia es visible en varias ramas, o en una rama y el tronco del árbol, según lo apliquemos. Demostremos su funcionamiento en el siguiente ejercicio.
Mientras preparábamos la lista de la compra con los ingredientes necesarios para hacer una ensalada, ha venido una pandemia que ha activado el estado de alarma en todo el país y ha puesto a todos sus habitantes en cuarentena. Debemos preparar todo lo necesario para no salir de casa nunca más, y para ello haremos otra lista de la compra.

  1. Asegúrate de que estás en la rama master. Crea un fichero de texto nuevo, llamado hogar.txt.
  2. En su interior, escribe la siguiente línea: 100 kg de papel higiénico
  3. Guarda los cambios y haz commit.
  4. Abre el fichero ensalada.txt. Comprueba que los filetes de pollo no están.
  5. Fusiona los cambios de la rama experimental. Para ello, usa este comando: git merge pollo
  6. Si es necesario, introduce la contraseña de tu clave GPG. La acción merge suele generar un nuevo commit.
  7. Comprueba que ahora los filetes de pollo sí están, aunque sigues en la rama master.
  8. Utiliza el comando git log y observa cómo han quedado los commits.

Algunas notas de interés

Cuando hacemos merge, la rama desde la que tomamos cambios no se elimina. Podemos seguir trabajando en esa rama, seguir trabajando en master, y llamar a merge y rebase tantas veces como sea necesario. Para eliminar una rama, se puede usar el comando git branch -d. Por ejemplo: git branch -d pollo
No obstante, en esta serie de tutoriales no trataremos la eliminación de ramas, tags o commits.

Resolución de conflictos

En ocasiones nos vamos a encontrar situaciones que los comandos reset y clean no van a poder arreglar. Por ejemplo, imaginemos que hacemos un commit cambiando un par de líneas de un archivo, y cuando nos descargamos los cambios más recientes del servidor, descubrimos que otra persona se nos ha adelantado y ha manipulado las mismas líneas del mismo archivo. Aunque Git es relativamente inteligente, hay cosas que se le escapan, y esta es una de ellas. Afortunadamente, en la consola se nos indicará qué ha salido mal y qué podemos hacer para remediarlo. Los comandos varían, dependiendo de si estamos haciendo merge o rebase.
En el siguiente ejercicio, vamos a utilizar el repositorio de la lista de la compra para provocar un conflicto. A continuación, vamos a resolverlo.

  1. Estando en la rama master, modifica el fichero ensalada.txt. Indica que quieres 6 kg de lechuga. Guarda y haz commit.
  2. Cambia a la rama pollo.
  3. Edita el fichero ensalada.txt, modificando la línea correspondiente para que haya 7 kg de lechuga. Guarda y haz commit.
  4. Regresa a la rama master. A continuación, ejecuta la fusión de ramas con este comando: git merge pollo
  5. Observa lo que ha ocurrido. La fusión automática ha fallado, y el fichero de texto de la ensalada se ha quedado en un estado inconsistente. Al abrirlo, vemos algo como esto:

<<<<<<< HEAD
6 kg de lechuga
=======
7 kg de lechuga
>>>>>>> master
pollo

Para resolver este conflicto, debemos elegir la línea que sea más adecuada para lo que queremos conseguir. En ocasiones, no basta con seleccionar una de las dos opciones que se nos presentan, hay que tomar cambios de ambos lados y crear un cambio totalmente nuevo. Para facilitar la tarea, decidimos quedarnos con la segunda opción, 7 kg de lechuga.

  1. Elimina la línea que tiene 7 signos <, la que tiene 7 signos =, la que tiene 7 signos > y la que corresponde a 6 kg de lechuga. Guarda y cierra.
  2. Añade los cambios para hacer commit: git add --all
  3. Si estuvieras haciendo rebase, en este punto tendrías que ejecutar el comando git rebase --continue. Como estamos haciendo merge, el comando al que llamaremos será commit: git commit -m "conflicto resuelto"

¡Mucho cuidado! Si hacemos commit o continuamos con la operación de rebase sin haber resuelto los conflictos, Git no lo sabrá y pensará que los hemos arreglado. El sistema de descarga de complementos de la comunidad internacional de NVDA estuvo caído durante varias semanas por culpa de un conflicto que se dejó sin resolver. En medio del archivo get.php, había líneas <<<<<<< HEAD, ======= y >>>>>>> master, algo que al intérprete PHP no le sentó demasiado bien.

Introducción a GitHub

GitHub es una plataforma web colaborativa construida alrededor de Git y todo lo que nos ofrece. Los usuarios pueden publicar allí sus repositorios, interactuar con otros usuarios, corregir fallos o aplicar mejoras en otros proyectos, y aceptar cambios en su propio código procedentes de otras personas. Si bien es cierto que GitHub es la plataforma más popular de este tipo, no es la única. Tenemos también GitLab o BitBucket. Todas ellas tienen características en común, pero en cada una existen pros y contras. Por ejemplo, GitLab se puede instalar en cualquier servidor, mientras que para hacer eso con GitHub hay que pagar una suscripción de empresa.
La interfaz web de GitHub, a priori, puede ser bastante compleja. Accesible, por supuesto, pero compleja. El hecho de que sólo esté en inglés tampoco lo pone nada fácil. Por suerte, y para agilizar las cosas, tenemos a nuestra disposición un importante aliado: la barra de direcciones del navegador. Las direcciones son muy sencillas de construir, como veremos enseguida.

Usuarios y repositorios

En GitHub, cada usuario u organización tiene una dirección propia y única, que se corresponde con el nombre de usuario elegido. Cuando visitamos el perfil de un usuario, podemos ver qué repositorios tiene, sus últimas contribuciones a otros proyectos, su actividad y todo lo que nos quiera contar de sí mismo en los distintos campos del perfil (nombre, país de origen, biografía…). Pongamos algunos ejemplos.

Como se puede ver, es muy fácil acceder al perfil de un usuario conociendo su nombre. Por este motivo, y aunque es posible, no se recomienda cambiar el nombre de usuario. Lo ideal es que se quede como está para siempre.
Si queremos ver todos los repositorios que tiene, añadimos el sufijo ?tab=repositories. La dirección de nvda-es podría quedar así: https://github.com/nvda-es?tab=repositories
Para acceder a un repositorio, se incluye el nombre de dicho repositorio después del nombre de usuario, intercalando una barra entre ellos. Este sería el repositorio de NVDA: https://github.com/nvaccess/nvda
Al acceder a un repositorio, veremos un montón de opciones. Una de las que más nos puede interesar es el archivo léame, que los desarrolladores suelen situar en la raíz del repositorio para que GitHub lo muestre. Lo encontraremos después de un encabezado de nivel 2, que suele llamarse Readme.md. En el repositorio del lector de pantalla Habla, el contenido del archivo readme.md es fácilmente identificable porque está en español, pero no es lo habitual. El sufijo md, por su parte, indica que el archivo está escrito en sintaxis Markdown, que luego GitHub se encarga de traducir a HTML cuando cargamos la página.

Descarga del código de un repositorio dentro del ordenador

GitHub nos permite descargar el código fuente alojado en un repositorio de distintas maneras. La más común para quienes no usan Git es descargar un archivo zip con los contenidos. Sin embargo, esto no nos va a permitir ver el historial de los cambios, hacer un seguimiento del trabajo realizado o colaborar por nuestra cuenta. En esta ocasión, vamos a aprender sólo a descargar un repositorio, pero sin colaborar enviando cambios. Más adelante veremos cómo clonar por SSH, hacer un fork y enviar nuestros propios commits.
Para descargar un repositorio, utilizaremos el comando clone. Su sintaxis es la siguiente: git clone URL_del_repositorio

Ejercicio: descarga del código fuente de NVDA

NVDA es un proyecto bastante activo, por lo que nos servirá para descargar el código fuente y actualizarlo cuando alguien haga cambios. Para descargar el código fuente de NVDA, sigue estos pasos:

  1. Abre la consola Git Bash.
  2. Navega a la carpeta que contiene tus repositorios. Por ejemplo: cd /c/git_repos
  3. Clona el repositorio de NVDA: git clone https://github.com/nvaccess/nvda
  4. Con el explorador de archivos, entra a tu carpeta de repositorios. Observarás una nueva carpeta, llamada NVDA. Entra en ella y explora todo lo que contiene.
  5. Desde Git Bash, entra en el nuevo repositorio: cd nvda
  6. Observa el historial de cambios con git log. Enumera también los distintos tags disponibles. ¿Qué representa cada uno?
  7. Utiliza el comando git branch list --remote para enumerar las ramas disponibles. Son muchas, por lo que puedes tener que pulsar la q para salir.
  8. Cambia a la rama beta y estudia el historial devuelto por git log.
  9. Vuelve a la rama master.
  10. Deja la consola abierta, seguiremos trabajando con ella.

Submódulos

A veces, un proyecto es tan complejo y tiene tantos equipos de desarrollo, que lo ideal es dividir sus componentes entre varios repositorios. De hecho, el proyecto puede depender de repositorios de terceros con los que no tenemos relación alguna. Sin embargo, es importante mantenerlos conectados entre sí. Un submódulo es un repositorio que se aloja en una carpeta dentro de otro repositorio. En esta guía no aprenderemos a crearlos, pero sí a descargarlos y mantenerlos actualizados. Vamos a completar la descarga del código fuente de NVDA. Para ello, primero vamos a inicializar los submódulos, y luego a descargarlos todos a la vez. La lista de submódulos de un repositorio se puede encontrar en el archivo .gitmodules, dentro de la carpeta raíz. Es perfectamente legible con editores de texto plano, como el bloc de notas.

Ejercicio: descarga de los submódulos de NVDA

  1. Estando en el repositorio de NVDA, ejecuta el siguiente comando para inicializar los submódulos: git submodule init
  2. Con el explorador de archivos, accede a la carpeta include. Verás muchas subcarpetas vacías, sin nada en su interior.
  3. Descarga los submódulos de NVDA: git submodule update
  4. Observa lo que ha ocurrido dentro de estas carpetas.
  5. Cierra todo. Tendrás que esperar varios días antes de hacer el siguiente ejercicio.

Cómo mantenerse actualizado

Ahora que tenemos descargado un repositorio, es importante mantenerlo al día con los últimos cambios. Podríamos borrarlo y clonarlo otra vez, pero este enfoque no parece muy práctico. Por suerte, Git lo tiene todo previsto. Vamos a conocer el comando git pull.
Git pull busca los cambios más recientes del origen remoto asociado a la rama actual, los descarga, los inserta en la base de datos del repositorio local y los integra en nuestro directorio de trabajo, haciendo avanzar el HEAD o cursor de posición. Gracias a git log, podremos estudiar el historial y saber qué ha cambiado desde la última vez que actualizamos o clonamos. Vamos a actualizar NVDA para recibir los últimos commits de la rama master. Se recomienda esperar unos días para poder descargar cambios.

Ejercicio: mantener NVDA actualizado

  1. Abre Git Bash y navega a la carpeta del repositorio de NVDA. Por ejemplo: cd /c/git_repos/nvda
  2. Actualiza el repositorio: git pull
  3. Si ves el mensaje «Already up to date», ya tienes los últimos cambios, por lo que puedes ir directamente al paso 6. Si no, sigue con el paso 4.
  4. Comprueba qué ha cambiado con el comando git log.
  5. Mantén actualizados los submódulos. Los comandos git submodule sync, git submodule init y git submodule update pueden ayudarte, en ese orden. Normalmente los submódulos no cambian, pero podrían hacerlo en cualquier momento.
  6. Repite el ejercicio periódicamente para mantenerte siempre al día. Si el código fuente de NVDA no te llama la atención, no dudes en hacerlo con otro repositorio que sí lo haga.

Creación de una cuenta en GitHub

Como dijimos anteriormente, GitHub es la plataforma colaborativa de repositorios Git más popular y conocida. Es hora de hacerse una cuenta allí y mostrar el fruto de nuestro trabajo a la comunidad.

  1. El primer paso es entrar a la página de inicio de GitHub, buscar un enlace llamado «Sign up» y pulsarlo. Asumiremos que la web está en inglés, pero para algunos puede ser más cómodo traducirla con traductores automáticos o complementos de NVDA.
  2. Llegaremos a un formulario donde hay un solo campo, en el que tendremos que introducir una dirección de correo válida y que no se esté usando todavía. Lo rellenamos y pulsamos el botón Continue. Se recomienda que dicha dirección sea la misma que tenemos configurada en Git y la clave gpg.
  3. A continuación, veremos exactamente el mismo formulario con el campo de correo ya rellenado, y con un campo para introducir una contraseña. Lo ideal es que esta contraseña sea fuerte, y contenga al menos un número, una letra mayúscula, un símbolo, una letra minúscula, y que su longitud sea de 8 caracteres. Tras escribir una contraseña suficientemente fuerte, volvemos a pulsar en Continue.
  4. Llegamos al mismo formulario, listo para agregar nuestro nombre de usuario. Este es nuestro nick dentro de la plataforma. Formará parte de la barra de direcciones cuando la gente visite nuestro perfil y nuestros repositorios. Por ese motivo, hay que elegirlo bien y, aunque se puede, no debería cambiarse nunca. Lo rellenamos y pulsamos Continue una vez más.
  5. Aparece un campo más donde se nos solicita consentimiento para recibir promociones por correo. Escribimos una n y seguimos.
  6. Ahora llega el momento de resolver un captcha, que afortunadamente tiene alternativa auditiva con mensajes en español. Tras escribir los números que escuchemos, verificamos la validez de la respuesta y pulsamos el botón «Create account». Si el botón no aparece en modo exploración, se puede activar el modo foco y buscarlo tabulando por la ventana.
  7. GitHub todavía no confía en nosotros, por lo que nos pedirá un código numérico de 6 cifras que llegará por correo electrónico. Basta con pegarlo en el campo correspondiente para que siga adelante y muestre el siguiente paso automáticamente.
  8. Llegamos a una pantalla en la que GitHub pregunta por nuestros intereses. Rellenarla es opcional y no afectará a nuestra experiencia, por lo que elegiremos el enlace «Skip personalization» para saltar directamente al panel de control de nuestra cuenta.

Importación de las claves ssh y gpg

Ahora ya tenemos una cuenta en GitHub, ¡primer paso conseguido! Sin embargo, aún no queda muy claro cómo se va a comunicar Git con ella. Y firmar los commits y los tags, aunque es útil, tampoco va a ayudar a GitHub a que marque nuestro trabajo como verificado… a menos que agreguemos allí nuestras claves. Vamos a ello.

Importación de la clave ssh

  1. En la web de GitHub, teniendo la sesión iniciada, busca un botón llamado «Open user navigation menu». Estará contraído, expándelo. Si no encuentras el menú expandido, busca un diálogo modal justo al final de la página y pulsa intro, o activa el modo foco y pulsa tabulador.
  2. Activa un elemento de menú llamado «Settings».
  3. Busca un enlace llamado «SSH and GPG keys» y púlsalo.
  4. Pulsa el enlace «New SSH key».
  5. Verás un formulario con tres campos. En el campo Title, da un nombre a tu clave ssh. Si es la única que tienes, algo como «mi clave ssh» puede ser más que suficiente.
  6. En el cuadro combinado «Key type», deja el valor por defecto, «Authentication key».
  7. En el explorador de archivos, abre tu carpeta de usuario y entra a la subcarpeta .ssh (empieza con un punto).
  8. Abre el archivo id_ed25519.pub con un editor de texto y copia su contenido. Esta es la parte pública de la clave, no tengas miedo de compartirla. Está pensada exactamente para eso.
  9. En GitHub, pega lo que has copiado en el campo key, y pulsa el botón «Add SSH key». Si se te solicita, introduce tu contraseña para terminar.

Ahora, Git podrá comunicarse desde la consola con GitHub. Gracias a la clave, GitHub sabrá que somos nosotros sin tener que introducir usuario ni contraseña. Vamos con la clave gpg.

Importación de la clave GPG

Agregar una clave GPG a nuestra cuenta se parece mucho a lo que acabamos de hacer con la clave SSH. Sin embargo, obtener la clave pública no es tan sencillo en este caso. Deberemos recurrir a la consola Git Bash:

  1. Obtén el identificador único de tu clave. En el capítulo 1 de esta serie se explica cómo hacerlo. Por ejemplo: 1A703CB73B311567
  2. Con el identificador ya preparado, exporta la parte pública en un archivo: gpg --armor --export 1A703CB73B311567 > miclave.gpg
  3. Abre el archivo miclave.gpg con un editor de texto, y copia todo su contenido al portapapeles.
  4. En GitHub, en la pantalla de gestión de claves ssh y gpg, pulsa el enlace «New GPG key».
  5. Aparecerá un formulario con dos campos. En el primero, escribe un título para tu clave. En el segundo, pega lo que has copiado y pulsa el botón Add GPG key. Si se te solicita, introduce tu contraseña para finalizar.

Como paso opcional, se recomienda activar el Vigilant mode. Para ello, simplemente hay que marcar la casilla que está en la página de gestión de claves.

Comprobación de que las comunicaciones funcionan

Para comprobar que podemos comunicarnos correctamente con GitHub, ejecutaremos el siguiente comando desde la consola: ssh [email protected]
Como es la primera vez que conectamos con este servidor, el cliente ssh preguntará si confiamos en él. Para decirle que sí, escribimos yes y pulsamos intro. A continuación, ssh preguntará por nuestra contraseña de la clave. Al escribir la contraseña, el resultado no se reflejará en pantalla, por lo que parecerá que no estamos escribiendo nada. Sin embargo, sí lo estamos haciendo.
Si todo ha ido bien, GitHub nos saludará diciéndonos que no nos puede ofrecer una consola, pero incluirá nuestro nombre de usuario en el saludo, indicando que la conexión se ha hecho bien.

Creación del primer repositorio en GitHub

En este ejercicio, crearemos nuestro primer repositorio en GitHub, lo clonaremos, haremos cambios en él y los publicaremos.

  1. En la página web de GitHub, busca un botón contraído llamado «Create new…» y actívalo.
  2. Pulsa intro sobre «New repository». Llegarás al formulario de creación de repositorios.
  3. El primer campo, un botón desplegable, sirve para indicar quién será el propietario del repositorio. Viene bien si pertenecemos a alguna organización que permita crearlos, pero ahora mismo no sirve para nada, por lo que es mejor ignorarlo.
  4. En el campo Repository name, introduce el nombre del repositorio. Debe ser un nombre corto, sencillo, fácil de recordar y sin espacios. Por ejemplo, por ser el primero, puedes llamarlo pruebas.
  5. El siguiente campo permite indicar una breve descripción, y es opcional. Escribe «Mi primer repositorio en GitHub».
  6. A continuación, encontrarás dos botones de opción que indican si el repositorio es público o privado. Antes, los repositorios privados eran de pago, pero ahora son gratuitos, al igual que los públicos. Elige la opción con la que te sientas más cómodo.
  7. Bajo el encabezado «Initialize this repository with:», marca la casilla «Add a README file».
  8. Finalmente, pulsa el botón «Create repository».

Ahora, tenemos en nuestra cuenta de GitHub un repositorio. Dentro de él, se encuentra un único archivo: readme.md. Vamos a clonar dicho repositorio. En los próximos pasos, se asume que el nick elegido en GitHub es usuario. Las URLs para clonar repositorios por SSH son muy distintas a las que vimos en el capítulo anterior, pero terminan exactamente igual. Por tanto, será fácil familiarizarse con ellas.

  1. Abre la consola Git Bash y navega a tu carpeta de repositorios.
  2. Clona tu nuevo repositorio con el siguiente comando: git clone [email protected]:usuario/pruebas.git
  3. Introduce la contraseña asociada a tu clave ssh, y espera a que se descargue el repositorio.
  4. Con el explorador de archivos, entra al repositorio pruebas. Abre el archivo readme con el bloc de notas.
  5. Borra todo el contenido. Escribe algunas líneas presentándote y cuenta por qué quieres aprender a usar Git.
  6. Desde la consola, entra al repositorio. Haz commit para registrar los cambios que has realizado. Observa que la rama en la que te encuentras no se llama master, sino main. Tendrás que acostumbrarte a esta nomenclatura siempre que hagas nuevos repositorios desde la web de GitHub.
  7. Envía los cambios al servidor. Para ello, utilizarás la acción contraria a git pull que vimos anteriormente: git push
  8. Escribe la contraseña de tu clave ssh, y espera a que se suban los cambios.
  9. Visita tu repositorio en la web: https://github.com/usuario/pruebas. Si es un repositorio privado, tendrás que iniciar sesión para poder verlo. Observa el archivo readme, que ya tiene los cambios que has hecho en tu disco duro.

Configuración del perfil y otros aspectos de la cuenta

Ahora que ya tenemos una cuenta, podemos empezar a colaborar con los demás. Sin embargo, es importante que nos conozcan para que puedan confiar en nosotros. Al igual que en muchas redes sociales, en GitHub se pueden tener seguidores, seguir a otras personas, y modificar ciertos datos en el perfil.
Teniendo la sesión iniciada, iremos al botón «View profile and more» y, tras pulsarlo, entraremos en «Your profile». Se puede llegar a este mismo sitio mediante la barra de direcciones: https://github.com/usuario
El perfil estará vacío. Buscamos un botón llamado «Edit profile» y lo pulsamos.
En la pantalla que se despliega, tenemos los siguientes campos, todos opcionales:

  • Name: aunque puede estar vacío, también puede incluir un pseudónimo o el nombre completo. Si pretendes usar tu cuenta en el mundo profesional o que la gente sepa quién hay realmente detrás de las colaboraciones, escribe tu nombre completo en este campo.
  • Bio: aquí puedes contar más sobre ti. Quién eres, a qué te dedicas, qué esperas conseguir, etc. Da igual que lo hagas en inglés o en español.
  • Company: si trabajas en una empresa o tienes tu propia empresa, puedes rellenar este campo.
  • Location: en este campo puedes escribir tu ubicación. No pongas una dirección muy precisa, recuerda que es público y todo el mundo lo ve. Un ejemplo podría ser «Madrid, España».
  • Website: si tienes una página web propia, pega la URL de la misma aquí.
  • Twitter username: si tienes cuenta en Twitter, puedes escribir aquí el nombre de usuario.

Al finalizar, pulsa el botón Save para guardar los cambios.
El formulario que acabamos de ver permite editar el perfil de una manera rápida y sencilla. Sin embargo, podemos llegar a un formulario equivalente con algunos campos más desplegando el botón «View profile and more» y eligiendo «Settings». Desde la barra de direcciones, se puede llegar al mismo sitio mediante esta URL: https://github.com/settings/profile
Aquí, aparte de los campos anteriores, tenemos los siguientes:

  • Public email: si queremos mostrar públicamente una dirección de correo para que la gente contacte con nosotros, podemos elegirla en el cuadro combinado. Por defecto el correo es privado, así que primero hay que levantar la restricción en https://github.com/settings/emails. Basta con desmarcar la casilla «Keep my email addresses private» y pulsar «Save email preferences».
  • Profile picture: este botón desplegable, situado debajo de «Save profile», permite subir una foto de perfil. Tras pulsarlo, elige «Upload a photo…» y carga el archivo que corresponda.
  • Include private contributions on my profile: si trabajas con repositorios privados, puedes marcar esta casilla para que todo el mundo vea que, aunque tus colaboraciones no son públicas, tienes actividad. Pulsa el botón «Update contributions» si modificas esta casilla.
  • Available for hire: marcando esta casilla, indicas a GitHub que estás disponible para que alguien te contrate en su empresa. Es una forma más de buscar trabajo. Pulsa el botón «Save jobs profile» si cambias el valor de esta casilla.
  • Preferred spoken language: por defecto, el valor de este cuadro combinado es «No preference» (sin preferencia). Configúralo en inglés o español para indicar qué idioma prefieres y qué repositorios pueden ser más relevantes para ti. Pulsa «Save Trending settings» al acabar.

Si tienes una cuenta de pago o alcanzas ciertos logros, GitHub lo mostrará en el perfil, aunque también se puede ocultar desde esta pantalla. Algo que también muestra, y que puede ser un requisito indispensable a la hora de unirse a algunas organizaciones, es si la verificación en dos pasos está activada. La verificación en dos pasos es una acción extra a la hora de iniciar sesión que mejora la seguridad. Para configurarla, busca entre las opciones una llamada «Security», o directamente entra en https://github.com/settings/security
Después, pulsa el enlace «Enable two-factor authentication» y sigue los pasos que se muestran. Puedes configurar un número de teléfono para recibir mensajes de texto, o una app en el móvil que genere códigos. Más adelante podrás añadir más métodos, como llaves de seguridad hardware, códigos de recuperación o números alternativos. La verificación en dos pasos es algo muy usado en muchos servicios, por lo que no profundizaremos en ella en este tutorial.

Introducción a las incidencias

Una incidencia es un excelente mecanismo que nos permite contactar públicamente con un desarrollador e informar de un problema o sugerir una característica para un proyecto. En este tutorial haremos un uso muy básico de ellas, sin emplear etiquetas, asignar revisores ni otras funciones avanzadas.

Exploración de incidencias existentes

Antes de abrir una incidencia, lo mejor que se puede hacer es comprobar si lo que queremos solicitar ya se ha solicitado. De esa forma, todo está más organizado y facilitamos la vida a otros colaboradores. Cuando entramos a cualquier repositorio, hay un enlace que nos permite llegar a las incidencias. Dicho enlace se llama «Issues», y está en una lista dentro de un punto de referencia etiquetado como «Repository». Como siempre, podemos usar la barra de direcciones si nos resulta más cómoda: https://github.com/usuario/repositorio/issues
En la página de incidencias, hay un buscador que nos permite filtrarlas. Bajo el botón «New issue», que veremos en el siguiente apartado, hay dos enlaces especialmente interesantes: Open y Closed. Dichos enlaces tienen un número delante, indicando cuántas incidencias siguen aún abiertas y cuántas se han cerrado. Por defecto, se muestran las incidencias abiertas.
Tras más botones que nos permiten filtrar y ordenar de distintas maneras, llegamos a una agrupación que contiene las incidencias propiamente dichas. Veremos su estado (open o closed), el asunto de la incidencia, el usuario que la abrió y cuánto tiempo hace de eso. Pulsando en el asunto, entraremos a la incidencia.
Dentro de una incidencia, nos interesa un encabezado de nivel 2 llamado «Comments». Bajo ese encabezado, los comentarios de cada usuario van precedidos de encabezados de nivel 3. El primer comentario contiene la descripción de la incidencia.
Pasados todos los comentarios, cabe destacar un cuadro de edición, que veremos porque tenemos la sesión iniciada. Independientemente de que la incidencia esté abierta o cerrada, podemos escribir comentarios aquí, y publicarlos pulsando el botón «Comment». El botón Examinar que hay justo encima nos permite adjuntar pequeños archivos, útiles para complementar la incidencia. Por ejemplo, logs de NVDA en modo depuración.
El campo de comentario admite texto plano, texto en formato Markdown, e incluso podemos mencionar a otras personas si conocemos su nombre de usuario. Para ello, se antepone el símbolo arroba (@). Es importante respetar el idioma de la incidencia y escribir según corresponda: en inglés, en español, etc.
Por defecto, si comentamos en una incidencia, recibiremos por correo electrónico todas las actualizaciones relacionadas con la misma. Podemos responder a esos correos para añadir más comentarios.

Ejercicio: exploración de una incidencia

  1. Abre el repositorio del empaquetador de complementos.
  2. Busca el enlace «Issues» y actívalo para cargar la página de incidencias.
  3. Activa el enlace que carga la página de incidencias cerradas.
  4. Busca una incidencia titulada «Preparación para la revisión de la comunidad internacional» y entra en ella.
  5. Lee los diferentes comentarios y familiarízate con la estructura.

Creación de una nueva incidencia

Si no encontramos ninguna incidencia en la que se explique el problema o sugerencia que tenemos, es momento de crear una nueva. Para ello, en la página de incidencias del repositorio en cuestión, pulsamos el botón «New issue». Aquí pueden pasar dos cosas distintas:

  • El repositorio tiene plantillas de incidencia: si sólo dispone de una plantilla, veremos que el cuadro de edición principal tiene algunos datos e instrucciones para rellenarlo. Si tiene varias, GitHub nos pedirá elegir una. Por ejemplo, NVDA tiene una plantilla para sugerir características y otra para informar sobre fallos.
  • El repositorio no tiene plantillas: el foco aterrizará directamente en el campo Title, y el campo de comentario estará vacío.

Asumiendo el segundo escenario, debemos dar título a la incidencia y explicar todo lo que podamos sobre ella en el campo de comentario. El título debe ser breve, sintetizando lo que ocurre. En el comentario, debemos explicar cómo reproducir la incidencia, bajo qué circunstancias ocurre, por qué es necesario solucionarla, etc. Cuando acabemos, pulsaremos el botón «Submit new issue».

Cierre de incidencias

Cuando la incidencia ya se ha resuelto, es momento de cerrarla. Pueden cerrar incidencias tanto las personas que las han creado, como los administradores del repositorio. Hay dos formas de cerrar una incidencia:

  • Desde la web. Se puede pulsar el botón «Close issue», o escribir un comentario y pulsar el botón «Comment and close».
  • Con un commit desde Git. Se puede incluir una palabra especial en el mensaje del commit junto con el número de incidencia, y GitHub la cerrará automáticamente cuando hagamos push. Para saber el número de una incidencia, podemos mirar la barra de direcciones teniendo la incidencia abierta. El número se sitúa después de /issue/ en la dirección. Por ejemplo: git commit -m "Se resuelven todas las solicitudes propuestas para superar la revisión. Fixes #5". Tanto fixes como closes son palabras válidas.

Ejercicio: creación de una incidencia

Si bien es cierto que podemos crear una incidencia en nuestro propio repositorio, comentar en ella y cerrarla, lo ideal es que este ejercicio se haga en grupo. Si no tienes ningún compañero con el que puedas hacerlo, sigue estos pasos en tu propio repositorio o, si te sientes preparado, en el repositorio de un proyecto que te guste.

  1. Abre el repositorio de algún compañero.
  2. Carga su página de incidencias. Si no hay muchas, explora tanto las abiertas como las cerradas.
  3. Pulsa el botón «New issue».
  4. Rellena el título y el comentario como prefieras, y pulsa «Submit new issue».
  5. Utiliza los comentarios para hablar con tu compañero, intercambiando preguntas y respuestas sobre el tema que se trata en la incidencia.
  6. Una vez hayáis acabado, cierra la incidencia o pide al administrador del repositorio que lo haga.

Gestión de orígenes remotos

Los orígenes remotos son lugares a los que se envían los cambios (comando push) o se descargan (comando pull) en un repositorio concreto. Un repositorio Git puede tener varios orígenes remotos, o incluso ninguno. Los repositorios que utilizamos en los primeros capítulos de este tutorial tienen 0 orígenes remotos. Los repositorios que clonamos de otro lugar, como GitHub, tienen un origen remoto, llamado origin. Para ver la lista de orígenes remotos, simplemente escribe git remote. Este comando devolverá los nombres de los orígenes, y sólo los nombres. Si, además, queremos las URLs asociadas a cada origen, escribiremos git remote -v. El comando git remote admite varios subcomandos y parámetros. Veamos los más importantes:

  • git remote add nombre URL: añade un nuevo origen remoto con el nombre y la URL especificados.
  • git remote remove nombre: elimina el origen remoto cuyo nombre hemos pasado.
  • git remote rename nombre_viejo nombre_nuevo: renombra un origen remoto.
  • git remote update: actualiza todos los orígenes remotos, descargándose sus cambios.

En el siguiente ejercicio, vamos a crear un repositorio completamente vacío en GitHub, y vamos a enviar el reglamento de la sala allí, para que esté bien seguro y no se pierda.

Ejercicio: importar un repositorio externo en GitHub

  1. Accede a la página web de GitHub.
  2. Crea un nuevo repositorio. En el campo nombre, escribe Reglas. En la descripción, escribe «Reglamento de la sala de juegos». Haz que el repositorio sea privado, y no marques la casilla de inicializar con un archivo readme, ni ninguna de las que tiene alrededor.
  3. Cuando termines de crearlo, abre la consola Git Bash. Navega al repositorio reglas, con el que trabajamos en los primeros capítulos.
  4. Añade como origen remoto el repositorio recién creado en GitHub: git remote add origin [email protected]:usuario/reglas.git
  5. Envía la rama al origen remoto. Como es la primera vez que lo hacemos, hay que asociarla: git push -u origin master
  6. Introduce la contraseña de tu clave ssh y espera a que terminen de subirse los cambios.
  7. Vuelve a la web de GitHub. Pulsa f5 para refrescarla, y observa lo que ha ocurrido. Deberías ver el fichero de reglas allí.

Ahora que hemos terminado de afianzar este concepto, es momento de hablar de pull requests.

Introducción a las pull requests

Una pull request (o solicitud de cambios) es una excelente forma de contribuir con el trabajo de otro autor. A grandes rasgos, el proceso que se realiza es el siguiente:

  1. Comprobar las pull requests existentes.
  2. Bifurcar el repositorio en nuestra cuenta.
  3. Clonar el repositorio.
  4. Crear una rama temática.
  5. Realizar cambios en esa rama.
  6. Enviar los cambios a GitHub.
  7. Abrir la pull request.
  8. Participar en la conversación hasta que el autor la fusione o la cierre.
  9. Estar pendiente de nuestra bifurcación por si hubiera que preparar más pull requests.

Veamos ahora todos los pasos en detalle.

Comprobar las pull requests existentes

Es posible que alguien haya intentado solucionar el problema que nosotros queremos corregir. Por ello, antes de hacer cualquier otra cosa, debemos echar un vistazo a las pull requests abiertas y cerradas que existen en el repositorio. Para llegar hasta allí, se puede pulsar el enlace «Pull requests» que hay en la página del repositorio, o utilizar el formato https://github.com/usuario/repositorio/pulls en la barra de direcciones.
La página con la lista de pull requests es similar a la de incidencias. De hecho, se parecen tanto que podemos buscar las pull requests abiertas y las cerradas igual que hacíamos con las incidencias.
Una pull request es similar a una incidencia. Tiene un comentario inicial explicando qué se ha hecho, varios comentarios de los colaboradores, y puede estar abierta o cerrada. Si está cerrada, puede ser por dos motivos: se ha fusionado o se ha rechazado. Las pull requests aceptadas tienen la palabra «merged» por algún sitio. Aparte de todo lo que comparten con las incidencias, en la página de cada pull request se puede encontrar un breve resumen indicando cuántos commits tiene y cuántos archivos han cambiado.
Si se añade el sufijo .patch a la barra de direcciones, aparecerán en texto plano todas las diferencias. El formato es el mismo que vimos con git show: las líneas precedidas con un guión se han eliminado, y las que llevan el signo + delante se han añadido.
Si no encontramos a nadie que haya hecho algo parecido a lo que pretendemos hacer, continuamos.

Bifurcar el repositorio en nuestra cuenta

Una bifurcación es un proceso que nos permite hacer una copia íntegra de un repositorio, con todas sus ramas y etiquetas, en nuestra cuenta. De esa forma, podemos tratarlo como si fuera nuestro. GitHub identifica los repositorios bifurcados con el texto «Forked from», seguido de la ruta al repositorio original. De esta manera, se sabe su lugar de procedencia. Para bifurcar un repositorio, accede a su página principal y busca un botón llamado «Fork». Cuando lo pulses y confirmes la acción, el repositorio aparecerá en tu cuenta de usuario y la página se actualizará para dirigirte allí.

Clonar el repositorio

Ahora que tenemos el repositorio alojado en nuestra cuenta, vamos a clonarlo para hacer modificaciones sobre él. Como nuestro objetivo es enviar cambios al servidor, lo clonaremos por ssh:

git clone [email protected]:nuestracuenta/repositorio.git

Crear una rama temática

Por defecto, el repositorio clonado estará en la rama master o main. Podríamos lanzar la pull request desde aquí, pero es algo que no interesa por varios motivos:

  • El autor puede mezclar cambios en master y hacer que nuestra copia quede obsoleta.
  • Sólo podríamos hacer una pull request, y no podríamos seguir hasta que quedase cerrada o fusionada.

Por ello, conviene crear una rama adicional y trabajar sobre ella.

La creamos con un comando como este. La llamaremos micambio: git branch micambio
Ahora, nos movemos hacia ella: git checkout micambio

Realizar cambios en esa rama

A la hora de hacer cambios, debemos buscar un objetivo concreto. No podemos ir corrigiendo cosas aquí y allá. Debemos evitar eso de «Ya que estoy, voy a arreglar esto también». Si queremos realizar varios cambios no relacionados entre sí, emplearemos varias ramas y pull requests. Si realizamos un mismo cambio que afecta a varias zonas del repositorio (por ejemplo en código, traducciones y documentación), haremos varios commits, uno por área afectada.
Como siempre, al acabar, añadimos los archivos modificados para hacer commit: git add --all
Finalmente, los confirmamos: git commit -m "Corregido un problema que impedía ajustar la cuadratura del círculo"

Enviar los cambios a GitHub

En el apartado anterior vimos una versión extendida del comando git push, que debemos usar siempre con las ramas nuevas. Este caso no será una excepción. Para enviar las modificaciones de la rama micambio, ejecutaremos un comando como este: git push -u origin micambio
GitHub creará la rama micambio en el servidor, y nos devolverá por consola la URL a la que debemos dirigirnos desde el navegador para hacer la pull request. Será algo similar a esto: https://github.com/micuenta/repositorio/pull/new/micambio

Abrir la pull request

Al visitar la URL devuelta en el apartado anterior, aterrizaremos en una página similar a la de creación de incidencias. Si la pull request contiene un sólo commit, GitHub intentará rellenar el título y la descripción con los contenidos del mensaje del commit, algo que no nos interesa el 99% de las veces. Al igual que sucedía con las incidencias, podemos encontrarnos campos de descripción que vienen previamente rellenos con una plantilla a la que nos tendremos que ajustar.
El título debe ser breve y descriptivo, transmitiendo lo necesario para que el autor sepa de qué trata la pull request que le estamos enviando. En la descripción podemos extendernos más, indicando qué se ha hecho en cada commit, por qué se ha hecho, qué beneficios aporta, si tiene alguna desventaja, etc. Se puede usar tanto texto plano como sintaxis Markdown, y mencionar a otros usuarios anteponiendo el signo arroba (@).
Cuando terminemos, pulsamos el botón «Create pull request». A partir de este momento, sólo nos queda esperar y prestar atención.

Participar en la conversación hasta que el autor la fusione o la cierre

Esta etapa es opcional. Dependiendo del autor, la importancia del cambio y las dudas de los colaboradores, puede no existir o durar mucho. El autor puede pedirnos que justifiquemos algún cambio, para lo que contestaremos por correo electrónico o en un comentario. También puede pedirnos que hagamos algún cambio, ya sea para corregir un fallo potencial, ajustar el código al estilo propuesto, o cualquier otra cosa. En este último caso, podremos hacer commit en nuestro repositorio local y ejecutar git push. Los cambios que hagamos en la rama de la pull request (en este caso, micambio) se reflejarán en la solicitud abierta.
La pull request puede finalizar de dos maneras, como ya hemos explicado antes:

  • Closed: el autor no la acepta.
  • Merged: el autor la acepta. Lógicamente, este es el mejor resultado posible, ya que habremos logrado colaborar con el proyecto.

En esta fase, el receptor de la pull request tiene dos botones a su disposición: uno para cerrarla, muy similar al que vimos en las incidencias, y otro para fusionarla, llamado «Merge pull request». Tras pulsarlo, aparecerá un diálogo de confirmación. Para finalizar la fusión, se debe pulsar el botón «Confirm merge».

Estar pendiente de nuestra bifurcación por si hubiera que preparar más pull requests

Aunque el repositorio del proyecto se actualice y reciba nuevos cambios, la bifurcación que hemos hecho en nuestra cuenta no lo hará. Debemos prestar atención y ocuparnos nosotros. De esa forma, al abrir una nueva pull request, estará basada en los cambios más recientes. Para mantener actualizado el repositorio, sigue estos pasos:

  1. Vuelve a la rama master o main, según sea el caso: git checkout master
  2. Añade como origen remoto el repositorio del autor. Como no podemos manipularlo, puede ser más práctico usar https, ya que así nos ahorramos la contraseña de la clave ssh. Podemos llamar al nuevo origen como queramos, por ejemplo upstream: git remote add upstream https://github.com/usuario/repositorio.git
  3. Cada cierto tiempo, actualiza la rama master desde el nuevo origen. Para ello, se puede usar una versión extendida del comando git pull: git pull upstream master
  4. Envía los cambios a tu copia bifurcada: git push

Creación de liberaciones

Una liberación, o release, es una entrega que realizamos del producto en un momento dado de su desarrollo, lista para que el usuario la utilice. NVDA, por ejemplo, realiza cuatro liberaciones al año, que todos conocemos bien por su número de versión. GitHub nos permite hacer liberaciones, y alojar el resultado de las mismas. Para ver las liberaciones asociadas a un repositorio concreto, pulsa el enlace Releases, o sigue el formato https://github.com/usuario/repositorio/releases en la barra de direcciones.
Cada liberación puede contener un texto que describe que ha cambiado desde la liberación anterior, y una serie de archivos. Por defecto, si no subimos nada más, GitHub permitirá descargar el código fuente asociado al tag, tanto en formato zip como tar.gz. Para ir a la última liberación de un repositorio, utilizaremos la palabra latest en la barra de direcciones: https://github.com/usuario/repositorio/releases/latest
A continuación, veremos los pasos necesarios para crear una liberación nueva:

  1. Crear un tag asociado al commit desde el que queremos hacer la liberación. Consulta la sección sobre tags de esta guía.
  2. Enviar el tag a GitHub. Se puede usar un comando como este: git push --tags
  3. Visitar la página releases del repositorio. En ella, hay que buscar el tag, que estará representado como un enlace dentro de un encabezado de nivel 4.
  4. Tras entrar dentro del tag, buscamos y activamos un enlace llamado «Create release from tag».
  5. En el campo «Release title», se escribe el título de la release. Por ejemplo, «v1.1».
  6. El campo «Describe this release» contendrá una descripción de lo que ha cambiado. Al igual que sucede con las incidencias y las pull requests, aquí también se puede escribir Markdown.
  7. Debajo del campo de descripción, hay dos botones para subir archivos. De ellos nos interesa el segundo, que sirve para subir binarios. Los binarios son el resultado de nuestro trabajo, por ejemplo el programa compilado. Tras elegir cada archivo, aparecerá en una lista por encima del botón, y podremos cambiar su nombre o eliminarlo.
  8. La casilla «This is a pre-release» indica a GitHub que se trata de una versión experimental, y que a lo mejor su uso no es recomendable para todo el mundo. Sólo se debe marcar si el trabajo que se va a publicar no es estable.
  9. Finalmente, se pulsará el botón «Publish release». La liberación estará disponible para que el público general la descargue.

Archivos .gitignore

A veces podemos hacer commit y meter archivos accidentalmente en la base de datos que no debían estar ahí. Por ejemplo, si compilamos un programa, todos los archivos .exe, .dll y demás sobran. Para evitar esta desagradable situación, se puede añadir en la raíz del repositorio un archivo llamado .gitignore. Tras añadirlo al repositorio y hacer commit, Git ignorará los ficheros que se indiquen en su interior. Se pueden especificar rutas relativas y nombres de archivos, o utilizar caracteres comodín para excluir ficheros de un tipo concreto. Como muestra,la plantilla de desarrollo de complementos nos da el siguiente .gitignore:

addon/doc/*.css
addon/doc/en/
*_docHandler.py
*.html
*.ini
*.mo
*.pot
*.py[co]
*.nvda-addon
.sconsign.dblite

Si estos archivos existen en la carpeta del repositorio, no se añadirán cuando llamemos a git add. Git los tratará como si no estuvieran ahí.