Deine Entwicklungsumgebung

In der letzten Lektion hast du ein Terminal geöffnet und einen Befehl eingetippt. In der nächsten sollst du git init eingeben. Dazwischen fehlt eine Auskunft: Was muss auf deinem Rechner liegen, damit irgendetwas davon antwortet?

Die Antwort ist kein großes Programm, das du kaufst. Es sind vier kleine Teile — und der schnellste Weg hinein führt über eine andere Frage. Nicht »was lade ich herunter«, sondern »welche Frage beantwortet dieses Teil«.

Dein Agent benutzt dieselben vier Teile: Er läuft im Terminal oder im Editor und greift auf dieselbe Laufzeitumgebung und dasselbe git zu wie du. Deshalb ist das hier kein Hintergrundwissen, sondern das, womit du seine Arbeit prüfst.

Was hier nicht steht: eine Klick-für-Klick-Anleitung. Die sieht auf jedem System anders aus und ist in einem halben Jahr falsch. Sie steht auf den offiziellen Seiten unten.

Was eine Entwicklungsumgebung wirklich ist

Eine Entwicklungsumgebung ist kein Produkt. Sie ist die Summe aus vier Teilen: einem Ort zum Lesen, einem Ort zum Befehlen, etwas, das den Code ausführt, und einem Weg zurück zu einem Stand, der funktioniert hat. Keines davon enthält die anderen.

Daraus folgen zwei praktische Dinge: Du kannst in unter einer Minute feststellen, was dir fehlt — und du erkennst, was du dir nur eingeredet hast zu brauchen.

Vier Teile, vier Fragen

Den Editor stellst du dir schon vor: ein Fenster mit Text, eingefärbt und durchsuchbar. Er ist der Ort, an dem du liest und prüfst — und je weniger du selbst tippst, weil ein Agent einen Teil des Schreibens übernimmt, desto wichtiger wird diese Stelle.

Das Terminal kennst du aus der letzten Lektion. Neu ist hier nur eines: Es gehört zum Grundbestand, und installieren musst du keins. Jedes Betriebssystem bringt eins mit.

Bleibt das Teil, das die meisten übersehen, weil man es nie zu Gesicht bekommt. Ein Editor zeigt Text an, ein Terminal nimmt Befehle entgegen — ausführen tut keines von beiden irgendetwas.

Das gilt auch, wenn du selbst keine Zeile schreibst: Die Werkzeuge des Projekts brauchen die Laufzeitumgebung, bevor du irgendetwas eintippst. Ein großes Web-Framework verlangt in seiner Installationsanleitung eine Mindestversion davon, allein damit sich das Projekt starten lässt.

Ein Missverständnis lohnt sich früh loszuwerden: Der Paketmanager — das Programm, das fertige Code-Bausteine anderer Leute in dein Projekt holt — ist kein zweiter Download. Normalerweise kommt er mit der Laufzeitumgebung; auf manchen Systemen liefert ihn die Distribution getrennt aus. Welchen Installationsweg du nimmst, entscheidet nicht dieser Artikel, sondern die offizielle Installationsanleitung des Paketmanagers — sie rät aus Rechtegründen zu einem Versionsmanager.

Das vierte Teil ist git, der Weg zurück. Was git tut, ist Thema der nächsten Lektion; hier zählt, dass es ein eigenes Programm ist, das du separat installierst, und dass seine gesamte Pflicht-Einrichtung aus zwei Konfigurationszeilen besteht: Name und E-Mail, einmal pro Rechner.

Beispiel: Vier Fragen, vier Antworten

Dein Setup ist keine Stimmung, sondern vier Ja-oder-Nein-Antworten. Die folgenden Abfragen tippst du in irgendein Terminal — in das deines Systems oder in das im Editor, das ist ohnehin dasselbe.

