Im ersten Artikel dieser Reihe habe ich die „Denkweise“ von Git beschrieben. Heute geht es um die Befehlszeile – beziehungsweise darum, was die Arbeit damit so schwierig macht. Meiner Erfahrung nach existieren große Berührungsängste gegenüber dem Thema. Ich möchte in diesem Text ein bisschen beleuchten, wo die Ursachen für diese Ängste liegen.
Je nach Betriebssystem heißt das Programm für die Eingabe von Befehlen im Textmodus Terminal, Konsole oder Command Line.
Die Kommandozeile … ist ein Eingabebereich (interface) für die Steuerung einer Software, der typischerweise (aber nicht zwingend) im Textmodus abläuft.
sagt Wikipedia dazu. Dieser Textmodus hat es in sich.
Wie bedient man einen Computer?
Heutzutage sind wir es gewohnt, auf einer hübsch aufgemachten Oberfläche zu navigieren. Wir nutzen dazu den Finger beim Touch-Screen oder die Maus beim klassischen Desktop-Computer. Wir zeigen auf etwas, klicken und es passiert was. An diese Art der Interaktion sind wir mittlerweile seit Jahrzehnten gewöhnt und tun uns damit relativ leicht.
Dieser Artikel ist Teil einer Reihe.
Bisher sind erschienen/geplant:
1. Git für WordPress – Einstieg
2. Git für WordPress – Hilfe, Befehlszeile!
3. Git für WordPress – Die wichtigsten Git-Kommandos
4. Git für WordPress – Arbeiten mit Branches
5. Git für WordPress – Projekt auf GitHub
6. Git für WordPress – Versionen zusammenführen
6. Git für WordPress – Tools und Tipps
Aber es gab eine Zeit vor der grafischen Oberfläche. Ehe die Computer grafische Oberflächen zu bieten hatten, war die Befehlszeile der normale Weg, sich mit dem Computer zu unterhalten. Menschen, die das irgendwann mal gelernt haben, greifen auch heute noch gern darauf zurück. Sie sagen, es sei einfach schneller, als alles mögliche Zeug anklicken zu müssen und irgendwelche Menüs zu durchforsten.
Computer im Blindflug
Der große Vorteil der Befehlszeile ist die Geschwindigkeit. Es sind keine graphischen Oberflächen im Weg, die Ladezeit beanspruchen oder einfach nur ablenken. Wenn man weiß, wo man hinwill und die Syntax beherrscht, ist die Arbeit per Befehlszeile vom Tempo her ungeschlagen.
Der Nachteil: Es ist abstrakt. Es gibt keine optische Rückmeldung über das, was gerade passiert.
Wenn ich per Point & Click einen Prozess anstoße, bekomme ich immer irgendeinen Hinweis auf den Fortschritt meiner Aktion. Ein Verzeichnis öffnet sich (= ein neues Fenster geht auf) oder es erscheint eine animierte Sanduhr, die sagt: „Es dauert noch einen Moment hier“.
Wenn ich dagegen über die Befehlszeile einen Prozess anstoße, sehe ich erst Mal nichts. Wenn ich Glück habe, hat ein freundlicher Entwickler eine Botschaft eingebaut, die den Text „das kann jetzt ein paar Minuten dauern“ erscheinen lässt. Die Regel ist aber, dass einfach nichts passiert. Irgendwann ist die Befehlszeile wieder bereit und es kann weitergehen. Sonst hat sich nichts verändert.
Spätestens jetzt werden viele Anwender nervös. Was passiert denn da? Tut sich überhaupt was? Jetzt ist das Eingabe-Prompt wieder da, ist jetzt alles so, wie ich es haben wollte?
Ungewohnt und unheimlich
Auch viele erfahrene Computer-Nutzer verwenden die Befehlszeile nur, wenn sie unbedingt müssen. Sprich, wenn die Google-Suche zu irgendeinem Problem den Hinweis ausgespuckt hat, man müsse über Befehlszeile diesen oder jenen Code eingeben.
Was dabei genau passiert, bleibt unklar. So kann es sein, dass sie Benutzer-Rechte verändern, Editoren aufrufen und Dateien beschreiben, löschen oder ändern, ohne dass ihnen das bewusst ist.
„Welchen Editor hast Du denn benutzt?“ – „Editor? Nö, ich hab nur was ins Terminal eingegeben…“.
Zurück zum Thema Git
Git wurde, wie im ersten Artikel beschrieben, von Linus Torvalds entwickelt. Er brauchte für die Entwicklung von Linux eine leistungsfähige Software zur Versionskontrolle.
Menschen, die mit Linux arbeiten, sind Großmeister der Befehlszeile. Und sie schätzen ein Tool, das schlank und schnell ist. Außerdem müssen die wichtigsten Funktionen einfach zu steuern sein – direkt aus ihrem Arbeitsalltag (= Befehlszeile) heraus. Und genau das ist Git – schnell, supereinfach und trägt überhaupt nicht auf.
Ein bisschen wie Zauberei
Beim Arbeiten mit Git gebe ich einen Befehl ein, der lediglich aus zwei oder drei Wörtern besteht. Ich denke, das allein verwirrt die Menschen schon. Das soll den Stand meiner Arbeit sichern? Eine so komplexe Aufgabe wird mit nur einer Zeile im Terminal gelöst?
Noch dazu bekommt man ganz wenig Rückmeldung, man „sieht“ nicht, was man tut. Wobei ich allerdings bemerken muss, dass Git vorbildlich ist für ein Befehlszeilen-Tool. Es gibt mir eigentlich immer eine Rückmeldung darüber, was gerade passiert ist und wie ich das im Zweifelsfall wieder rückgängig machen kann.
Aber vermutlich kommt das bei dem Web-Designer nicht so richtig an, der wie das Kaninchen vor der Schlange vor dem Terminal-Programmfenster sitzt. Er fragt sich wahrscheinlich, ob jetzt wirklich das passiert ist, was er auslösen wollte oder ob er gerade was kaputt gemacht hat.
Fazit
Manche Leute schaffen es, sich an die Arbeit per Befehlszeile zu gewöhnen. Es packt sie die Neugier und sie entwickeln einen gewissen Entdeckerdrang. Manche Leute werden den leichten Grusel nie los, der sie beim Anblick der Befehlszeile überkommt. Sie steigen eher früher als später auf eines der grafischen Tools um, die es für die Arbeit mit Git gibt. Am Ende dieser Artikel-Serie werden wir ein paar davon vorstellen.
Für beide Fraktionen gilt: Um mit Git arbeiten zu können, muss man sich mit der Arbeitsweise von Git auseinandersetzen. Man muss verstehen, wie Git denkt und welche Wege es geht. Das schließt auch die Befehle ein, mit denen man das Tool per Befehlszeile steuert. Darum wird es im nächsten Artikel gehen.