Hola a todos.
A raíz de una pull request que hizo @jamesPotter en el repositorio de EVM, he pensado que sería una buena idea redactar una serie de posts hablando de Git, GitHub y herramientas relacionadas para entenderlo un poco mejor. Aclaro que en este hilo no vamos a hablar nada de programación, y tampoco es apto para la gente que tiene prisa. Iré editando este primer mensaje para indicar en qué otros mensajes del hilo se van desarrollando los demás capítulos de esta nueva aventura. Vuestros comentarios me servirán para crear una colección de documentos que quiero publicar en la web de NVDA en español. ¿Preparados? ¿Listos? ¡Vamos!

Índice

Instalación y configuración inicial de Git: post 1.
Creación del primer repositorio: post 12.
Navegación por el historial y los commits, uso de tags y limpieza de un repositorio: post 26.
Ramas, rebase y merge: post 32.
Resolución de conflictos: post 34.
Introducción a GitHub y clonación de un repositorio: post 44.
Creación de cuenta en GitHub y primer repositorio: post 60.
Configuración de perfil e introducción a las incidencias: post 75.
Gestión de orígenes remotos y creación de pull requests: post 77.
Releases y archivos .gitignore: post 79.

¿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, se activará 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. 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 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.
3. 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.
4. 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.
5. ¿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), 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).
6. Selección de biblioteca SSL. Seleccionamos "Use the native Windows Secure Channel library" y seguimos adelante.
7. 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.
8. 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".
9. Comportamiento predeterminado de git pull. Más adelante explicaremos qué hace este comando. De momento, lo ideal es elegir el valor "Default (fast-forward or merge)".
10. Ayudante de credenciales. En principio no nos hará falta, así que elegiremos None (ninguno).
11. Opciones extra. Se recomienda dejar los valores por defecto.
12. Opciones experimentales. Se recomienda dejar los valores por defecto.
13. Confirmación de instalación. Al pulsar el botón Install en esta pantalla, Git se instalará en nuestro sistema con las opciones elegidas.
14. 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 longitud de la clave. En vez de dejar los 3072 bits que se nos ofrecen, escribimos 4096 y pulsamos intro. Esto vendrá bien para GitHub de cara al futuro, ya que sólo admite de 4096 en adelante.
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:
/Users/hubot/.gnupg/secring.gpg

---

sec 4096R/3AA5C34371567BD2 2016-03-10 [expires: 2017-03-10]
uid Hubot
ssb 4096R/42B317FD4BA89E7A 2016-03-10
4
El identificador de la clave que nos interesa está inmediatamente debajo de la línea de guiones, justo después de sec 4096R, 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 3AA5C34371567BD2
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.
Si has llegado hasta aquí, ya tienes Git configurado para trabajar con repositorios, y además hacerlo de forma segura reduciendo al mínimo las posibilidades de que alguien suplante tu identidad. En el próximo capítulo, aprenderemos a crear nuestro primer repositorio y grabar cambios en él.
¡Hasta pronto!

dioos, hilo que vale la pena, posteo para guardármelo.

que tiene de distinto git y github? o es lo mismo.

A ver si no me equivoco en algo, que no soy experto en el tema. Básicamente Git es un sistema de control de versiones, como está definido en el tutorial, y GitHub es una plataforma que permite subir repositorios a la nube para trabajar de forma colaborativa basándose en git. Y no solo es git con cloud, también incluye algunas características propias como funciones para gestión de proyectos. Ah, y los repositorios suelen ser públicos. Podríamos decir que es una especie de red social para programadores.

me lo guardo.

me lo guardo

véngache pá cá.

Me sumo.

Posteo para que aparezca en la lista.

igual yo

Una más

