GitGres : ton GitHub privé sur PostgreSQL

Pourquoi quitter GitHub ?

GitHub marche bien pour 95% des cas. Mais si tu entraînes des agents IA localement, gères des données sensibles, ou que ton infra tourne sur du matériel maison, ses contraintes deviennent rapidement un frein :

• ▸Disponibilité imprévisible : GitHub tombe, ta pipeline d'agents s'arrête.
• ▸Latence variable : chaque requête traverse le réseau public ; GitGres peut vivre à côté de tes agents.
• ▸Cohérence faible : GitHub synchronise les données « à son rythme » ; GitGres garantit l'ordre des requêtes.

Ce que te donne GitGres

C'est un serveur Git minimal écrit en Rust, alimenté par PostgreSQL. Zéro disque — tout vit en base :

• ▸Objets Git, packfiles, deltas
• ▸Références, branches, tags
• ▸PRs, issues, commentaires, reviews
• ▸Jetons, équipes, organisations
• ▸Journaux d'événements

Tu configures 3 variables d'env, tu lances gitgres init et gitgres serve, et hop — tu as une instance Git clonée/pushée en HTTP ou via gh CLI standard.

Exemples concrets

Cloner :

git clone http://gitgres.host/owner/repo.git

Intégrer gh CLI :

gh auth login --hostname gitgres.host --with-token
gh pr create
gh issue list

Affiner les performances :

• ▸Choisis ton cache Postgres (stockage hiérarchisé, compression).
• ▸Ajuste GITGRES_WORKERS (threads HTTP).
• ▸Fais tourner le serveur colocalisé avec tes agents.

Les limites actuelles

C'est un MVP. Pas de : recherche, GitHub Actions, SSH, webhooks, HTTP/2, interface web. Mais le code est ouvert — tu peux l'étendre.

Pour qui ?

• ▸Équipes d'agents IA qui ont besoin de dépôts locaux rapides.
• ▸Organisations exigeantes sur la sécurité et la souveraineté des données.
• ▸Développeurs qui veulent expérimenter l'architecture sans s'enchaîner à GitHub.

Si tu roules solo ou que GitHub te suffit, laisse tomber. Si tu cherches à reprendre le contrôle, c'est une rampe d'accès claire.