Leitfaden zu Git-Bereichen

Ein Git-Repository in Flow ist ein echtes Repository (du klonst es und pushst mit dem git, das du schon benutzt), das in Flow lebt statt bei einem externen Dienst. Code, Tasks und Pull Requests liegen dort, wo auch deine Dateien liegen: dieselbe Anmeldung, dieselben Mitglieder und Berechtigungen, dieselbe Sicherheitskopie, dieselbe Instanz, in Europa oder in deinem Unternehmen.

Es ist für alle gedacht, die ihren Code nicht nach außen geben wollen (oder dürfen): Das Repository ist ein Bereich wie die anderen, mit seinen Mitgliedern und zwei Rollen (Editor pusht, Leser klont und liest), dazu die Administratoren, die alles dürfen. Die Repositories erscheinen im Abschnitt Repositories der Seitenleiste und belegen wie alles andere Platz im Kontingent des Tarifs.

Im Browser findest du fünf Tabs: Code, Commits, Tasks, Pull Requests und Zugang. Die ersten beiden sind zum Ansehen, die anderen zum Arbeiten: Die Teamarbeit (wer was macht, was in den Hauptbranch kommt) findet dort statt.

Klonen und Pushen laufen über HTTPS, mit eigens dafür gedachten Zugangsdaten:

• Benutzername = deine E-Mail-Adresse;
• Passwort = ein Git-Passwort, das du selbst im Tab Zugang des Repositorys erstellst („So verbindest du dich“, mit dem Klon-Befehl fertig zum Kopieren).

Das Passwort siehst du nur beim Erstellen: Kopiere es in den Anmeldedaten-Speicher von git (auf dem Mac osxkeychain, unter Windows Git Credential Manager), dann fragt git nicht mehr danach. Geht es verloren, lässt es sich nicht wiederherstellen: Du erstellst ein neues und widerrufst das alte. Deine Git-Passwörter siehst und widerrufst du unter Konto → Git; ein Passwort gilt für alle Repositories, auf die du Zugriff hast, und für nichts anderes: Es öffnet nicht die App und gilt nicht für die API.

Wer was darf, bestimmt die Rolle im Bereich: Editor pusht Branches und Tags wie auf jedem Remote, Leser nur Klonen und Fetch. Wer kein Mitglied ist, sieht das Repository gar nicht.

Der Tab Code zeigt den Dateibaum im gewählten Branch, und die Startseite des Repositorys öffnet das README im Stammverzeichnis, wie du es erwartest. Textdateien liest du dort; bei einer Binärdatei oder einer sehr großen Datei tut der Browser nicht so als ob: Er sagt dir, dass du klonen sollst.

Der Tab Commits ist die Historie des Branches: Jeder Commit öffnet sich mit seinem Diff. Aus dem Text von Tasks und Kommentaren führt ein SHA direkt zum Diff dieses Commits.

Der Browser ist zum Lesen und Entscheiden da: Geschrieben wird lokal, im eigenen Editor, und dann gepusht. Der einzige Schreibvorgang über das Web ist der, der dort stattfinden muss: das Mergen einer Pull Request.

In den Tasks spricht das Team miteinander: Bugs zum Beheben, Änderungen zum Anfragen, Dinge zum Erledigen, Diskussionen. Vier Arten (Bug, Änderungsantrag, To-do, Diskussion) und ansonsten dieselbe Form: Titel, Text in Markdown, Kommentare, Status offen/geschlossen.

Jeder Task hat eine Nummer: Wer #12 in einen Task, einen Kommentar oder eine Pull Request schreibt, erzeugt den Link; ein SHA eines Commits wird zum Link auf seinen Diff. Ein Task kann eine zuständige Person (aus den Mitgliedern), Labels und eine Priorität haben; die Filter oben in der Liste („Offen“, „Meine Tasks“, die Suche) helfen, den Überblick zu behalten, wenn es viele Tasks werden.

Was du noch nicht gelesen hast, fällt auf: Der Task mit Neuigkeiten steht fett, und der Tab zeigt den Zähler „ungelesen“. Die E-Mails folgen deiner Einstellung unter Konto → E-Mail-Benachrichtigungen → Tasks: Wer an einem Task beteiligt ist (Autor, zuständige Person, wer kommentiert hat), erhält Zuweisungen, Kommentare und Schließungen.

