hoola muchas gracias eso va ser de gran utilidade para mi tambien

¡Buenos días!
Vamos a continuar hablando sobre Git. Ya nos falta muy muy poco para poder usarlo en Internet, pero eso será en el próximo post, no en este. Hoy seguiremos conociendo por dentro los repositorios locales. En esta ocasión, toca hablar de ramas. ¡Empezamos!

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 posts 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

3. Haz tu primer commit con estos datos.
4. 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.

Esto es todo por el momento. En la próxima entrega, empezaremos a conocer GitHub y veremos cómo clonar un repositorio público. ¡Feliz martes!

Esto si me interesa, leyendo voy mirando e imaginando como quedan las cosas, así que jithub se usa desde consola.
Vaya y con comandos, parece fácil, pero se requiere trabajo. Vaya.

¡Hola!
El otro día dije que comenzaríamos a hacer cosas con repositorios remotos, pero me he dado cuenta de que me dejé algo importante, así que vamos a acabarlo primero. ¿Qué pasa cuando las cosas salen mal y provocamos un conflicto? Vamos a verlo.

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
>>>>>>> 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.

6. 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.
7. Añade los cambios para hacer commit: git add --all
8. 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.
Esto es todo por el momento. Si os gusta, escribid en el hilo y seguimos adelante!

Como fue lo de NVDA?

Como he dicho más arriba. No voy a dar más detalles. Pasó, se arregló y ahora todo está bien. Además pasó hace mucho.

Otro que se guarda el tema. Gracias por el currazo.

Hola, subo hilo para preguntar:
¿Habrá más capítulos?
Gracias por la atención de antemano :D

