Yo ya hice todos los pasos, lo de las incidencias me interesa, al igual que las pull request, algo que dice grep también. Gracias por el aporte, hay forma de que no me pida la contraseña de la clave ssh cada vez que hago commit o push, tal vez configurarlo que me la pida unicamente la primera vez de cada sesión.

Sí, la hay! No tenía muchas ganas de hablar de ella, porque puede comprometer la seguridad si no tenemos cuidado y nos vamos por ahí sin bloquear la pantalla o cerrar la sesión. Sin embargo, con este método, se introduce la contraseña una sola vez al abrir la consola, y ya no hay que meterla otra vez hasta que se reinicie el equipo, se cierre sesión en Windows o el proceso ssh-agent.exe muera.
Simplemente debes editar el archivo .profile que se encuentra en tu carpeta de usuario. Si no existe, deberás crearlo primero. A Windows no le gustan los archivos cuyo nombre empieza con un punto, por lo que se queja y es mejor usar un comando como este: touch .profile
Una vez creado, hay que pegar el siguiente contenido en su interior:

env=~/.ssh/agent.env
agent_load_env () { test -f ";$env"; &;&; . ";$env"; >;| /dev/null ; }
agent_start () {
(umask 077; ssh-agent >;| ";$env";)
. ";$env"; >;| /dev/null
}
agent_load_env
# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >;| /dev/null 2>;&;1; echo $?)
if [ ! ";$SSH_AUTH_SOCK"; ] || [ $agent_run_state = 2 ]; then
agent_start
ssh-add
elif [ ";$SSH_AUTH_SOCK"; ] &;&; [ $agent_run_state = 1 ]; then
ssh-add
fi
unset env

Aunque no lo recomiende, así es como lo tengo yo también. Cuidado con el Markdown de la sala, que hace cosas extrañas.

¡Hola!

Antes que nada, muchísimas gracias por el aportazo. He seguido todos los post desde que esto empezó, y la verdad es que me ha sido extremadamente útil para aprender nuevas cosas acerca de git y GitHub.
No obstante, tengo un problema bastante serio que no sé cómo resolver.
Hasta el momento, yo clonaba y subía repositorios utilizando simplemente mi correo de GitHub y un tocken que había generado para eso. En estos días se me dio por probar la forma con SSH y... no lo consigo de ninguna forma.

Al intentar lanzar el comando ssh git@github.com, me sale lo siguiente: git@github.com: Permission denied (publickey).

La primera vez que lo intenté aparentemente resultó, pero me confundí escribiendo la clave y tras pifiarle un par de veces, git me regresó a la pantalla principal. Desde ese momento, no consigo hacer que funcione. He intentado crear otra clave ssh y añadirla en github por probar, pero tampoco veo que dé resultado.
Si alguien me pudiera ayudar, se lo agradecería enormemente.
¡Saludos!

Tienes que cambiar el link del repocitorio a modo ssh, pues cuando lo clonaste provablemente lo hiciste con http, para usar ssh es algo así como git@github.com/usuario/repocitorio.
El comando creo que es.
git remote origin git@github.com.
Igual ese comando te lo da cuando vas a git hub o git lab y elijes conección ssh.

Hola.
No no, lo que estoy intentando no es clonar o hacerle un push a mi repositorio, sino que lo único que estoy intentando hacer es lo que se explica en el tutorial, intentar ver si las conexiones funcionan, lanzando un ssh git@github.com. He estado buscando algunas soluciones pero no consigo nada que resulte. Borré la carpeta temp junto a todos los ssh que había creado y lo rehice, conectándolo a github, probé ponerle al nombre del archivo .pub id_rsa... y nada.

No no, cuidado con eso. Si es de tipo ed25519, no la renombres como id_rsa. Lo mejor que puedes hacer es cargarte la carpeta .ssh entera, borrar todas las claves de tu cuenta y empezar otra vez. Por cierto, mañana es viernes, así que... habrá que preparar el siguiente capítulo, ¿no?

@el pichon puedo publicar los post en una página educativa

creo que el mismo dijo que los subirá a la web de nvda.es

