GitRoot

 (gitroot.dev)
2 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • GitRoot ist eine kleine Git-Forge, die Repositorys und Zugriffsrechte in einer einzigen Binärdatei verwaltet und über eigenständige Plugins Issues, Boards, Branch-Merges und eine Weboberfläche kombiniert
  • Neben Code speichert sie auch Issues, Merge Requests und Boards: Alle Daten werden als normale Dateien in Git gespeichert, ohne Abhängigkeit von einer separaten Datenbank oder versteckten Blobs
  • Änderungen werden über .gitroot/users.yml und branchspezifische Schreibrechte kontrolliert; auf den Default Branch, der den aktuellen Zustand des Repositorys darstellt, dürfen nur autorisierte Nutzer pushen
  • Derzeit Alpha-Version: Unterstützt Repositorys, Nutzer, Plugins, SSH-Git-Befehle und HTTP-Ansicht, ist aber nicht für den Produktionseinsatz geeignet
  • Bis Version 1.0 sind Updates, dateibasierte Rechte, HTTP-Git-Befehle, Gruppen und Untergruppen sowie die Stabilisierung der Plugin-API geplant; aktuelle Beiträge erfordern Verständnis von Git und dem grafter-Plugin-Workflow

Kleine Git-Forge, die nur die benötigten Funktionen kombiniert

  • GitRoot ist eine kleine Git-Forge, die als einzelne Binärdatei läuft und ihre Kernfunktionen auf das Erstellen von Repositorys sowie die Verwaltung von Zugriffsrechten pro Repository beschränkt
  • Die übrigen Funktionen übernehmen Plugins, die unabhängig voneinander installiert werden können
    • Erstellen von Issues, Roadmaps, Sprints und Milestones
    • Anzeigen von Einträgen in Board-Form
    • Überprüfung und Zusammenführung von Branches, die GitRoot graft nennt
    • Bereitstellung von Repository-Daten und verschiedenen Funktionen über eine Weboberfläche
  • Da Plugins vollständig getrennt sind, kann man nur Boards ohne Weboberfläche verwenden und auch eigene Plugins für die im Projekt benötigten Funktionen erstellen

Design, das die Forge an das Projekt anpasst

  • Ausgehend davon, dass jedes Projekt andere Arbeitsweisen benötigt, ist GitRoot so konzipiert, dass jedes Projekt die Freiheit hat, seine eigene Forge anzupassen
  • Die gewünschte Umgebung für Entwickler sieht so aus
    • Code, Issues, Pull/Merge Requests und Boards in einem einzigen Repository speichern
    • Funktionen bereitstellen, die für Projektwerbung und Betrieb nötig sind, etwa Landing Page, Übersetzungen, Ticketsystem oder Forum
    • Zu einer anderen Server-Forge migrieren, ohne Migrationsskripte und ohne Verlust der Darstellung von Daten oder Beitragenden
  • Umgekehrt sollen folgende Komplexitäten vermieden werden
    • Ein Arbeitsablauf, bei dem man den Browser öffnen muss, um Pull/Merge Requests oder Issues zu verwalten
    • Eine Struktur, die Neulingen im Projekt zuerst nur eine Liste von Dateien und Verzeichnissen zeigt
    • Eine Forge, die Bedeutung und Workflow von Sprints, Milestones, Epics und User Stories vorgibt
    • Eine Struktur, bei der man mehrere Menüs durchlaufen muss, um eine einzige Nutzerberechtigung zu setzen

Autonomie bei Installation und Betrieb

  • Ziel ist eine Distribution ohne Abhängigkeiten und Datenbank, die Administratoren leicht installieren und warten können
  • Administratoren sollen festlegen können, welche Aktionen pro Nutzer erlaubt sind; Nutzer sollen die Erstellung von Projekten und Funktionen sowie den Zugriff darauf direkt anfragen können, ohne E-Mail oder Chat
  • Ziel ist es, den Upgrade-Aufwand zu reduzieren, Projekt- und Nutzerdaten nicht an Dritte weiterzugeben und nicht von großen Anbietern abhängig zu sein, die ihre Betriebsregeln plötzlich ändern können
  • Das Projekt ist noch nicht fertiggestellt und nimmt externe Beiträge an

Rechteverwaltung über normale Dateien und Branches

  • Statt Datenbanken oder versteckter Blobs im Git-Tree speichert GitRoot alle Daten in normalen Dateien neben dem Code
  • .gitroot/users.yml jedes Repositorys legt fest, an welchen Stellen einzelne Nutzer schreiben dürfen; die Zugriffskontrolle funktioniert vor allem über Branch-Beschränkungen
    • Anfangs hat nur der Owner Zugriff auf den Default Branch
    • Wenn ein Nutzer ohne Berechtigung auf den Default Branch pusht, lehnt GitRoot die Änderung ab
    • Jeder kann einen neuen Branch erstellen; der erstellende Nutzer erhält Schreibrechte für diesen Branch, andere Nutzer können ihn nicht ändern
    • Wird .gitroot/users.yml geändert oder ein Branch gemergt, in dem ein Nutzer sich selbst hinzugefügt hat, kann dieser Nutzer ebenfalls auf den Default Branch pushen
  • Jeder kann Dateien lesen und lokal oder in einem neuen Branch ändern, doch um Änderungen in den Default Branch zu übernehmen, der den aktuellen Zustand des Repositorys darstellt, ist ein Merge durch den Owner erforderlich
  • Auch die Konfiguration der Forge selbst wird im Root-Repository verwaltet
    • Ein Repository wird erstellt, wenn eine Änderung in .gitroot/repositories.yml im Default Branch des Root-Repositorys hinzugefügt oder eine entsprechende Änderung gemergt wird
    • Die genaue Funktionsweise ist in der Dokumentation beschrieben