¡Me encanta que hayáis recibido así de bien el hilo! ¿Alguien se ha atrevido ya a completar la primera parte? ¿Qué tal la experiencia? Sigamos avanzando. Por cierto, me gusta mucho cómo ha explicado @pildain la diferencia entre Git y GitHub, ha acertado casi por completo. Voy a proponer un ejercicio que puede causar algo de polémica, pero que sin duda os va a motivar mucho.

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. Tal vez en un futuro veamos para qué puede ser útil.
• 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.
Esto es todo por el momento. En el próximo capítulo de esta serie, aprenderemos cómo navegar por el historial de cambios, cómo retroceder en el tiempo, qué son los tags y cómo restablecer y limpiar un repositorio para dejarlo como estaba en el commit más reciente.
¡Hasta otra!

meloguardo

comenzaré con esta bonita aventura en días posteriores. muy lindo to.

Excelente hilo. Si bien ya usaba Git para algunas cosas, me viene genial para aprender cosas nuevas como firmar commits o el uso de los tags. También es lo suficientemente conciso para usarlo de manual de referencia cuando se olvida algún comando, so... me lo guardo. Gracias por el trabajo :)

me lo guardo

Adentro.

bueno, voy a proceder a repetir lo que tán diciendo todos hacá. me lo guardo.

ven para acá cosita, que sé que te voy a necesitar.

Guardo el hilo. Por cierto, está muy guapa la estructura de los capítulos, si entramos desde la web claro está.
de paso Pregunto: ¿Y qué pasa si no se genera una de esas claves o las dos? Ya que, a la primera configuración recuerdo haber hecho eso aunque fue ya hace años, y no me ha dado problemas al crear, modificar o subir cualquier cosa hasta ahora.

claaro que lo guardo si!

Dependiendo de la clave que sea pueden pasar distintas cosas. Si no generas una clave GPG no podrás firmar commits. En principio no es necesario firmarlos, pero he decidido meter ese extra para tener una capa de seguridad adicional desde el primer momento. En cuanto a la clave SSH, mucho me temo que ya es obligatoria. GitHub en algún momento va a prohibir hacer push por https.

hola, e aquí mi primer problema. en la parte de generar la segunda clabe, después de poner mi nombre y gmail, me tira esto.
MINGW64:/c/Users/angel
y un comando que por cuestiones del speech story no pude copiar, pero según recuerdo decía algo de una q, o algo así. al dar q, y enter, me regresa a preguntarme el nombre y el gmail.

Ahí, la tecla correcta es la O, de OK. Lo que te sale es una especie de menú de opciones por si quieres modificar tu nombre, correo o comentario.

Listo, creada la configuración inicial, carpeta repos y primer repocitorio local, ahora a practicar lo de los commits.

¡Hola!
Después de una ardua semana de trabajo, llega el fin de semana, y con él seguimos aprendiendo Git. En el post anterior, vimos cómo crear nuestro primer repositorio y agregamos un par de commits. Espero que nadie lo haya borrado, porque hoy haremos cosas con esos commits. ¿Preparados? ¡Vamos allá!

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.

Esto es todo por hoy. En la próxima entrega, explicaremos qué son las ramas, cómo moverse entre ellas, y qué hacen los comandos merge y rebase. Voy a dejar de poner como ejemplo las reglas de la sala, que al final alguien se va a enfadar de verdad!

hola, muchas gracias por esto. de verdad me será muy útil. ya voy al corriente con la guía.

Hola. Intentando firmar los commits rompí todo (?)
A ver si @el_pichon o alguien sabe como solucionar esto.
La cosa es que creé la clave gpg, se la asigné a git y a la hora de hacer commits me figura el siguiente error:
error: gpg falló al firmar la data
fatal: falló al escribir el objeto commit

No estoy usando Git for Windows, estoy usando git sobre Ubuntu 20.04 en Wsl2

Puedes desactivar la firma de commits mientras descubrimos por qué falla. En las instrucciones del post 1, cambia true por false para quitar la firma automática.

Esto me solucionó el problema:

export GPG_TTY=$(tty)