Zwei Antworten sehen dabei gleich aus und bedeuten Verschiedenes. »Befehl nicht gefunden« heißt entweder: nicht installiert. Oder: installiert, aber die Kommandozeile findet es nicht. Den zweiten Fall kennt sogar die offizielle Anleitung einer großen Programmiersprache: Sie führt den Eintrag in den Suchpfad als eigenen, ausdrücklich optionalen Schritt.

Komfort, der wirklich zählt

Drei Bequemlichkeiten des Editors sind mehr als Kosmetik, und in einer steckt eine Falle.

Automatisches Speichern gibt es, aber ab Werk ist es aus. Einschalten kannst du es auf drei Arten: nach kurzer Verzögerung, beim Verlassen der Datei oder beim Verlassen des Fensters. Bis dahin sind »steht im Editor« und »steht auf der Platte« zwei verschiedene Aussagen; sobald git dazukommt, wird eine dritte daraus. Warum ein ungespeicherter Text nach einem Absturz weg ist, weißt du schon aus dem ersten Schritt dieses Lernpfads.

Die Diff-Ansicht legt alt und neu nebeneinander. Das ist die eine wirklich hilfreiche Bildschirmansicht, wenn ein Agent Dateien umgeschrieben hat, bei deren Entstehen du nicht zugesehen hast.

Und das eingebaute Terminal ist kein anderes Terminal: Jeder Befehl aus der Terminal-Lektion funktioniert dort unverändert.

Die Abkürzung: eine Umgebung mieten

Es gibt einen Weg, bei dem du nichts davon installierst: eine Cloud-Entwicklungsumgebung. Das ist ein Rechner, den jemand anderes bereithält, erreichbar in einem Browser-Tab, mit allen vier Teilen schon darauf.

Was sie dir abnimmt, ist die Installation. Mehr nicht. Die vier Teile sind weiterhin da, du bedienst sie nur auf einem fremden Rechner. Deshalb steht dieser Abschnitt hinter dem ersten und nicht davor.

Denk an eine Mietwerkstatt statt an den eigenen Keller. Du mietest Zeit und Platz an einer fremden Werkbank, die Uhr läuft, während du arbeitest, und ist die Zeit um, bist du draußen. Dein einziges Exemplar lässt du dort besser nicht liegen.

Beispiel: Die Rechnung hinter dem Gratis-Kontingent

Zwei Gratis-Tarife, zwei entgegengesetzte Formen. Der eine rechnet in Kern-Stunden, und das ist der ganze Punkt: Der Anbieter rechnet es auf seiner Produktseite selbst an einer Maschine mit zwei Kernen vor — dort bleibt vom Monatskontingent die Hälfte an echter Laufzeit. Bei doppelt so vielen Kernen halbiert sich das erneut.

Der zweite Tarif ist die Umkehrung: mehr Stunden pro Woche, weniger dauerhafter Speicher, eine harte Obergrenze pro Sitzung und eine Regel, die vergisst. Das ist keine Rangliste, sondern eine Wahl.

Die Zahl, die du dir merkst, ist gar keine Zahl, sondern ein Rechenweg: durch die Kernzahl teilen. Der gilt bei jedem Anbieter, auch bei denen, die es heute noch nicht gibt.

»In der Cloud brauche ich gar nichts« stimmt nicht ganz: Du brauchst einen Browser und ein Konto. Und der reine Browser-Editor aus der Vertiefung ist ausdrücklich keine Umgebung — ohne Terminal und Laufzeitumgebung kannst du lesen und ändern, aber nichts ausführen und nichts prüfen.

»Was in der Cloud liegt, bleibt dort« stimmt noch weniger. Der eine Anbieter löscht das Heimatverzeichnis nach der im Tarifkasten oben genannten Frist ohne Zugriff und schreibt dazu, dass die Dateien dann nicht wiederherstellbar sind. Der andere sperrt bei erschöpftem Kontingent — und nennt in derselben Dokumentation als Ausweg, die angefangene Arbeit in einen Branch zu exportieren.

