Accueil / Fonctionnalités / Code / GitNest

GitNest — hébergement Git privé avec clone et push sur osFoundry

Du vrai Git en HTTPS pour les dépôts de votre espace de travail, avec des jetons d’accès que vous maîtrisez.

GitNest est l’hébergement Git intégré d’osFoundry. Chaque dépôt de votre espace de travail dispose d’un vrai remote Git que vous pouvez cloner et sur lequel vous pouvez pousser en HTTPS, avec n’importe quel client Git standard : aucun plugin, aucun export, aucun second compte. L’authentification repose sur des jetons d’accès d’espace de travail que vous créez et révoquez vous-même. Le dépôt que vous clonez est celui-là même que l’IDE web modifie et que Maestro lit : le travail fait sur votre machine et celui fait dans l’espace de travail partagent le même historique.

Réponse rapide

Clonez n’importe quel dépôt de l’espace de travail et poussez dessus en HTTPS, avec Git standard.
Authentifiez-vous avec des jetons d’accès que vous créez, limitez et révoquez vous-même.
Les dépôts sont privés à leur espace de travail par défaut.
L’IDE web s’appuie sur le même dépôt : un push apparaît donc dans l’espace de travail.
Compatible avec tout client Git : ligne de commande, IDE ou job de CI.

Présentation

GitNest est un remote Git qui appartient à votre espace de travail. Ce n’est pas le miroir d’un dépôt hébergé ailleurs, et ce n’est pas un remplaçant de l’hébergement open source public : c’est l’endroit où vit le code de votre espace de travail, accessible depuis votre machine avec le Git que vous utilisez déjà. Comme il s’agit de vrai Git et non d’un export, les commandes habituelles fonctionnent sans rien changer : clone, fetch, branche, push, et tous les outils bâtis dessus.

Fonctionnalités clés

Clone, fetch et push en smart-HTTP, via l’implémentation de référence de Git.
Jetons d’accès par utilisateur, avec date d’expiration et révocation en un clic.
Autorisation limitée à l’espace de travail : un jeton n’atteint que les dépôts du sien.
Accès en lecture et en écriture décidé dépôt par dépôt : un jeton peut se voir refuser un push.
Les push remontent dans l’espace de travail : l’IDE web et Maestro voient ce que vous avez poussé.
Les versions publiées sont protégées : un push qui en réécrirait une est refusé, pas appliqué en silence.

Comment faire dans osFoundry

Créez un jeton d’accès — Ouvrez Paramètres → jetons de dépôt et créez-en un. Il n’est affiché qu’une fois : copiez-le tout de suite. Donnez-lui une expiration — un jeton qui n’expire jamais est un jeton dont vous ne cesserez jamais de vous inquiéter.
Copiez l’URL de clone — Ouvrez le dépôt dans Code et utilisez le panneau Clone. L’URL contient votre espace de travail, car un client Git ne peut pas envoyer d’en-têtes personnalisés : l’adresse doit se suffire à elle-même.
Clonez-le — Lancez git clone avec cette URL. Quand Git demande un mot de passe, saisissez votre jeton ; le nom d’utilisateur importe peu. Un gestionnaire d’identifiants le retiendra.
Committez et poussez comme d’habitude — Créez vos branches, committez et poussez avec les commandes que vous connaissez déjà. Rien dans ce flux de travail n’est spécifique à osFoundry.
Retrouvez-le dans l’espace de travail — Le push est répercuté dans l’espace de travail : la branche et ses fichiers apparaissent dans l’IDE web et deviennent accessibles à Maestro.

Comment osFoundry se compare

Fonctionnalité	osFoundry	La plupart des autres outils
Où vit le code	Un vrai remote Git, à l’intérieur de votre propre espace de travail.	Un compte d’hébergement séparé, relié par une intégration.
Récupérer le code	git clone — la commande standard, sans étape d’export.	Télécharger une archive, ou installer un plugin pour synchroniser.
Identifiants	Des jetons d’espace de travail que vous créez et révoquez, avec expiration.	Un mot de passe de compte, ou une autorisation OAuth accordée à un tiers.
Éditeur et remote	Le même dépôt sert aux deux : aucun décalage possible.	Un dépôt hébergé, recopié dans l’éditeur et resynchronisé par un job.

