- Ziel ist es, das einfachste Git-Kollaborationstool zu bauen
- Einen selbst gehosteten Git-Server so einfach zu betreiben wie einen SSH-Server, ohne dabei Zeit und Energie externer Mitwirkender zu opfern
- Verbindet Mailinglisten- und Pull-Request-Workflows
- Es soll ein Kollaborationstool entstehen, das so einfach ist wie das Erstellen von Patches und zugleich den Bedienkomfort von Pull Requests bietet
- Es geht nicht darum, ein weiteres Code-Repository zu bauen, sondern eine sehr einfache selbst gehostete Git-Lösung zu schaffen, mit der sich mit externen Beitragenden zusammenarbeiten lässt
Was man braucht
- Was Code-Eigentümer zum Betrieb des Git-Servers benötigen:
- eine einzelne Golang-Binärdatei
- Was externe Mitwirkende benötigen:
- ein SSH-Schlüsselpaar
- einen SSH-Client
Die aktuellen Probleme
- E-Mail ist zwar ein hervorragendes verteiltes System zum Senden und Empfangen von Änderungen an Git-Repositories (Patch-Sets), aber schon das Onboarding neuer Nutzer auf einer Mailingliste, das korrekte Einrichten des E-Mail-Clients und schließlich das Einreichen eines Code-Beitrags bringt viele Entwickler dazu aufzugeben
- Da die Zusammenarbeit auf dem E-Mail-Protokoll basiert, ist der Funktionsumfang eingeschränkt. So lassen sich E-Mails etwa nicht bearbeiten, jeder nutzt andere Clients, und diese Clients haben jeweils unterschiedliche Beschränkungen bei Klartext-E-Mails und dem Herunterladen von Patches
- GitHub Pull Requests sind einfach zu verwenden, zu bearbeiten und zu verwalten, haben aber den Nachteil, dass Nutzer sich innerhalb der GitHub-Website befinden müssen, um Code-Reviews durchzuführen
- Für schnelle Änderungen ist das in Ordnung, aber sobald man beginnt, Code im Webbrowser zu lesen, gibt es erhebliche Nachteile. Ab einem gewissen Punkt ist es sinnvoller, Code in der lokalen Entwicklungsumgebung oder in einer IDE zu prüfen
- Es gibt zwar Tools und Plugins, mit denen sich PRs in der IDE prüfen lassen, aber sie nutzbar zu machen erfordert enormen Aufwand
- Außerdem benötigen selbst gehostete Lösungen, die Pull Requests nachbilden, viel Infrastruktur für ihren Betrieb: Datenbanken, eine mit Git verbundene Website, Admin-Verwaltung, Services usw.
- Ein weiterer großer Reibungspunkt ist, dass externe Nutzer zunächst ein Konto anlegen und sich anmelden müssen, bevor sie Code-Änderungen einreichen können. Das erhöht die Hürde erheblich – sowohl für externe Mitwirkende als auch für Code-Eigentümer, die die Infrastruktur bereitstellen müssen
- Häufig muss man ein Repository innerhalb des Code-Hostings forken, bevor man einen PR einreichen kann. Danach trägt man oft nie wieder etwas bei und behält das geforkte Repository für immer. Das wirkt absurd
Einführung in Patch Request (PR)
- Ziel ist es, einen selbst gehosteten Git-"Server" zu bauen, mit dem sich Patches senden und empfangen lassen, ohne den Aufwand der E-Mail-Einrichtung oder die durch das E-Mail-Protokoll auferlegten Einschränkungen
- Außerdem soll sich der zentrale Workflow um die lokale Entwicklungsumgebung drehen. GitHub unterstützt seinen Workflow, indem es die IDE in den Browser bringt, wir möchten diese Idee umdrehen und Code-Reviews innerhalb der lokalen Entwicklungsumgebung zu einem erstklassigen Bestandteil machen
- Es versteht sich als eine Zwischenform zwischen dem Pull-Request-Workflow von GitHub und dem Senden bzw. Empfangen von Patches per E-Mail
- Die Grundidee ist, eine SSH-App zu nutzen, um den Großteil der Interaktionen zwischen Mitwirkenden und Projekt-Eigentümern abzuwickeln. Alles soll ergonomisch und voll funktionsfähig im Terminal erledigt werden können
- Benachrichtigungen erfolgen per RSS, und jede Statusänderung führt zur Erzeugung statischer Web-Assets, sodass sich alles mit einem einfachen Datei-Webserver hosten lässt
Der format-patch-Workflow
- Das grundlegende Kollaborationstool ist hier
format-patch
- Ob man Code-Änderungen einreicht oder prüft – alles findet im Code statt
- Sowohl Mitwirkende als auch Eigentümer erstellen neue Commits und erzeugen Patches aufeinander aufbauend
- Dadurch braucht es keinen Web-Viewer, in dem Reviewer eine „Kommentar“-Zeile an einen Codeblock hängen können. Das ist nicht nötig. Man wendet einfach den Patch des Mitwirkenden an, schreibt Kommentare oder Code-Änderungen, erzeugt einen neuen Patch und sendet diesen als „Review“ an den Git-Server
- Dieser Ablauf funktioniert genauso, wenn zwei Nutzer gemeinsam an einer Reihe von Änderungen arbeiten
- Damit wird auch das Problem gelöst, mehrere Patch-Sets für dieselbe Code-Änderung zu verschicken. Es gibt einen einzigen zentralen Patch Request, in dem alle Änderungen und die gesamte Zusammenarbeit stattfinden
- Man könnte vielleicht einen Weg finden, Reviews/Kommentare mithilfe von git note zu nutzen, aber offen gesagt wirkt diese Lösung brutal und außerhalb des Komfortbereichs der meisten Git-Nutzer
- Man sendet Reviews einfach als Code und kommentiert den Code in der verwendeten Programmiersprache
- Diese Kommentare zu „bearbeiten“ und in nachfolgenden Patches zu entfernen, ist Aufgabe der Mitwirkenden
- Erzwingungsfunktion für die Bearbeitung aller Kommentare: Wenn es im Code noch unbearbeitete Kommentare gibt, wird der Patch nicht gemergt. Sie lassen sich nicht ignorieren, da sie sonst fälschlich upstream gelangen würden
So funktioniert Patch Request
- Patch Request (PR) ist der einfachste Weg, Änderungen an einem Git-Repository einzureichen, zu prüfen und anzunehmen. So funktioniert es:
- Externe Mitwirkende klonen das Repository (
git-clone)
- Externe Mitwirkende nehmen Code-Änderungen vor (
git-add & git-commit)
- Externe Mitwirkende erzeugen einen Patch (
git-format-patch)
- Externe Mitwirkende reichen den PR beim SSH-Server ein
- Eigentümer erhalten eine RSS-Benachrichtigung über den neuen PR
- Eigentümer wenden den Patch vom SSH-Server lokal an (
git-am)
- Eigentümer schreiben Vorschläge in den Code (
git-add & git-commit)
- Eigentümer leiten den Patch an den SSH-Server weiter und reichen so ein Review ein (
git-format-patch)
- Externe Mitwirkende erhalten eine RSS-Benachrichtigung über das PR-Review
- Externe Mitwirkende wenden den Patch erneut an (
git-am)
- Externe Mitwirkende prüfen und entfernen Kommentare im Code
- Externe Mitwirkende reichen einen weiteren Patch ein (
git-format-patch)
- Eigentümer wenden den Patch lokal an (
git-am)
- Eigentümer markieren den PR als genehmigt und pushen den Code nach
main (git-push)
1 Kommentare
Scheint eine neue Ergänzung zu Pico.sh – eine Open-Source-Sammlung, mit der sich Webservices vollständig über SSH verwalten lassen, zu sein.
Bisher sind unter anderem die folgenden Dinge enthalten.