Origin ajoute l’hébergement de dépôts à Cursor. Le choix essentiel est de créer un dépôt natif ou de conserver GitHub comme référence avec une copie synchronisée dans Origin.
Accepter un push ne rend pas le miroir indépendant
La documentation Origin décrit une bêta initiale pour Pro, Teams et Enterprise, sous réserve des contrôles de l’équipe. Consultation du code et intégration des agents ne nécessitent pas de déplacer immédiatement tous les services de développement.
Le guide du miroir GitHub prévoit la synchronisation de l’historique Git, des branches et des tags, et des pull requests dans les deux sens. Un push vers le miroir Origin transite vers GitHub, qui reste la référence. Issues, configuration Actions et secrets ne sont pas transférés dans un service CI Origin équivalent.
Cela change l’analyse d’une panne. Pouvoir consulter une copie ne démontre pas que les écritures, contrôles de PR et déploiements fonctionneront indépendamment si GitHub devient indisponible. L’illustration distingue les deux chemins au lieu de présenter Origin comme un secours automatique.
Détacher le dépôt change la référence
L’action documentée Detach from GitHub transforme la copie en dépôt autonome hébergé par Origin. Ses pushes ne transitent plus vers GitHub, dont le dépôt reste intact. Deux dépôts intacts ne constituent pas automatiquement deux références synchronisées.
Avant une migration, faites une répétition sur un dépôt jetable : créez commit et tag, poussez via le miroir, comparez leurs identifiants des deux côtés, puis vérifiez commentaires de PR, contrôles et permissions des branches. Identifiez le système qui exécute le build et conserve les secrets de déploiement. Pour un essai de détachement, documentez la divergence et la réconciliation nécessaire à un retour explicite. Il s’agit d’une évaluation proposée, pas d’une migration effectuée par PeopleAreGeek.
Suivre le contrat actuel de l’API
L’API évolue. Le journal du 5 septembre impose expectedHeadSha à CreateCommitFromFiles pour une branche existante. L’intégration dispose ainsi d’un contrôle explicite de concurrence plutôt que de supposer sa lecture précédente toujours actuelle.
Exemple : deux agents lisent le commit A ; le premier publie B. Le second ne doit pas traiter silencieusement A comme tête actuelle. Il faut gérer le rejet, relire l’état et réconcilier les modifications avant de réessayer. Vérifier que clone fonctionne ne suffit donc pas : code, revues, permissions et automatisations doivent rester d’accord sur la même révision.
Revue du 8 septembre : sources recoupées, données actualisées et explications et visuels remplacés.