Cas d’usage

Développeur qui préfère travailler en local: Il clone le dépôt de l’espace de travail, travaille dans son propre éditeur avec ses propres outils, puis pousse. L’équipe voit la modification dans l’espace de travail sans que personne ait eu à exporter quoi que ce soit.
Pipeline de CI: Un job de build clone le dépôt avec un jeton restreint et daté, exécute la suite de tests, et n’a jamais besoin d’un compte humain ni d’un identifiant personnel.
Équipe qui garde son code hors des hébergeurs publics: Elle conserve ses dépôts privés au sein de l’espace de travail tout en travaillant avec du Git ordinaire, sans avoir à sacrifier ses outils habituels pour rester confidentielle.

Questions fréquentes

Qu’est-ce que GitNest ?

GitNest est l’hébergement Git intégré d’osFoundry. Il donne à chaque dépôt de votre espace de travail un vrai remote Git, que vous pouvez cloner et sur lequel vous pouvez pousser en HTTPS avec n’importe quel client Git standard.

GitNest remplace-t-il GitHub ?

Non, et ce n’est pas son objectif. GitHub reste l’endroit de l’hébergement open source public et de la communauté qui l’entoure. GitNest, c’est là où vivent les dépôts propres à votre espace de travail, pour que vous puissiez y travailler en local et dans osFoundry sans déplacer du code entre deux systèmes.

Puis-je utiliser mes commandes Git habituelles ?

Oui. GitNest parle le protocole smart-HTTP standard de Git, en s’appuyant sur l’implémentation de référence de Git : clone, fetch, branche et push se comportent exactement comme ailleurs.

GitNest prend-il en charge SSH ?

Pas pour l’instant : GitNest fonctionne uniquement en HTTPS. Vous vous authentifiez avec un jeton d’accès d’espace de travail plutôt qu’avec une clé SSH.

Comment m’authentifier ?

Créez un jeton d’accès dans les Paramètres et utilisez-le comme mot de passe quand Git vous le demande. Le nom d’utilisateur n’est pas vérifié. Les jetons ne sont affichés qu’une fois, peuvent recevoir une date d’expiration et être révoqués à tout moment.

Que se passe-t-il quand je révoque un jeton ?

Il cesse de fonctionner immédiatement, dès la requête suivante. Ce qui a déjà été cloné sur une machine y reste : révoquer un jeton coupe les accès futurs, cela ne va pas supprimer une copie de travail à distance.

Mes dépôts sont-ils privés ?

Oui. Les dépôts sont privés à leur espace de travail par défaut, et un jeton n’atteint que les dépôts de l’espace de travail auquel il appartient.

Un push apparaît-il dans l’espace de travail ?

Oui. Une fois le push accepté, la branche et ses fichiers sont répercutés dans l’espace de travail : l’IDE web affiche ce que vous avez poussé et Maestro peut le lire.

Puis-je pousser sur une version publiée ?

Non, et le push est refusé d’emblée plutôt qu’appliqué à moitié. Une version publiée est un enregistrement figé ; si un push devait en réécrire une, GitNest le rejette et vous indique quelle branche est en cause, sans toucher à votre dépôt.

Puis-je utiliser GitNest depuis la CI ?

Oui. Créez un jeton avec une expiration, stockez-le dans le gestionnaire de secrets de votre fournisseur de CI, et clonez avec lui comme avec n’importe quel autre remote Git.

Tarifs

L’hébergement d’un dépôt fait partie de votre espace de travail : il n’y a pas de facturation séparée par dépôt ni selon leur nombre. Le trafic de clone et de push est comptabilisé dans la consommation de votre espace de travail, comme toute autre bande passante.