6.3 GitHub - Mantenimiento de un proyecto

Cuando alguien realiza un cambio en el código y te crea un Pull Request, debes recibir una notificación por correo electrónico avisándote, con un aspecto similar a Notificación por correo de nuevo Pull Request..

Hay algunas cosas a destacar en este correo. En primer lugar, te dará un pequeño diffstat (es decir, una lista de archivos cambiados y en qué medida). Además, trae un enlace al Pull Request y algunas URL que puedes usar desde la línea de comandos.

Si observas la línea que dice git pull <url> patch-1, es una forma simple de fusionar una rama remota sin tener que añadirla localmente. Lo vimos esto rápidamente en Recuperando ramas remotas. Si lo deseas, puedes crear y cambiar a una rama y luego ejecutar el comando para fusionar los cambios del Pull Request.

Las otras URL interesantes son las de .diff y .patch, que como su nombre lo indica, proporcionan “diff unificados” y formatos de parche del Pull Request. Técnicamente, podrías fusionar con algo como:

Como hemos visto en El Flujo de Trabajo en GitHub, puedes participar en una discusión con la persona que generó el Pull Request. Puedes comentar líneas concretas de código, comentar commits completos o comentar el Pull Request en sí mismo, utilizando donde quieras el formato Markdown.

Cada vez que alguien comenta, recibirás nuevas notificaciones por correo, lo que te permite vigilar todo lo que pasa. Cada correo tendrá un enlace a la actividad que ha tenido lugar y, además, puedes responder al comentario simplemente contestando al correo.

Una vez que el código está como quieres y deseas fusionarlo, puedes copiar el código y fusionarlo localmente, mediante la sintaxis ya conocida de git pull <url> <branch>, o bien añadiendo el fork como nuevo remoto, bajándotelo y luego fusionándolo.

Si la fusión es trivial, también puedes pulsar el botón “Merge” en GitHub. Esto realizará una fusión “sin avance rápido”, creando un commit de fusión incluso si era posible una fusión con avance rápido. Esto significa que cada vez que pulses el botón Merge, se creará un commit de fusión. Como verás en Botón Merge e instrucciones para fusionar manualmente un Pull Request., GitHub te da toda esta información si pulsas en el enlace de ayuda.

Si decides que no quieres fusionar, también puedes cerrar el Pull Request y la persona que lo creó será notificada.

Si tienes muchos Pull Request y no quieres añadir un montón de remotos o hacer muchos cada vez, hay un pequeño truco que GitHub te permite. Es un poco avanzado y lo veremos en detalle después en Las especificaciones para hacer referencia a…​ (refspec), pero puede ser bastante útil.

En GitHub tenemos que las ramas de Pull Request son una especie de pseudo-ramas del servidor. De forma predeterminada no las obtendrás cuando hagas un clonado, pero hay una forma algo oscura de acceder a ellos.

Para demostrarlo, usaremos un comando de bajo nivel (conocido como de “fontanería”, sabremos más sobre esto en Fontanería y porcelana) llamado ls-remote. Este comando no se suele usar en el día a día de Git pero es útil para ver las referencias presentes en el servidor.

Si ejecutamos este comando sobre el repositorio “blink” que hemos estado usando antes, obtendremos una lista de ramas, etiquetas y otras referencias del repositorio.

Por supuesto, si estás en tu repositorio y tecleas git ls-remote origin podrás ver algo similar pero para el remoto etiquetado como origin.

Si el repositorio está en GitHub y tienes Pull Requests abiertos, tendrás estas referencias con el prefijo refs/pull. Básicamente, son ramas, pero ya que no están bajo refs/heads/, no las obtendrás normalmente cuando clonas o te bajas el repositorio del servidor, ya que el proceso de obtención las ignora.

Hay dos referencias por cada Pull Request, la que termina en /head apunta exactamente al último commit de la rama del Pull Request. Así si alguien abre un Pull Request en el repositorio y su rama se llama bug-fix apuntando al commit a5a775, en nuestro repositorio no tendremos una rama bug-fix (puesto que está en el fork) pero tendremos el pull/<pr#>/head apuntando a a5a775. Esto significa que podemos obtener fácilmente cada Pull Request sin tener que añadir un montón de remotos.