edito:
Hola chicos.
Bueno, luego de sufrir por un buen rato, logré arreglarlo (a medias). Borré la carpeta .ssh y hasta reinstalé el cliente de windows. No obstante, eso no solucionó mis problemas puesto que al parecer las claves siguen guardadas en vete a saber dónde. Al final, luego de investigar por un buen rato y de intentar de todo, lo acomodé simplemente renombrando los nombres de los archivos de las claves y añadiendo el fingerprint manualmente en el known_hosts. Es decir, me refiero, por alguna razón al crear mis claves ssh jamás se crean con el nombre que deberían, como id_ed25519, sino que aparecen con nombres como [B, [D y así. Los renombré y al parecer funcionó. Ahora, al intentar hacer un ssh git@github.com, aunque a veces me tira un error de timeout (no sé por qué), cuando logra conectarse me pide la clave del id_ed25519 y ya me salta el mensaje que debería (aunque a veces lanza ciertos mensajes extraños).
De todas formas, sigue siendo algo tedioso porque al abrir la consola de git, a veces me pide que escriba mi contraseña ssh de una vez, y aunque la escriba bien, me dice que está mal. Tengo que darle enter varias veces hasta que me deje en la pantalla principal y así poder trabajar, y luego está eso, que al conectarme a github me siguen saliendo mensajes extraños a veces. Lo que quisiera saber es si hay alguna forma de borrar toda esta configuración, es decir, si hay alguna manera de destruir todo rastro de claves ssh que haya hecho y volver a empezar de 0, a ver si así logro acomodarlo. Lo pregunto porque al parecer con borrar la carpeta .ssh no es suficiente, puesto que al lanzar por ejemplo el comando ssh -Vt git@github.com muchas veces me salían un montón de claves que técnicamente no existían.
Gracias y saludos.

Esto es algo drastico, pero puede funcionarte, en la carpeta app data, de tu usuario, escribe git en el cuadro de busqueda, luego enter y elimina todo lo que salga, luego a volver a configurar git desde 0.

No no, borrar la carpeta .ssh es suficiente, pero hay un detalle que se debe tener en cuenta: Windows 10 también lleva su propio cliente ssh, y ese sí que hace cosas raras. Por eso siempre recomiendo la consola Git Bash. El ssh que invoques desde ella es el que viene incluido con Git y se porta como se tiene que portar. En cuanto a [d y demás caracteres extraños, surgen al pulsar las flechas en la consola cuando no está previsto que se pulsen, entre otros muchos caracteres.

¡Hola!
Gracias, intentaré lo que me dices. Aprovecho a comentar un par de cambios que hice, que al parecer hizo que la cosa funcionase mejor.
Al final, encontré una carpeta ssh en program data y la borré. Por las dudas, volví a borrar mi carpeta .ssh de usuario también, y destruí todo lo que podría estar relacionado a eso (hasta vacié mi carpeta temp). Luego, por probar, volví a lanzar un ssh -vt git@github.com, sin haber creado una clave ni nada y... vi que seguían habiendo como 3 claves ssh que, si bien yo había eliminado, por alguna razón el programa pensaba que existían.
Así, me volví loco intentando descubrir dónde se almacenaba la configuración del ssh. Mi idea era modificarlo todo manualmente. Tras rebuscar bastante en la web, encontré como solución crear mi propio archivo de configuración, y eso hice. Tras crearlo con el powersell, coloqué en su interior esto:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github
IdentitiesOnly yes

Luego, creé una nueva clave ssh (esto también lo hice con el powersell y no desde la consola de git). Al preguntarme la ubicación del archivo, para evitarme problemas, coloqué la ruta entera junto al nombre que había colocado en mi configuración, en este caso, id_ed25519_github. Le puse una contraseña y al revisar mi carpeta .ssh, al fin tenía la clave con el nombre que le corresponde. Lo digo así porque en el pasado había intentado hacer algo así, pero como ya he comentado, por alguna razón las claves jamás se ponían con el nombre que debían. Luego solo hice la configuración correspondiente en github.com, y lancé el ssh git@github.com. Ahora la cosa va un poco mejor, aunque sigo teniendo dos problemas.
Al lanzar el comando, lo usual es que me pida la contraseña del archivo ssh. Tras colocarla, me salta lo siguiente:
PTY allocation request failed on channel 0
No sé por qué es, la verdad, aunque tampoco es tan molesto, puesto que igualmente se conecta (ya me sale el archivo de bienvenida de github y demás), aunque esa línea me extraña bastante.
Otra cosa que me ocurre, que no sé si será por intentar hacerlo en un espacio de tiempo muy corto, es que me salta un error de timeout. Es decir, se queda esperando como por medio minuto, y finalmente salta:
ssh: connect to host github.com port 22: Connection timed out

Pero bueno, salvo por esos detalles ya parece ir bastante bien. Nuevamente, intentaré hacer lo que me has comentado y cualquier cosa, comentaré si me resulta.
Muchas gracias.
¡Saludos!
Bueno, edito, no había visto el mensaje del pichon jajaja. Sí, hasta el momento siempre lo había hecho con la consola de git pero no sé, quizás había tocado las flechas en esa parte y no me di cuenta (es lo mas probable). De todas formas, así hasta el momento se ha comportado decentemente, exceptuando esos 2 pequeños detalles que ya comenté.

Ese mensaje de allocation failed está bien, nos aparece a todos. No es un problema. Por ese lado puedes estar tranquilo.

Genial, ¡muchísimas gracias a todos! Ya está todo, entonces :). He probado hacer un push a un repositorio que tengo mediante ssh y ha funcionado excelente. Mil gracias por sus comentarios y sus ayudas. Al final, aunque fue un poco trabajoso, al menos logré aprender bastante sobre ssh.
Pd: por cierto, al final mi problema con las claves evidentemente era que estaba presionando alguna tecla y por ende se ponían mal los nombres. Ya está arreglado.
¡Un saludo!

Pues ya que está solucionado el problema de las claves, vamos a seguir, ¡que hay mucho que hacer! Hoy no trabajaremos con la consola, toca hablar de incidencias. ¡Empecemos!

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.

Esto es todo por hoy. Ya tenemos casi todo lo que se necesita para hacer pull requests. Pero eso es algo que tendrá que esperar a la semana que viene. ¡Disfrutad y practicad!

Dios. Esto me viene como anillo a todos los dedos

¡Hola gente!
Hoy es el día. Hoy, aprovechando que cambiamos de mes, hablaremos de Pull requests. Esto es lo que muchos estábais esperando. Vamos a juntar todo lo aprendido en posts anteriores, echar algún ingrediente más, agitar la mezcla, y ver qué sale. ¡Comenzamos!

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

¡Esto es todo por hoy! Espero que os haya gustado. Ya nos falta poco para acabar la serie de tutoriales introductorios. En el próximo capítulo, hablaremos de releases y del archivo .gitignore. A partir de ahí, vosotros decidiréis por dónde continuar.
¡Hasta la próxima!

Genial, Muchas gracias.

¡Buenas!
Aprovechando que tenía que hacer una release, me he decidido a documentar el proceso. Llegamos al final de esta serie de tutoriales, guías, o como algunos lo han llamado, curso.

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í.
Tras este breve mensaje, doy por concluida la guía de introducción a Git y GitHub. Espero que os haya gustado mucho, y hayáis aprendido con ella. Esto no significa ni que se cierre el hilo ni que se elimine. Sin embargo, ahora sois vosotros los que decidís cómo y por dónde continuar. ¡Este es sólo el principio de la aventura!
¡Hasta la próxima!

Muchas gracias, ha sido de mucha utilidad para mi.

muy buen hilo!

Hola chicos. estaba creando un repo con un par de boludeces mías en github por simplemente tenerlo aí y me dice que el archivo ocupa mas de 100 mb. como ago para poder sobrepasar ese límite?

hola a todos. bueno, yo vengo con una pequeña duda: he estado intentando interactuar desde git a mi repositorio de github, pero cuando intento subir cambios carga, y al final de todo me topo con que me da error. esto dice
Werror: RPC failed; curl 92 HTTP/2 stream 0 was not closed cleanly: CANCEL (err 8) send-pack: unexpected disconnect while reading sideband packet. y al final, antes de decir Everything up-to-date, dice esto otro:
fatal: the remote end hung up unexpectedly.
alguien me puede ayudar? como resuelvo ese error porque he hecho varias cosas pero siempre me sigue apareciendo lo mismo. de antemano gracias.

Hola.
Tengo una pregunta y una acotación.
¿Se puede hacer auto-commits en un repositorio?Quiero decir. Tengo mi proyecto en la carpeta C: y al momento que actualizo archivos o carpetas quiero que se realice un commit automático sin teclear comandos.no sé si hay scripts o el mismo git o GitHub ofrece esa función.Por otra parte, nadie de aquí se atrebió a hablar de las GitHub actions. Suele ser muy útiles por si se quiere compilar algo automáticamente, todo esto mediante máquinas virtuales en la nuve. Yo es que hace días lo pruebo y mola mucho, como dicen allá.

Yo lo de los commits automáticos no lo haría. En cuanto a las GitHub Actions, no he hablado de ellas por dos razones: el hilo es introductorio, y todavía no he experimentado con ellas. Si alguien se anima y lo deja bonito con encabezados, listas y esas cosas, lo subo extendiendo el documento que pronto llegará a NVDA.es.

Si alguien logra darme una luz con el siguiente problema, se lo agradecería montón. Verán:
Ayudo en el repositorio de un compañero, pero tiene un problema muy raro. Cuando intenta hacer push de sus cambios, comienza a cargar, y al llegar hasta cierto punto, le advierte que no puede subir un archivo por el tamaño, pero es un archivo que no existe dentro del repositorio, y además está ignorado en el .gitignore. Es más, yo hice cambios, y como yo no tenía el archivo, pude subir sin problemas, y el bro pudo actualizar su rama master sin lío igual. ¿Que hacemos? no encuentro info al respecto.

Se me ocurre lo siguiente:

1. Hacer una copia del repo.
2. volver a clohnarlo y crear las ramas para que no se engorrinen los trabajos.
3. Modificar los archivos adecuados.
4. Hacer push.

Tiene que haber otra forma más elegante y menos destructiva, pero... Bueno, es una idea.

Gracias bro! la única que se ocurrió fue clonar, añadir cambios según los archivos modificados en cada commit adicional faltante en el repositorio original, ir haciendo commits, y sale incluyendo las ramas. Destructivo, sí. Raro, también pero funcionó. Locura.

Hola, revivo esto para hace runa pregunta.
al reinstalar windows de 0, como puedo ahcer para tener las clabes que se mencionan al comienzo del curso, cuadno ya están puestas en github? o necesito hacer toda la configuracion desde 0.
Gracias al que me responda.

Guarda las carpetas .ssh y .gnupg que hay en tu perfil de usuario. Son las que contienen todo.