Hosting y pull requests

Crear

Crea un pull (o merge) request sin salir de la app: desplegables de ramas, título y cuerpo rellenados a partir de los commits de la rama, un interruptor de borrador y — en GitHub — revisores, etiquetas y asignados aplicados al crearlo.

Funciona en GitHub, GitLab, Bitbucket y Azure DevOps. Los PR/MR abiertos de los cuatro aparecen listados en la barra lateral.

Empieza uno desde la comparación de ramas, desde el grafo, desde el + del panel de PRs, o desde una incidencia (lo que rellena Closes #N).

Pilas en la lista

Los pull requests que se apoyan unos en otros se colapsan en una sola fila con un icono de pila, la rama en la que aterriza la cadena y cuántos hay. Despliégala para ver la cadena en orden de lectura —de la hoja hacia la base— con una flechita bajo cada una que dice en qué se fusiona, así la dirección se ve en vez de deducirse de cuatro ramas base.

Dos cosas forman ese grupo: el número de pila propio de GitHub, cuando los PR pertenecen a una pila nativa, y si no las propias refs: un pull request cuya base es la cabeza de otro se apoya en él. Esa segunda regla es la que hace que también funcione en GitLab, Bitbucket y Azure DevOps, y con cadenas abiertas antes de que nada de esto existiera.

Cada fila lleva el estado de los checks de su cabeza —pasa el ratón para ver las cuentas— y, en GitHub, también los niveles ya cerrados o fusionados, que una lista de PR abiertos escondería. Un nivel por encima de uno cerrado se marca como bloqueado: sus checks pueden estar en verde, pero la rama a la que apunta no va a aterrizar nunca. Las acciones de la fila salen al pasar el ratón, para que el título conserve el ancho.

Leer los checks cuesta una petición por pull request, y solo al refrescar la lista.

Revisar — GitHub y GitLab

Si alguien hace force push a mitad de la revisión, qué ha cambiado desde te enseña exactamente qué se ha movido.

Las diferencias de GitLab, dichas claramente: GitLab no tiene una única llamada de "enviar revisión", así que aprobar usa su endpoint de aprobaciones y pedir cambios retira tu aprobación y publica tu comentario. El rebase-merge no se ofrece — GitLab decide entre merge-commit y fast-forward según la configuración del proyecto, así que el menú de merge muestra solo merge y squash. Los hilos en línea muestran el archivo y la línea, pero no el hunk del diff que los rodea, porque la API de GitLab no lo devuelve. Revisar/fusionar funciona para proyectos en gitlab.com; las instancias autoalojadas aún no están soportadas. Bitbucket y Azure DevOps se siguen abriendo en el navegador para revisar.

Incidencias, hitos y releases — GitHub

Explora las incidencias y abre una pestaña completa por incidencia: cuerpo, comentarios, etiquetas, asignados, hito, campos de Projects v2, cerrar/reabrir, y crear una rama para esta incidencia (con nombre generado por IA). Los hitos muestran su progreso y sus incidencias. Los releases se pueden explorar con su página de changelog.

Notificaciones — GitHub

Tu bandeja entera — peticiones de revisión, menciones, actividad de CI — de todos los repositorios, con filtros de no leídas/todas y marcar como leída. La campana de la barra lleva un contador de no leídas, y opcionalmente saltan notificaciones de escritorio cuando te piden una revisión o cuando termina la CI.

Tokens

Tokens por perfil para varias cuentas u organizaciones, guardados en el llavero del sistema. Gitcito también puede tomar prestado lo que ya tenga tu helper de credenciales de git, así que una organización para la que ya te has autenticado a menudo no necesita configuración ninguna. Mira Seguridad y secretos.

Ver también: Ramas apiladas · Funciones de IA