Damit bricht die Analogie, und zwar zu deinen Gunsten: Aus einer Mietwerkstatt trägst du dein Werkstück nach Hause, hier wandert es in ein Repository, das jede neue Werkstatt wieder öffnen kann. Die Umgebung ist das Vergängliche, das Repository das Bleibende — und das liegt an einem dritten Ort, weder in der gemieteten Werkstatt noch in deiner Hand.

Was du NICHT brauchst

Dieser Abschnitt ist keine Meinung über Werkzeuge. Er ist eine Zählung.

Beispiel: Was die offiziellen Anleitungen wirklich verlangen

Nimm die Installationsseiten echter Projekte und schreib auf, was dort als Voraussetzung steht. Ein großes Web-Framework führt vier Punkte auf: eine Laufzeitumgebung in einer Mindestversion, einen Texteditor, ein Terminal — und als vierten ein Zusatzwerkzeug für den Editor, das es ausdrücklich nur empfiehlt. Verlangt sind also drei; der vierte Punkt ist ein Rat. Ein zweites Framework nennt unter »Systemvoraussetzungen« zwei. Das Handbuch von git verlangt zwei Konfigurationszeilen, einmal pro Rechner. Der Editor verlangt die Hardware aus dem Kasten oben.

Jetzt die zweite Zählung: Was steht in keiner dieser Listen? Eine Vollausstattung, ein grafisches git-Programm, eine Container-Laufzeit, ein Linux-Unterbau als Pflicht, ein neuer Rechner. Diese Liste ist länger als die erste, und alles darauf hat sich jemand selbst dazugekauft.

Die Packliste schreibt das Ziel, nicht der Laden. Was du mitnehmen musst, entscheidet, wohin du fährst — nicht, wie gut vorbereitet du dich fühlen möchtest. Genau deshalb verlangt die eine Seite drei Dinge und die andere zwei: Der Unterschied kommt von den Projekten, nicht von dir.

Die Grenze der Packliste: Sie nennt den Boden, nicht die Decke, und sie ist pro Ziel geschrieben. Der dokumentierte Fall dafür ist der Linux-Unterbau unter Windows. Der Hersteller empfiehlt ihn unter einer ausdrücklichen Bedingung — wenn du auf Linux-Server ausrollst oder Linux-Werkzeuge benutzt. Trifft beides nicht zu, ist er eine Möglichkeit und kein Initiationsritus.

»Ich brauche einen neuen Rechner« erledigt der Kasten oben: Die dort dokumentierte Untergrenze liegt weit unter dem, was heute in jedem Gerät steckt, das noch angeht.

»Ohne grafisches git-Programm verstehe ich git nicht« dreht die Sache um: Das Handbuch von git hält fest, dass solche Programme nichts können, was die Kommandozeile nicht kann. Die eine wirklich hilfreiche Ansicht hast du im Editor ohnehin schon.

Es gibt inzwischen eine eigene Kategorie von Editoren mit eingebautem Agenten. Für das Minimal-Setup brauchst du sie nicht: Irgendein Editor plus ein Terminal reicht.

Eine offene Abweichung

Dieselbe Dokumentation, der wir das »installier es, wenn du es brauchst« verdanken, rät Einsteigern auch, sich um Versionskontrolle vorerst nicht zu kümmern. Von diesem einen Punkt weichen wir ab, und wir sagen es lieber, als die Quelle stillschweigend zu kürzen: Ihr Rat gilt jemandem, der HTML von Hand tippt. Du arbeitest mit einem Agenten, der Dateien ändert, die du nicht gelesen hast.

Und jetzt?

Vier Fragen, vier Teile: Wo lese ich? Wie befehle ich? Was führt aus? Wie komme ich zurück? Drei davon hast du jetzt so weit beisammen, wie du sie für den Anfang brauchst.

Das vierte hat eine eigene Lektion verdient. Der Ausweg des Cloud-Anbieters von eben — bring deine Arbeit in einen Branch — hilft nur, wenn du weißt, was ein Branch ist.

Genau davon handelt der nächste Artikel.