Synchroniser plusieurs dépôts : fetch, pull, push et push rejeté

Dans le navigateur, passez sur la vue Git : chaque projet du workspace affiche sa branche courante et ses compteurs ↑ (commits locaux à publier) et ↓ (commits distants à intégrer). Une icône d’alerte signale un dépôt qui demande votre attention.

Dépliez un projet pour voir ses fichiers non indexés, non suivis et indexés, ses remises et ses worktrees, et committer depuis le composeur en bas du panneau. Un fetch automatique en arrière-plan tient les compteurs à jour.

Survolez un projet pour faire apparaître ses actions : Fetch télécharge les références distantes sans toucher à vos fichiers, Pull intègre la branche amont — par merge ou par rebase selon la divergence — et Push publie vos commits. Le menu … regroupe les autres actions du dépôt.

Vous synchronisez ainsi plusieurs dépôts à la suite sans ouvrir leur cockpit. Une notification confirme chaque opération, par exemple « Envoi vers origin réussi – 4 commits ». Pour le détail du cockpit, voir échanger avec le distant.

Si la branche distante a avancé, Git refuse le push. Singularity ouvre le dialogue Envoi rejeté — « main » est en retard sur le dépôt distant et propose trois choix :

• Tirer d’abord intègre les modifications distantes localement pour que vous les vérifiiez avant un nouvel envoi. C’est le choix sûr.
• Forcer l’envoi remplace la branche distante par votre historique local avec --force-with-lease.
• Annuler laisse les deux branches inchangées.

Si la reprise échoue à son tour, Singularity propose un ticket de correction. Pour les workflows GitHub, il sait aussi réparer une configuration SSH défaillante.

Les agents travaillent dans leurs propres worktrees et la file de commits intègre leur travail un ticket après l’autre, par rebase, sans commit de merge. Votre branche principale peut donc avancer pendant que vous travaillez : faites un Fetch avant de pousser, et préférez Tirer d’abord à l’envoi forcé sur une branche partagée.