Conectar un host de código

Control Center funciona con tres hosts de código, a los que en toda la aplicación se llama forjas: GitHub, GitLab y Bitbucket Cloud. Ninguna de ellas es la predeterminada. Conecta una y todo funciona; conecta varias y un mismo espacio de trabajo puede albergar repos de todas ellas a la vez.

La forja es una propiedad de cada repo, que se lee de su remoto origin cuando lo registras. Nunca la eliges, y no hay ningún ajuste por espacio de trabajo que puedas dejar mal.

Conectar una forja

Abre Ajustes → Espacio de trabajo → Perfil e identidad (/settings/workspace/profile).
Busca la tarjeta Alojamiento de código. En ella se listan todas las forjas compatibles, conectadas o no.
Pulsa Iniciar sesión con … si la fila lo ofrece, o Añadir token y pega uno.

Iniciar sesión aparece para una forja para la que tu servidor tiene una aplicación registrada; hoy ese es el caso de GitHub, mediante un flujo de dispositivo (consulta Crear la GitHub App). Todo lo demás es un token pegado, que es la opción honesta en lugar de un botón que no puede llegar a completarse.

En cualquier caso, la credencial es tuya y vive en el servidor, indexada por tu id de usuario: no se guarda ningún token en la computadora donde lo escribiste, todos los dispositivos desde los que inicies sesión usan la misma, y ningún otro miembro puede leerla. Surte efecto en la siguiente petición —no hay nada que reiniciar, y desconectarla hace que deje de enviarse de inmediato.

Cada fila te dice de dónde procede su credencial, porque esa es la diferencia entre «mi token no funciona» y «está respondiendo otro token»:

Subtítulo	Significado
`Sesión iniciada como octocat`	Se está usando tu propia credencial
`Sesión iniciada como octocat · mediante la app de este servidor`	Está respondiendo la identidad de la aplicación del servidor —no has iniciado sesión
`Sesión iniciada como octocat · desde el entorno`	Está respondiendo una variable de entorno del servidor, no tu credencial
`No conectado`	No tienes ninguna credencial para esta forja

Qué token quiere cada forja

Forja	Token	Dónde crearlo
GitHub	Clásico: `repo` y `read:org`. De grano fino: Contents + Pull requests (read/write), Checks + Actions (read)	github.com → Settings → Developer settings → Tokens
GitLab	Un token de acceso personal con `api`	gitlab.com → User settings → Access tokens
Bitbucket	Un token de API de Atlassian, más el correo de tu cuenta	id.atlassian.com → Security → API tokens

Bitbucket se autentica con tu correo de cuenta como nombre de usuario y el token como contraseña. Configura BITBUCKET_EMAIL en el entorno del servidor para que sepa con qué correo emparejar el token.

O usa el entorno

Para una instalación headless o de CI, el servidor lee estas variables:

GitHub — GITHUB_TOKEN y luego GH_TOKEN
GitLab — GITLAB_TOKEN y luego CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN y luego BITBUCKET_TOKEN (junto con BITBUCKET_EMAIL)

Estas son la credencial del servidor, no la tuya, y la distinción es fundamental: una petición hecha en tu nombre usa tu credencial y nada más, así que el entorno nunca te suplanta en silencio. El trabajo sin ninguna persona detrás —webhooks, sondeo de PR, sincronización de tickets— resuelve primero la identidad de la aplicación del servidor, luego la credencial del propietario del servidor y por último el entorno. El orden es fijo, de modo que «inicié sesión y nada cambió» no sea nunca un resultado posible.

Eres una persona distinta en cada forja

La misma persona es octocat en GitHub y algo completamente distinto en GitLab. Control Center resuelve tu identidad por forja y usa la correcta para cada repo, que es lo que hace que «necesita mi revisión», «creado por mí» y «tú aprobaste esto» sean correctos en un espacio de trabajo mixto.

Si la identidad de una forja no se ha resuelto, sus repos no aportan nada a la bandeja de entrada en lugar de coincidir con todo. La bandeja de entrada lo dice, en vez de afirmar que estás al día.

Una sola bandeja de entrada, todas las forjas

La bandeja de entrada y la cola de PR se despliegan por todas las forjas representadas en el espacio de trabajo y combinan los resultados en un único flujo: una pull request de GitHub y una pull request de Bitbucket aparecen una junto a la otra, ordenadas por hora en lugar de agrupadas por proveedor.

Los fallos están aislados. Una forja caída, con el límite de velocidad alcanzado o sin conectar no aporta nada y deja intactas a las demás; nunca vacía toda la bandeja de entrada. Sus propios repos siguen mostrando su último estado conocido hasta que se recupere.

Qué puede hacer cada forja

Todas las forjas admiten el ciclo básico: listar y abrir pull requests, leer diffs, comentar en línea y a nivel general, revisar, fusionar y cerrar. Más allá de eso, difieren de verdad, y Control Center oculta lo que una forja no puede hacer en lugar de mostrar un control que falla en silencio.

Capacidad	GitHub	GitLab	Bitbucket
Revisiones por lotes (pendientes)	✓	✓	—
Solicitar cambios	✓	✓	✓
Estado «visto» por archivo sincronizado	✓	—	—
Reacciones con emoji	✓	✓	—
Revisores de equipo / grupo	✓	✓	—
Revisores sugeridos	✓	—	✓
Resultados de CI en una PR	✓	✓	✓
Profundizar en los pasos/registros de un trabajo de CI	✓	✓	—
Pull requests apiladas	✓	—	—
Plantillas de descripción de PR	✓	✓	—
Sondeo de notificaciones	✓	—	—
Perfiles de usuario enriquecidos	✓	✓	—
Ref de head de la PR en el servidor	✓	✓	—

Cuando falta una capacidad, la función se degrada con honestidad:

El estado de «visto» sigue funcionando, pero solo en el dispositivo donde lo marcaste.
Las revisiones por lotes en Bitbucket se publican comentario a comentario, así que quienes revisan las ven llegar de una en una en lugar de todas a la vez.
Sin ref de head de la PR en Bitbucket, hacer checkout de una pull request obtiene su rama de origen por nombre, lo que falla en cuanto esa rama se elimina.

Vocabulario

GitLab llama a una pull request merge request. Control Center dice «pull request» en todo su propio modelo, y usa el sustantivo propio de cada forja cuando habla de esa forja.

Solución de problemas

La lista de PR está vacía y dice que una forja no está conectada

No tienes ninguna credencial para esa forja. Inicia sesión o pega un token en Ajustes → Espacio de trabajo → Perfil e identidad → Alojamiento de código. Los repos de las demás forjas no se ven afectados.

Conecté una forja, pero sus repos siguen sin mostrar nada

Comprueba el subtítulo de la fila. Si dice «mediante la app de este servidor» o «desde el entorno», está respondiendo una credencial distinta de la que esperabas —tu propia credencial gana para todo lo que pidas, así que si dice otra cosa, la tuya no se guardó.

Un repo no se registra

El registro necesita las tres cosas: que la ruta esté dentro de un árbol de trabajo de git, que tenga un remoto origin y que ese remoto apunte a github.com, gitlab.com o bitbucket.org. Consulta Agregar repos a un espacio de trabajo.

Todo deja de funcionar un rato tras un uso intensivo

Ese es el cortacircuitos del límite de velocidad. Cuando una forja señala su límite principal, el cliente hace que las siguientes peticiones fallen localmente, sin ninguna llamada de red, hasta que transcurra la ventana —así una tormenta de reintentos no puede agravar el límite. Los fallos transitorios se reintentan con retroceso exponencial.