Ahora puedes obtenerlo directamente.

Esto dice a Git, “Conecta al remoto origin y descarga la referencia llamada refs/pull/958/head.” Git obedece y descarga todo lo necesario para construir esa referencia, y deja un puntero al commit que quieres bajo .git/FETCH_HEAD. Puedes realizar operaciones como git merge FETCH_HEAD aunque el mensaje del commit será un poco confuso. Además, si estás revisando un montón de Pull Requests, se convertirá en algo tedioso.

Hay también una forma de obtener todos los Pull Requests, y mantenerlos actualizados cada vez que conectas al remoto. Para ello abre el archivo .git/config y busca la línea origin. Será similar a esto:

La línea que comienza con fetch = es un “refspec.” Es una forma de mapear nombres del remoto con nombres de tu copia local. Este caso concreto dice a Git, que "las cosas en el remoto bajo refs/heads deben ir en mi repositorio bajo refs/remotes/origin." Puedes modificar esta sección añadiendo otra refspec:

Con esta última línea decimos a Git, “Todas las referencias del tipo refs/pull/123/head deben guardarse localmente como refs/remotes/origin/pr/123.” Ahora, si guardas el archivo y ejecutas un git fetch tendremos:

Ya tienes todos los Pull Request en local de forma parecida a las ramas; son solo-lectura y se actualizan cada vez que haces un fetch. Pero hace muy fácil probar el código de un Pull Request en local:

La referencia refs/pull/#/merge de GitHub representa el “commit” que resultaría si pulsamos el botón “merge”. Esto te permite probar la fusión del Pull Request sin llegar a pulsar dicho botón.

No solamente se puede abrir Pull Requests en la rama master, también se pueden abrir sobre cualquier rama de la red. De hecho, puedes poner como objetivo otro Pull Request.

Si ves que un Pull Request va en la buena dirección y tienes una idea para hacer un cambio que depende de él, o bien no estás seguro de que sea una buena idea, o no tienes acceso de escritura en la rama objetivo, puedes abrir un Pull Request directamente.

Cuando vas a abrir el Pull Request, hay una caja en la parte superior de la página que especifica qué rama quieres usar y desde qué rama quieres hacer la petición. Si pulsas el botón “Edit” en el lado derecho de la caja, puedes cambiar no solo las ramas sino también la bifurcación.

Aquí puedes fácilmente especificar la fusión de tu nueva rama en otro Pull Request o en otrá bifurcación del proyecto.

Cuando decimos “notificaciones”, nos referimos a una forma por la que GitHub intenta contactar contigo cuando tienen lugar eventos, y éstas pueden ser configuradas de diferentes formas. Si te vas al enlace “Notification center” de la página de ajustes, verás las diferentes opciones disponibles.

Para cada tipo, puedes elegir tener notificaciones de “Email” o de “Web”, y puedes elegir tener una de ellas, ambas o ninguna.

Si usas como rama predeterminada una que no sea “master”, por ejemplo para que sea objetivo de los Pull Requests, puedes cambiarla en las opciones de configuración del repositorio, en donde pone “Options”.

Simplemente cambia la rama predeterminada en la lista desplegable, y ésta será la elegida para la mayoría de las operaciones, así mismo será la que sea visible al principio (“checked-out”) cuando alguien clona el repositorio.

Si quieres transferir la propiedad de un proyecto a otro usuario u organización en GitHub, hay una opción para ello al final de “Options” llamada “Transfer ownership”.

Esto es útil si vas a abandonar el proyecto y quieres que alguien continúe, o bien se ha vuelto muy grande y prefieres que se gestione desde una organización.

Esta transferencia, supone un cambio de URL. Para evitar que nadie se pierda, genera una redirección web en la URL antigua. Esta redirección funciona también con las operaciones de clonado o de copia desde Git.