lo mismo que kabo erain,
donde están más capítulos? se que la gente tiene cosas que hacer(pa que luego no me salten los de siempre) pero esto tenía un gran camino que pena que hayan como 2 meces de inactividad u. :(

Solo puedo decirque estoy enormemente agradecido, este hilo ayudó a muchos a usar git, o a refrescar como es mi caso. Con lo que vieron ya es un paso enorme, se pueden ya gestionar repositorios muy bien. Claro, hacen falta cositas, pero son ya cosas un poco extremas.

Sí, habrá más, pero estas semanas he tenido bastante lío. Perdón por eso.

¡me encantó esto!
No conocía este hilo, yo uso github por ahí para algunas cosas, y sin duda esto sirbe mucho para gestionarlo mejor. Gracias pichón.

Acabo de practicar todo esto. Ha salido bien, así que espero el próximo capítulo y aquí tengo los dos repositorios de la lista de la compra y el reglamento.
Ahora que soy el principal mantenedor de la traducción al inglés de un complemento para NVDA, supe que necesito aprender a usar Git y GitHub para trabajar mucho mejor.

¡Hola!
Vamos a seguir con esto, ¿no? Que ya llevaba demasiado tiempo aparcado, y eso no se puede consentir. Hoy aprenderemos cosas de Github, pero aún no es necesario registrarse allí. Eso lo veremos en el próximo capítulo. ¡Empecemos!

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.

• Esta es la cuenta de la Asociación Comunidad Hispanohablante de NVDA: https://github.com/nvda-es
• Y esta otra, la cuenta de la persona que está redactando esta sucesión de tutoriales: https://github.com/jmdaweb

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.

¡Y esto es todo por hoy! En el próximo mensaje crearemos una cuenta en GitHub, la configuraremos, y sabremos qué son las incidencias y las pull requests y cómo explorarlas.
¡Espero que os haya gustado!

hola resien comienso a leer la entrada como puedo ver la guía completa, la verdad nunca habia entrado a esta sección de la sala me interesaría la guía saludos.

Pulsa abrir esta discusión en la web, puede ser un buen punto de partida.

Hola, hoy me puse al día con los últimos 2 posts, esto seguro me ayudará para no peder mi pequeño cacharro jaja.

Yo quiero saber y creo que se abordará en el próximo post, ¿cómo hago para configurar git con mi usuario de github? He estado buscando información pero no logro comprender bien como es que se hace.

Muchas gracias @el_pichon, excelente trabajo y muy bien explicado. Me había perdido este hilo.

@coachJos: En git, antes de hacer commits pusiste un correo, con:
git config --global user.email x@y.z
Si te registras con ese mismo correo a github, o lo añades a tu usuario desde la configuración de tu cuenta, tus commits quedan asociados a tu usuario.

Aaah, ya, muchas gracias por la respuesta.

Sí, pero yo creo que está preguntando por la autenticación a la hora de enviar cambios. Aviso que en esa parte me voy a olvidar de https y voy a ir con ssh a tope, por lo que espero que todo el mundo que está siguiendo esta guía tenga su clave generada.

Eso presisamente me confunde, pues en github lei que es recomendable trabajar con http en lugar de ssh.

No. De hecho, https se está empezando a marcar como obsoleto e inseguro a la hora de enviar cambios. Lo ideal es usarlo únicamente para clonar repositorios que vayas a mirar de otras personas. Para clonar los tuyos propios, ssh sin duda. Por cierto, se me olvidó decirlo antes: he editado el post 1 explicando cómo actualizar Git a la última versión cómodamente desde consola. El comando que allí se menciona sólo funcionará en Windows, no existe en ninguna otra plataforma.

Sí, acabo de ver el comando, yo prefiero usar la versión portable de git for windows, sabes si existe algún comando para actualizarla automáticamente.

Podrías probar con ese mismo. Nunca he usado Git en modo portable, te obliga a emplear Mintty como terminal. Ya nos contarás si funciona.

No, la versión portable también trae la consola CMD, el comando no funciona, lo que hace es que instala git. Ahora tengo una duda, como puedo verificar que los commits y tags si se están firmando, pues no me solicita la passfreis cuando hago commits o tags.

He investigado un poco, y esto se resuelve con los comandos git verify-commit y git verify-tag. Hay que pasar el identificador del commit o el tag. Por ejemplo:
git commit-verify HEAD
Esto dará la información gpg asociada al commit actual, si la hay.
Información extraída de aquí: https://stackoverflow.com/questions/17371955/verifying-signed-git-commits
Voy a preparar el siguiente capítulo, que esto continúa!

Muchas gracias, lo logré solucionar eliminando la configuración anterior y volviendo a hacer todo el proceso nuevamente, Estoy pendiente del próximo capítulo. Me adelaanté un poco y me creé una cuenta pero en gitlab, me pareció más intuitiva que github la interfaz web.

¡Hola!
Hoy avanzaremos en esta serie de pequeños tutoriales adentrándonos en el mundo de GitHub. Crearemos una cuenta de usuario, y haremos algo verdaderamente útil con las claves ssh y gpg que generamos al principio. Preparados, listos... ¡vamos!

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 "View profile and more". Estará contraído, expándelo.
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 dos 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 explorador de archivos, abre tu carpeta de usuario y entra a la subcarpeta .ssh (empieza con un punto).
7. 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.
8. 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: 3AA5C34371567BD2
2. Con el identificador ya preparado, exporta la parte pública en un archivo: gpg --armor --export 3AA5C34371567BD2 > 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 un único campo. 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, aunque todavía está en fase beta, 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 git@github.com
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

Llega la última sección de este capítulo, y el primer paso hacia un sinfín de aventuras. En este ejercicio, crearemos nuestro primer repositorio en GitHub, lo clonaremos, haremos cambios en él y los publicaremos. ¡Empecemos!

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 comienzan 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 git@github.com: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.

¡Esto es todo por hoy! En la próxima entrega, rellenaremos el perfil de GitHub para que quede más presentable, y aprenderemos a abrir incidencias. Mientras tanto, ¿alguien se anima a compartir lo que ha hecho en este hilo? Yo me he tenido que hacer una cuenta llamada jmdaweb-pruebas, porque hace años que tengo perfil ahí y no sabía si el formulario habría cambiado. Por cierto, y antes de que alguien lo pregunte: esto que hemos hecho con las claves ssh y gpg también sirve en Gitlab y Bitbucket. El procedimiento es exactamente el mismo, con las pequeñas diferencias que se puedan presentar en cada interfaz. También se pueden clonar por ssh los repositorios de otras personas, no sólo los nuestros. Cualquier repositorio público es accesible por https y ssh.
¡Hasta la próxima!