// Documentação do Singularity
Sincronizar vários repositórios: fetch, pull, push e push rejeitado
A vista Git do Navigator mostra o ramo e a diferença em relação ao remoto de cada projeto do workspace. Faz fetch, pull e push sem mudar de separador, e deixa o Singularity guiar a recuperação quando um push é rejeitado.
Todos os repositórios do workspace num relance
No Navigator, muda para a vista Git: cada projeto do workspace mostra o seu ramo atual e os contadores ↑ (commits locais por publicar) e ↓ (commits remotos por integrar). Um ícone de alerta assinala um repositório que requer a tua atenção.
Expande um projeto para ver os ficheiros não preparados, não monitorizados e preparados, os stashes e os worktrees, e faz commit a partir do compositor no fundo do painel. Um fetch automático em segundo plano mantém os contadores atualizados.
Fetch, Pull e Push ao passar o rato
Passa o rato sobre um projeto para mostrar as suas ações: Fetch descarrega as referências remotas sem tocar nos teus ficheiros, Pull integra o ramo upstream — por merge ou por rebase, consoante a divergência — e Push publica os teus commits. O menu … reúne as restantes ações do repositório.
Assim, sincronizas vários repositórios seguidos sem abrir o respetivo cockpit. Uma notificação confirma cada operação, por exemplo «Pushed to origin – 4 commits». Para o detalhe do cockpit, consulta sincronizar com o remoto.
Quando o push é rejeitado
Se o ramo remoto tiver avançado, o Git recusa o push. O Singularity abre o diálogo Push rejected — “main” is behind the remote e propõe três opções:
- Pull first integra as alterações remotas localmente para que as verifiques antes de um novo envio. É a opção segura.
- Force push substitui o ramo remoto pelo teu histórico local com
--force-with-lease. - Cancel deixa os dois ramos inalterados.
Se a recuperação também falhar, o Singularity propõe um ticket de correção. Nos workflows GitHub, também consegue reparar uma configuração SSH avariada.
Com agentes em paralelo
Os agentes trabalham nos seus próprios worktrees e a fila de commits integra o seu trabalho um ticket de cada vez, por rebase, sem commit de merge. O teu ramo principal pode, portanto, avançar enquanto trabalhas: faz um Fetch antes do push e prefere Pull first a um push forçado num ramo partilhado.
Perguntas frequentes
Porque é que o meu push é rejeitado?
O repositório remoto contém commits que não existem no teu ramo local: alguém — ou um agente — fez push entretanto. Escolhe Pull first para integrar esses commits, verificar e voltar a fazer push.
Forçar o push apaga o trabalho dos outros?
Substitui o ramo remoto pelo teu histórico local com --force-with-lease, que recusa o envio se o ramo remoto tiver mudado desde o teu último fetch. Os commits remotos que não obtiveste ficam portanto protegidos, mas os que substituis conscientemente desaparecem do ramo.