In der Alpha-Version unterstützte Funktionen

  • Da GitRoot derzeit eine Alpha-Version ist, kann es getestet werden, sollte aber nicht in Produktion eingesetzt werden
  • Der unterstützte Umfang ist folgender
    • Erstellen und Löschen von Repositorys
    • Verarbeitung von Git-Befehlen über SSH
    • Verwaltung nutzerspezifischer Schreibbereiche auf Repository- und Branch-Ebene
    • Installation von Plugins und Aktivierung pro Repository
    • Ausführung von Plugins im Working Tree bei der Installation
    • Ausführung von Plugins auf Basis des Diffs nach der Installation bei jedem Commit
    • Repository-Ansicht über HTTP

Entwicklungsplan bis 1.0

  • Bis Version 1.0 sollen folgende Funktionen implementiert werden
    • Updates für GitRoot und Plugins
    • Verwaltung von Nutzerrechten auf Dateiebene
    • Verarbeitung von Git-Befehlen über HTTP
    • Repository-Verwaltung mit Gruppen und Untergruppen
    • Stabilisierung der Plugin-API

Self-Hosting und Beitragsprozess

  • Die GitRoot-Website ist eine GitRoot-Instanz, die den GitRoot-Code selbst hostet, und wird ausschließlich für das GitRoot-Projekt betrieben
  • Wer GitRoot für andere Projekte testen möchte, sollte der Installations- und Nutzungsdokumentation folgen
  • Da GitRoot selbst ebenfalls ein GitRoot-Repository ist, kann man auf dieselbe Weise beitragen; das Verfahren ist im Beitragsleitfaden beschrieben
  • Die aktuelle Instanz verwendet das grafter-Plugin, um Teile des Codes in den Default Branch zu integrieren; vor einem Beitrag muss man verstehen, wie es funktioniert
  • Da alle Daten, einschließlich Code, Issues und Übersetzungen, in Git gespeichert werden, muss man für aktuelle Beiträge Git bedienen können
  • Langfristig ist das Ziel, dass jeder direkt im Browser git commit und git push ausführen und so mitwirken kann

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Meinungen auf Lobste.rs
  • GitHub war nicht nur die größte Git-Forge, sondern auch die einflussreichste; ihre Spuren sind auch im Design von Forgejo und GitLab zu erkennen. Der Niedergang von GitHub könnte dazu führen, dass verschiedene Forges entstehen, die sich vom bisherigen Modell lösen, wodurch es offenbar mehr Raum für Innovation gibt
    • Gitea hat früher das GitHub-Frontend nahezu 1:1 kopiert, und als Forgejo von Gitea geforkt wurde, hat es diese Form unverändert übernommen
  • Ich bin der Entwickler von GitRoot; wenn es Fragen gibt, können sie gern gestellt werden
    • Drei Dinge interessieren mich. Ich frage mich, warum das CSS minifiziert committet wurde: https://gitroot.dev/worktree/app/…
      Die Ursache dafür, dass die Breite des <pre>-Tags auf 720px begrenzt ist, scheint display:grid im body zu sein; wenn man das deaktiviert, wird es wie erwartet breiter. Außerdem enthält die URL keine Informationen zu einem bestimmten Commit-Zeitpunkt, sodass es für Absender und Empfänger eines Links schwierig ist, denselben Stand zu sehen. Ich verstehe, dass es ein Projekt für persönliche Bedürfnisse ist, wollte das aber als prüfenswerte Punkte weitergeben
  • @manland, ich frage mich, ob es eine Policy oder Richtlinien gibt, die mit LLMs erstellte Contributions erlauben oder verbieten
    • Derzeit gibt es keine eigene Policy. Abgesehen von zwei einmaligen Beitragenden habe ich nämlich 99,999 % des Codes selbst geschrieben
      Persönlich nutze ich keine LLMs fürs Coding und lehne das ab, aber wenn ein Patch trotz LLM-Nutzung ausreichend klein ist, bin ich nicht sicher, ob ich ihn ablehnen würde
      Da Englisch nicht meine Muttersprache ist und es mir schwerfällt, GitRoot zu erklären, gibt es in der externen Kommunikation Spuren von LLMs. Ich habe früher auch unter https://gts.gitroot.dev/@forge/statuses/01KFNWDKSZBEHTC16N5G02HJZ6 und https://gts.gitroot.dev/@forge/statuses/01KTP30NTY9FK91Q9B5Z9B4M52 um Hilfe gebeten, aber niemand ist gekommen
      Es schmerzt mich, LLMs verwenden zu müssen, aber statt gar nichts zu tun, habe ich beschlossen, sie so wenig wie möglich einzusetzen. Wenn künftig eine Community entsteht, möchte ich sie vollständig ausschließen; vorher könnten sie meiner Ansicht nach auch aus wirtschaftlichen Gründen von selbst verschwinden. Auf meiner To-do-Liste stehen viele Texte, die Philosophie, Sicherheit und Zukunft erklären sollen, aber der Gedanke, dass am Ende doch ein LLM die Sätze glätten, Tippfehler korrigieren oder übersetzen wird, lässt mich beim Schreiben zögern
  • Mir gefällt, dass TinyGo genutzt wurde, um Go-Plugins nach WASM zu kompilieren