Gestión de Pull Requests

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Revisar una pull request puede llevar un tiempo considerable. En algunos casos, la revisión podría requerir más tiempo del que tomó escribir y enviar los cambios. Por lo tanto, es necesario realizar un trabajo preliminar para garantizar que cada pull request esté en buen estado para ser revisada.

Una pull request debe constar de tres secciones principales:

• Un resumen. Esto nos ayuda a comprender la motivación detrás de los cambios.

• Un changelog. Esto nos ayuda a escribir las notas de la versión. También sirve como un breve resumen de tus cambios.

• Un plan de pruebas. Esta podría ser la parte más importante de tu pull request. Un plan de pruebas debe ser una guía reproducible paso a paso para que un revisor pueda verificar que tu cambio funciona como se espera. También es buena idea adjuntar capturas de pantalla o videos para cambios visibles al usuario.

Cualquier pull request puede requerir un conocimiento más profundo de algún área de React Native que quizás no conozcas. Incluso si no te sientes la persona adecuada para revisar una pull request, aún puedes ayudar añadiendo etiquetas o solicitando más información al autor.

Revisión de PRs

Las pull requests deben ser revisadas y aprobadas mediante la función de revisión de GitHub antes de fusionarse. Si bien cualquiera puede revisar y aprobar una pull request, normalmente solo consideramos que está lista para fusionarse cuando la aprobación proviene de uno de los contribuyentes.

Si has encontrado una pull request que te sientes seguro de revisar, utiliza la función de revisión de GitHub y comunica de forma clara y educada cualquier cambio sugerido.

Considera comenzar con pull requests marcadas como carentes de changelog o plan de pruebas.

• PRs que parecen carecer de changelog - revisa si puedes añadir el changelog editando el PR. Luego, elimina la etiqueta "Missing Changelog".

• PRs que carecen de plan de pruebas - abre la pull request y busca un plan de pruebas. Si parece suficiente, elimina la etiqueta "Missing Test Plan". Si no existe o está incompleto, añade un comentario solicitando educadamente al autor que añada un plan de pruebas.

Una pull request debe pasar todas las pruebas antes de fusionarse. Estas se ejecutan en cada commit en main y en cada pull request. Una forma rápida de ayudar a preparar pull requests para revisión es buscar aquellas que fallen las pruebas pre-commit y determinar si necesitan revisión. La prueba fallida suele aparecer al final del hilo, bajo "Some checks were not successful".

• Revisa rápidamente las últimas ejecuciones de pruebas en main. ¿Está main en verde? Si es así:

  • ¿Parece que el fallo podría relacionarse con los cambios en esta pull request? Solicita al autor que investigue.
  • Incluso si main está actualmente en verde, considera la posibilidad de que los commits de la pull request puedan basarse en un commit de cuando main estaba roto. Si crees que este es el caso, pide al autor que haga rebase de sus cambios sobre main para incorporar correcciones posteriores.

• Si main parece estar dañado, busca incidencias etiquetadas como "CI Test Failure".

  • Si encuentras una incidencia que parezca relacionada con el fallo en main, vuelve a la solicitud de extracción y agradece al autor por proponer estos cambios, e indícale que el fallo en las pruebas podría no estar relacionado con su cambio específico (no olvides enlazar a la incidencia de CI Test Failure, ya que esto ayudará al autor a saber cuándo puede intentar ejecutar las pruebas nuevamente).
  • Si no encuentras una incidencia existente de CI Test Failure que describa el problema que has observado en main, por favor envía una nueva incidencia y usa la etiqueta "CI Test Failure" para informar a otros que main está dañado (consulta esta incidencia como ejemplo).

Cómo priorizamos las PRs

Los miembros del equipo de React Native en Meta se esfuerzan por revisar las solicitudes de extracción rápidamente y la mayoría de las PRs recibirán una respuesta en el plazo de una semana.

¿Cómo se fusiona una PR?

El repositorio de React Native en GitHub es en realidad un espejo de un subdirectorio de uno de los monorepos de Meta. Por lo tanto, las solicitudes de extracción no se fusionan en el sentido tradicional. En su lugar, deben importarse al sistema interno de revisión de código de Meta como un "diff".

Una vez importados, los cambios pasarán por una serie de pruebas. Algunas de estas pruebas son bloqueantes para la fusión, lo que significa que deben tener éxito antes de que el contenido del diff pueda fusionarse. Meta siempre ejecuta React Native desde main y algunos cambios pueden requerir que un empleado de Facebook adjunte cambios internos a tu solicitud de extracción antes de que pueda fusionarse. Por ejemplo, si renombras un módulo, todas las llamadas internas de Facebook deben actualizarse en el mismo cambio para poder fusionarlo. Si el diff se fusiona con éxito, los cambios eventualmente se sincronizarán de vuelta a GitHub mediante ShipIt como un único commit.

Los empleados de Meta utilizan una extensión personalizada del navegador para GitHub que puede importar una solicitud de extracción de dos maneras: la solicitud puede "aterrizar en fbsource", lo que significa que se importará y el diff resultante se aprobará automáticamente, y si no hay fallos, los cambios eventualmente se sincronizarán con main. Una solicitud también puede "importarse a Phabricator", lo que significa que los cambios se copiarán a un diff interno que requerirá revisión y aprobación adicionales antes de poder fusionarse.

Screenshot of the custom browser extension. The button "Import to fbsource" is used to import a Pull Request internally.

Bots

A medida que revisas y trabajas en solicitudes de extracción, podrías encontrar comentarios dejados por varias cuentas de bots de GitHub. Estos bots se han configurado para ayudar en el proceso de revisión de solicitudes de extracción. Consulta la Referencia de Bots para obtener más información.

Etiquetas de Pull Request

• Merged: Se aplica a una PR cerrada para indicar que sus cambios se han incorporado al repositorio principal. Esta etiqueta es necesaria porque las solicitudes de extracción no se fusionan directamente en GitHub. En su lugar, un parche con los cambios de la PR se importa y se pone en cola para revisión de código. Una vez aprobado, el resultado de aplicar esos cambios en el monorepositorio interno de Meta se sincroniza con GitHub como un nuevo commit. GitHub no atribuye ese commit a la PR original, de ahí la necesidad de una etiqueta que comunique el estado real de la PR.

• Blocked on FB: La PR ha sido importada, pero los cambios aún no se han aplicado.