Guía de los espacios Git

Un repositorio Git de Flow es un repositorio de verdad (lo clonas y le haces push con el git que ya usas) que vive dentro de Flow en lugar de en un servicio externo. Código, tasks y pull requests están donde están también tus archivos: mismo inicio de sesión, mismos miembros y permisos, misma copia de seguridad, misma instancia: europea o en tu empresa.

Está pensado para quien no quiere (o no puede) sacar el código fuera: el repositorio es un espacio como los demás, con sus miembros y dos roles (editor hace push, lector clona y lee), además de los administradores, que pueden hacerlo todo. Los repositorios aparecen en la sección Repositorios de la barra lateral, y ocupan espacio en la cuota del plan como todo lo demás.

En el navegador encuentras cinco pestañas: Código, Commits, Tasks, Pull requests y Acceso. Las dos primeras son para consultar, las demás para trabajar: el trabajo en equipo (quién hace qué, qué entra en la rama principal) ocurre ahí.

El clone y el push pasan por HTTPS, con credenciales creadas a propósito:

• nombre de usuario = tu email;
• contraseña = una contraseña Git, que creas tú mismo en la pestaña Acceso del repositorio («Cómo conectarse», con el comando de clone ya listo para copiar).

La contraseña se muestra solo en el momento de crearla: cópiala en el gestor de credenciales de git (en Mac osxkeychain, en Windows Git Credential Manager) y no te la volverá a pedir. Si la pierdes, no se recupera: creas otra y revocas la antigua. Tus contraseñas Git las ves y las revocas en Cuenta → Git; una contraseña vale para todos los repositorios a los que tienes acceso, y para nada más: no abre la app y no vale para la API.

Quién puede hacer qué lo decide el rol en el espacio: editor hace push de ramas y tags como en cualquier remoto, lector solo clone y fetch. Quien no es miembro ni siquiera ve el repositorio.

La pestaña Código muestra el árbol de archivos en la rama elegida, y la página principal del repositorio abre el README de la raíz, como esperas. Los archivos de texto se leen ahí; para un binario o un archivo muy grande, el navegador lo dice claramente: te indica que lo clones.

La pestaña Commits es la historia de la rama: cada commit se abre en su diff. Desde el texto de tasks y comentarios, un sha lleva directamente al diff de ese commit.

El navegador está pensado para leer y decidir: se escribe en local, con tu propio editor, y se hace push. La única escritura que pasa por la web es la que tiene que pasar por ella: fusionar una pull request.

Los tasks son donde el equipo se comunica: bugs que corregir, cambios que pedir, cosas que hacer, discusiones. Cuatro tipos (Bug, Solicitud de cambio, To-do, Discusión) y, por lo demás, la misma forma: título, texto en Markdown, comentarios, estado abierto/cerrado.

Cada task tiene un número: escribir #12 en un task, en un comentario o en una pull request crea el enlace; un sha de commit se convierte en el enlace a su diff. Un task puede tener una persona asignada (entre los miembros), etiquetas y una prioridad; los filtros de la parte superior de la lista («Abiertos», «Mis tasks», la búsqueda) sirven para orientarse cuando los tasks son muchos.

Lo que aún no has leído se nota: el task con novedades aparece en negrita, y la pestaña muestra el contador «sin leer». Los emails siguen tu preferencia en Cuenta → Notificaciones por email → Tasks: quien participa en un task (autor, persona asignada, quien ha comentado) recibe asignaciones, comentarios y cierres.

A un task se le adjuntan archivos: van a una carpeta «Task #n» del espacio, y en el texto queda la referencia. Útil para capturas de pantalla, logs, documentos de partida: están en el repositorio de quien trabaja en él, no en un chat externo.

Una pull request propone fusionar una rama en otra. La abres eligiendo las dos ramas (una PR abierta por rama a la vez), y la pestaña te dice al instante y en directo cómo está: «Se fusiona sin conflictos: n commits», o bien la lista de los archivos en conflicto, que resuelves en local, y con el push siguiente la pestaña se actualiza.

Debajo están los commits que llegan y el diff completo. Se comenta al final o en una línea concreta del diff: cada línea abre un hilo con Responder y Resolver, y los hilos de las líneas que un nuevo push ha cambiado no se pierden: pasan al final, con su ruta y su número de línea.

Las revisiones dan el veredicto: Aprobar o Pedir cambios (nunca en la propia PR). Cuenta el último veredicto de cada persona, y una aprobación vale para la versión de la rama sobre la que se dio: tras un nuevo push queda marcada «sobre una versión anterior» y deja de contar.

Fusionar desde la web, eligiendo cómo entran los commits:

• commit de merge: la historia queda como está, con un commit de fusión firmado por quien pulsa el botón;
• squash: todos los commits condensados en uno solo, firmado por quien abrió la PR;
• rebase: los commits vuelven a ponerse en fila sobre el destino, sin commit de merge.

Existe la opción «eliminar la rama tras la fusión», y si en cambio fusionas desde el terminal con git, la PR lo detecta sola y se marca «Fusionada con git».

En una rama protegida nadie hace push directo, tampoco los editores: quien lo intenta recibe el rechazo del servidor, con el motivo por escrito. En la rama se entra de una sola manera: fusionando una pull request desde la web.

Una rama se protege desde la pestaña Acceso (hace falta un administrador), y para cada rama se puede exigir un número de aprobaciones: la PR se fusiona solo cuando hay suficientes revisiones aprobadas, y una revisión «pedir cambios» la bloquea hasta que cambia. El administrador puede fusionar de todos modos: la regla ordena el trabajo del equipo, no le quita las llaves.

Es la forma de decir «a main solo se llega con una PR revisada», y de hacer que lo aplique el servidor en lugar de un acuerdo verbal.

Cada push se pone a salvo al instante, en el mismo archivo protegido que tus archivos: copias redundantes, controles continuos, restauración automática. No hay nada que configurar ni nada que recordar.

La página del repositorio te dice cuándo se hizo la última copia («Copia de seguridad al día…») y, si una copia no se ha completado, te lo indica.

En la cuota del plan, el repositorio ocupa lo que ocupa de verdad, con la deduplicación que se aplica a todo lo demás: un repositorio normal ocupa poco.

La contraseña Git abre también una puerta más: las rutas API de los tasks y de las pull requests (/api/repos/…/tasks y /api/repos/…/pulls). Con un curl autenticado (usuario tu email, contraseña la contraseña Git) se listan los tasks, se lee una PR, se comenta, se adjunta un archivo a un task o a una PR. Solo esas rutas: para el resto de la API hace falta un token API de verdad (lo explica la página Desarrolladores).

Sirve a quien automatiza su propio flujo (scripts, herramientas de desarrollo, agentes) sin repartir credenciales más amplias de lo necesario: la contraseña Git se puede revocar en un clic desde Cuenta → Git, y su alcance es el trabajo en el repositorio.