// Documentación de Singularity
Sincronizar varios repositorios: fetch, pull, push y push rechazado
La vista Git del navegador muestra la rama y la diferencia con el remoto de cada proyecto del espacio de trabajo. Recupera, integra y envía sin cambiar de pestaña, y deja que Singularity te guíe para recuperarte cuando un push es rechazado.
Todos los repositorios del espacio de trabajo de un vistazo
En el navegador, cambia a la vista Git: cada proyecto del espacio de trabajo muestra su rama actual y sus contadores ↑ (commits locales pendientes de publicar) y ↓ (commits remotos pendientes de integrar). Un icono de alerta señala un repositorio que requiere tu atención.
Despliega un proyecto para ver sus archivos sin preparar, sin seguimiento y preparados, sus stashes y sus worktrees, y hacer commit desde el compositor de la parte inferior del panel. Un fetch automático en segundo plano mantiene los contadores al día.
Fetch, Pull y Push al pasar el ratón
Pasa el ratón por encima de un proyecto para que aparezcan sus acciones: Fetch descarga las referencias remotas sin tocar tus archivos, Pull integra la rama upstream —mediante merge o rebase según la divergencia— y Push publica tus commits. El menú … agrupa las demás acciones del repositorio.
Así sincronizas varios repositorios seguidos sin abrir su cockpit. Una notificación confirma cada operación, por ejemplo «Pushed to origin – 4 commits». Para los detalles del cockpit, consulta sincronizar con el remoto.
Cuando el push es rechazado
Si la rama remota ha avanzado, Git rechaza el push. Singularity abre el diálogo Push rejected — “main” is behind the remote y ofrece tres opciones:
- Pull first integra los cambios remotos en local para que los compruebes antes de un nuevo envío. Es la opción segura.
- Force push sustituye la rama remota por tu historial local con
--force-with-lease. - Cancel deja ambas ramas sin cambios.
Si la recuperación también falla, Singularity propone un ticket de corrección. En los workflows de GitHub, también sabe reparar una configuración SSH defectuosa.
Con agentes en paralelo
Los agentes trabajan en sus propios worktrees y la cola de commits integra su trabajo un ticket tras otro, mediante rebase, sin commits de merge. Por tanto, tu rama principal puede avanzar mientras trabajas: haz un Fetch antes del push y prefiere Pull first al envío forzado en una rama compartida.
Preguntas frecuentes
¿Por qué se rechaza mi push?
El repositorio remoto contiene commits que no están en tu rama local: alguien —o un agente— ha hecho push mientras tanto. Elige Pull first para integrar esos commits, comprobarlos y volver a hacer push.
¿Forzar el envío borra el trabajo de los demás?
Sustituye la rama remota por tu historial local con --force-with-lease, que rechaza el envío si la rama remota ha cambiado desde tu último fetch. Los commits remotos que no has recuperado quedan, por tanto, protegidos, pero los que sobrescribes a sabiendas desaparecen de la rama.