Gitsi
Git auf deinem eigenen Server
Ein Team-Repository liegt auf einem SSH-Host, den du bereits hast. Klonen und Pushen erfolgen direkt per SSH zu diesem Host: Dein Laptop darf ausgeschaltet sein, der Host muss jedoch erreichbar bleiben.
Die folgenden Bedienelemente sind mit ihren Namen aus der englischen Oberfläche angegeben.
This machine: nur für dich
Ein lokales Remote erstellen
Installiere git auf deinem Computer und öffne Gitsi → This machine. Gib einen Repository name ein und drücke Create. Das Bare-Repository liegt standardmäßig unter ~/termiyo-repos; das ist kostenlos, es wird nichts hochgeladen und Teammitglieder können über diese Funktion nicht darauf zugreifen.
Lokal pushen oder klonen
Wähle Copy both lines und führe die beiden Zeilen im Projekt aus, das du pushen möchtest. Mit Copy the clone line erstellst du eine weitere Arbeitskopie auf demselben Computer.
On a host — Neu in 0.4.22
1. Mit deinem Server verbinden
Öffne in Termiyo eine SSH-Sitzung zum Host und prüfe dabei seinen Hostschlüssel; für das Teilen per Link muss der Host außerdem in Termiyo gespeichert sein, eine Schnellverbindung reicht dafür nicht. Der Host benötigt git; um Zugriff zu gewähren, ist außerdem OpenSSH 7.7 oder neuer erforderlich. Jedes Teammitglied braucht einen Netzwerkweg zu diesem Host, gegebenenfalls über ein eigenes VPN oder einen eigenen Sprunghost.
2. Vorbereiten und erstellen
Öffne Gitsi → On a host und wähle die Sitzung, falls mehrere geöffnet sind. Drücke Prepare this host, wenn die Schaltfläche angeboten wird, gib dann einen Repository name ein und drücke Create. Termiyo speichert das Bare-Repository unter ~/termiyo-repos/<name>.git auf diesem Host; die Vorbereitung erfolgt im Home-Verzeichnis des SSH-Kontos und benötigt weder Root-Zugriff noch einen zusätzlichen Daemon.
3. Deinen Schlüssel oder einen Deploy-Schlüssel hinzufügen
Wähle Add a key (yours, or a deploy key), gib einen Namen und den öffentlichen .pub-Schlüssel ein, wähle read only oder read and write und drücke Grant. Geprüft wird nur der bezahlte Tarif des Eigentümers; eine Testphase zählt nicht und der Schlüssel erhält ein an diesen Tarif gebundenes Enddatum. Copy the invitation liefert die Git-Befehle; der Empfänger kann gewöhnliches git verwenden.
Grenzen
Repository-Zugriff mit festgelegtem Umfang
Termiyos lokaler/SSH-Repository-Modus bietet keinen Repository-Webbrowser, keine Pull Requests, Issues, Code-Reviews oder Paket-Registry. Die Freigaben steuern Fetch und Push für die installierten Schlüssel; wer gewöhnlichen Shell-Zugriff auf das Hostkonto hat, kann direkt auf die Repositories zugreifen. Ein Push identifiziert einen Schlüssel, nicht den Autor eines Commits.
Bisherige Prüfung
Der vollständige Ablauf zum Teilen per Link wurde noch nicht mit echten bezahlten Konten geprüft.
Vorschau · noch nicht veröffentlicht
Dein Gitsi-Konto in Termiyo
Erstelle dein eigenes Gitsi-Konto oder melde dich an. Verbinde es anschließend per Browser-Zustimmung oder persönlichem Token. Das Dashboard erscheint nach der Kontoprüfung; Termiyo stellt kein gemeinsames Konto und keine Repositorys des Produktinhabers bereit. OAuth beginnt mit Lesezugriff; Repository-Erstellung erfordert zusätzliche Zustimmung, Pull Requests derzeit ein persönliches Token mit passenden Issue-Berechtigungen. Für private und geteilte Repositorys gelten deine Kontorechte. Token werden lokal durch das Betriebssystem geschützt; Trennen entfernt die lokale Verbindung.
Durchsuche deine Repositorys, erstelle neue und bearbeite Pull Requests mit deinem eigenen Gitsi-Konto.
Die Vorschau umfasst das Durchsuchen und Erstellen von Repositorys sowie Pull Requests mit Beschreibung, Diff und Commit-Prüfungen. Pull Requests können nicht zusammengeführt werden. HTTPS-Klonen ist auf macOS und Linux verfügbar; Windows, natives Pull/Push, LFS-Downloads und das Initialisieren von Submodulen sind nicht enthalten.
Einen Pull Request bei geöffneter App beobachten
Beobachte ausdrücklich einen Gitsi Pull Request eine Stunde lang, mit Abfragen alle 60 Sekunden, solange Termiyo geöffnet und entsperrt bleibt. Verwende dein eigenes persönliches Token mit read:issue und read:repository. Beobachtete Änderungen ergeben nur einen bearbeitbaren Textentwurf, ohne KI-Aufruf oder Repository-Änderung. Nach Neustart oder verweigerter Berechtigung bleiben alte Karten bis zu einem neuen erfolgreichen Start verborgen.