An einen Task lassen sich Dateien anhängen: Sie landen in einem Ordner „Task #n“ des Bereichs, und im Text bleibt der Verweis. Praktisch für Screenshots, Logs, Ausgangsdokumente: Sie liegen im Repository derer, die daran arbeiten, nicht in einem externen Chat.

Eine Pull Request schlägt vor, einen Branch in einen anderen zu mergen. Du öffnest sie, indem du die beiden Branches wählst (eine offene PR pro Branch gleichzeitig), und der Tab sagt dir sofort und live, wie es steht: „Merge ohne Konflikte: n Commits“, oder die Liste der Dateien mit Konflikten, die du lokal löst, und beim nächsten Push aktualisiert sich der Tab.

Darunter stehen die eingehenden Commits und der vollständige Diff. Kommentiert wird unten oder an der einzelnen Zeile des Diffs: Jede Zeile öffnet einen Thread mit Antworten und Erledigen, und Threads an Zeilen, die ein neuer Push geändert hat, gehen nicht verloren: Sie wandern ans Ende, mit ihrem Pfad und ihrer Zeilennummer.

Die Reviews geben das Urteil ab: Freigeben oder Änderungen erbitten (nie bei der eigenen PR). Es zählt das letzte Urteil jeder Person, und eine Freigabe gilt für die Version des Branches, für die sie erteilt wurde: Nach einem neuen Push ist sie als „zu einer früheren Version“ markiert und zählt nicht mehr.

Mergen im Web, mit der Wahl, wie die Commits hineinkommen:

• Merge-Commit: Die Historie bleibt, wie sie ist, mit einem Merge-Commit, signiert von der Person, die den Knopf drückt;
• Squash: alle Commits zu einem einzigen zusammengefasst, signiert von der Person, die die PR geöffnet hat;
• Rebase: die Commits der Reihe nach auf das Ziel gesetzt, ohne Merge-Commit.

Es gibt die Option „Branch danach löschen“, und wenn du stattdessen im Terminal mit git mergst, bemerkt die PR das von selbst und wird als „Mit git gemergt“ markiert.

Auf einen geschützten Branch pusht niemand direkt, auch nicht die Editoren: Wer es versucht, erhält vom Server eine Ablehnung mit der Begründung. In den Branch kommt man nur auf einem Weg: durch das Mergen einer Pull Request im Web.

Einen Branch schützt du im Tab Zugang (dafür braucht es einen Administrator), und für jeden Branch lässt sich eine Anzahl von Freigaben verlangen: Die PR lässt sich erst mergen, wenn genug Reviews freigegeben haben, und ein Review „Änderungen erbitten“ blockiert, bis es sich ändert. Der Administrator kann trotzdem mergen: Die Regel ordnet die Arbeit im Team, sie nimmt ihm nicht die Schlüssel.

So sagst du „auf main kommt man nur mit einer geprüften PR“ und lässt es vom Server durchsetzen statt von einer mündlichen Absprache.

Jeder Push wird sofort gesichert, im selben geschützten Speicher wie deine Dateien: redundante Kopien, laufende Prüfungen, automatische Wiederherstellung. Es gibt nichts einzurichten und nichts, woran du denken musst.

Die Seite des Repositorys zeigt dir, wann die letzte Kopie erstellt wurde („Sicherheitskopie aktuell (…)“), und wenn eine Kopie nicht geklappt hat, steht es dort.

Im Kontingent des Tarifs zählt das Repository so viel, wie es tatsächlich wiegt, mit der Deduplizierung, die auch für alles andere gilt: Ein normales Repository belegt wenig.

Das Git-Passwort öffnet noch eine weitere Tür: die API-Routen der Tasks und der Pull Requests (/api/repos/…/tasks und /api/repos/…/pulls). Mit einem authentifizierten curl (Benutzer deine E-Mail-Adresse, Passwort das Git-Passwort) lassen sich Tasks auflisten, eine PR lesen, Kommentare schreiben und Dateien anhängen an einen Task oder eine PR. Nur diese Routen: Für den Rest der API brauchst du ein echtes API-Token (mehr dazu auf der Seite Entwickler).

Das ist für alle gedacht, die ihren eigenen Ablauf automatisieren (Skripte, Entwicklungswerkzeuge, Agenten), ohne weitreichendere Zugangsdaten als nötig herauszugeben: Das Git-Passwort bleibt mit einem Klick unter Konto → Git widerrufbar, und sein Wirkungsbereich ist die Arbeit am Repository.