33  Explorar y ampliar una solicitud de cambio

Escenario: mantiene un paquete R en GitHub con solicitudes de cambio (PR) de contribuyentes externos, p. Jane Doe, janedoe en GitHub. A veces es necesario experimentar con las relaciones públicas para poder brindar retroalimentación o decidir si fusionarse o no. Yendo más allá, a veces desea agregar algunas confirmaciones y luego fusionarlas. O tal vez simplemente haya algunos conflictos de fusión que requieran su atención local y personal. Supongamos también que desea que el autor de relaciones públicas original obtenga crédito por sus confirmaciones, es decir, desea preservar la historia y la procedencia, no solo las diferencias.

¿Cómo se paga y posiblemente se extiende un PR externo?

33.1 Actualización del futuro

Las lecciones aprendidas aquí finalmente conducen a la familia de funciones pr_*() en uso. pr_fetch() y pr_push() son ahora mis caballos de batalla para explorar y ampliar las relaciones públicas. Puede leer más sobre las funciones de usethis para ayudar con las solicitudes de cambio en su propio artículo: Ayudantes de solicitudes de cambios.

33.2 Terminología

Vocabulario que utilizo en todo momento.

rama de bifurcación El nombre de la rama en la bifurcación a partir de la cual se creó la solicitud. En el mejor de los casos: nombre informativo como arreglar-conejo-peludo. En el peor de los casos: PR es de master.

rama local de solicitud de cambio El nombre de la rama local que utilizará para trabajar con el cmbio. En el mejor de los casos: puede ser lo mismo que la rama de bifurcación. En el peor de los casos: los cambios proviene de maester, por lo que debe inventar un nuevo nombre basado en algo sobre la solicitudde cambio, p. pr-666 o janedoe-master.

padre de solicitud de cambio El SHA de la confirmación en el repositorio principal que es la base de la solicitud de cambio.

solicitud de cambio remota La URL SSH o HTTPS para la bifurcación desde la cual se realizó la solicitud de cambio. O el apodo del control remoto, si te has molestado en configurarlo.

33.3 Consejo oficial de GitHub, versión 1

Cada solicitud de cambio en GitHub tiene un enlace a “instrucciones de línea de comando” sobre cómo fusionar la solicitud de cambio localmente a través de la línea de comando Git. En este viaje, hay un punto en el que puedes hacer una pausa y explorar las relaciones públicas a nivel local.

Aquí están sus pasos con mi vocabulario y algunos comandos de ejemplo:

• Crear y verificar la rama de solicitud de cambio local, anticipando su relación con la sucursal bifurcación. Plantilla del comando Git, además de un ejemplo de cómo se ve en ambos escenarios de nombres:

  # Template of the Git command
  git checkout -b LOCAL_PR_BRANCH master 
  # How it looks under both naming scenarios
  git checkout -b fix-fluffy-bunny master 
  git checkout -b janedoe-master master 

• Importe de la bifurcación del control remoto la solicitud de cambio:

  # Template of the Git command
  git pull REMOTE FORK_PR_BRANCH
  # How it looks under both naming scenarios
  git pull https://github.com/janedoe/yourpackage.git fix-fluffy-bunny
  git pull https://github.com/janedoe/yourpackage.git master

• Confía en que todo está bien y quieres fusionarte.

• Verificar master:

  git checkout master

• Fusione la rama de la solicitud de cambio local en la maestra con --no-ff, que significa “sin combinación de avance rápido”. Esto garantiza que obtendrá una confirmación de fusión, con dos padres.

  # Template of the Git command
  git merge --no-ff LOCAL_PR_BRANCH
  # How it looks under both naming scenarios
  git merge --no-ff fix-fluffy-bunny
  git merge --no-ff janedoe-master

• Envie master a GitHub.

  git push origin master

¿Que es no le gusta? Es casi seguro que la confirmación principal de la rama de solicitud de cambio local no será la confirmación principal de la rama de solicitud de cambio bifurcada, donde el colaborador externo hizo su trabajo. Esto a menudo significa que tendrás conflictos de fusión en git pull, con los que tendrás que lidiar lo antes posible. Cuanto más antigua sea la solicitud, más probable será esto y más complicados serán los conflictos.

Preferio ocuparme de los conflictos de fusión solo después de haber examinado la solicitud y resolver los conflictos localmente, no en GitHub. Así que no uso este flujo de trabajo exacto.

33.4 Consejo oficial de GitHub, versión 2

GitHub tiene otro conjunto de instrucciones: Consultar solicitudes de cambio localmente

Comienza haciendo referencia a las instrucciones de la Versión 1, pero continúa abordando una solicitud de cambio inactiva”, definida como un solicitud “cuyo propietario dejó de responder o, más probablemente, eliminó su bifurcación”.

Es posible que este flujo de trabajo NO otorgue crédito al autor de relaciones públicas original (la próxima vez que sea fácil probar esto, lo actualizaré con una respuesta definitiva). Nunca lo he usado palabra por palabra porque nunca he tenido este problema exacto con respecto a la bifurcación eliminada.

33.5 Consejo oficial de GitHub, versión 3

GitHub tiene otro conjunto de instrucciones: Confirmar cambios en una rama de solicitud de cambio creada a partir de una bifurcación

La página vinculada anteriormente explica todas las condiciones previas, pero la versión corta es que un mantenedor probablemente pueda enviar nuevas confirmaciones a una solicitud, lo que efectivamente llevará las confirmaciones a una bifurcación. ¡Extraño pero cierto!

Este conjunto de instrucciones sugiere que clones la bifurcación, revises la rama desde la cual se realizó la solictud, realices las confirmaciones que desees y luego envies. Cualquier confirmación nueva que realice aparecerá en la solictud. Y luego podrías fusionar.

Mi principal conclusión: el mantenedor puede acceder a la rama de una bifurcación asociada con una solicitud.

33.6 Un flujo de trabajo que utilicé una vez

Las lecciones aprendidas aquí eventualmente conducen a la familia de funciones pr_() en usethis. pr_fetch() y pr_push() son ahora mis caballos de batalla para explorar y ampliar las solicitude de cambio. Puede leer más sobre las funciones de usethis para ayudar con las solicitudes de cambios en su propio artículo: Ayudantes de solicitudes de cambios.*

Esto combina ideas de los tres enfoques anteriores, pero con algunos ajustes. Estoy bosquejando esto en código R, con la esperanza de ponerlo en una función y paquete en algún momento. Esta es una revisión de un enfoque anterior, basada en los comentarios de Jim Hester.

Ejemplo de una solicitud de cambio de la rama master (subóptimo pero que sucede con frecuencia) del usuario ficticio de GitHub abcde en usethis.

library(git2r)

## agregue la bifurcación del solicitante de cambios como un control remoto con nombre
remote_add(name = "abcde", url = "git@github.com:abcde/usethis.git")

## importe
fetch(name = "abcde")

## enumerar ramas remotas y aislar la que quiero
b <- branches(flags = "remote")
b <- b[["abcde/master"]]

## obtenga el SHA de HEAD en esta rama
sha <- branch_target(b)

## crear rama local
branch_create(commit = lookup(sha = sha), name = "abcde-master")

## échale un vistazot
checkout(object = ".", branch = "abcde-master")

## establecer rama de seguimiento upstream
branch_set_upstream(repository_head(), name = "abcde/master")

## confirmar la rama de seguimiento upstream
branch_get_upstream(repository_head())

## haga una o más confirmaciones aquí

## envie hacia la rama en la bifurcación y, por tanto, hacia la solicitud de cambio
push()