Kennt das jemand? Man hat da ein Audio von mehreren Stunden und wenn man die Wiedergabe abbricht, muss man hinterher spulen?
Ich kenne das ganz gut. Im Moment experimentiere ich damit, meine Bücher zu Hörbüchern umzubauen. Jedoch nicht mit mir als Sprecher. So. Ich bekomme dann also eine Audio-Datei geschickt, die kann auch mal etwas länger sein. Da ich es aber doof finde, mich dann die ganze Zeit vor den PC zu setzen und dem zu lauschen, um eventuell Fehler zu finden, oder was mir sonst vielleicht nicht gefällt, höre ich das ganz gerne im Auto.
Hier ist nun mein billig Autoradio nicht gerade mein Freund. Das frisst zwar alles, also SD-Karte und USB-Stick, aber wenn da mal irgendwas schief läuft, springt das dumme Ding wieder an den Anfang zurück. Jetzt spul mal im Auto, während der Fahrt, wieder an die richtige Stelle. Das ist absolut ein Krampf!
Da wäre es doch viel schöner, wenn man, wie bei fertigen Hörbüchern ja üblich, die Datei in viele kleine Dateien unterteilt hätte. Dann könnte ich einfach springen und wenn ich zumindest in der Nähe von dem bin, wo ich zuletzt war, die Wiedergabe fortsetzen.
Der wahrscheinlich eleganteste Weg wäre es, die Datei mittels Audacity, oder ähnlichen Programmen von Hand zu schneiden. Würde dann in einer endgültigen Fassung auch so passieren. Aber nur um sich das alles mal anzuhören diesen Aufwand betreiben, um dann hinterher zu sagen, muss alles noch einmal eingelesen werden, weil da was falsch war, oder wie auch immer, nee. Das ist mir dann zu heftig.
Ich habe ein bisschen rum gesucht. Es gibt viele kleine Tools, die einem da das Blaue vom Himmel versprechen. Oft haben die dann eine tolle Oberfläche und so, aber sie tun dann einfach nicht das, was ich von ihnen will. Oder sie tun es und ich frage mich, warum ich es nicht gleich mit Audacity gemacht habe, denn die manuelle Nachbearbeitung frisst dann wieder viel Zeit.
So bin ich dann über das kleine Programm mp3splt gestolpert. Es ist wirklich nicht gross, hat auch keine GUI von Hause aus dabei, man kann sich aber trotzdem eine nachinstallieren, aber eine einzige Zeile im Terminal reicht aus, dass genau das passiert, was ich haben will. Die grosse Datei wird in viele Kleine aufgeteilt. Dabei achtet das Programm sogar darauf, dass möglichst eine stille Stelle zum schneiden benutzt wird. In der Praxis scheint das aber nicht immer ganz zu funktionieren. Man merkt also, wann die nächste Datei an der Reihe ist. Das ist aber auch nur halb störend, wenn man mich fragt. Ich kann damit gut leben!
Wie immer, wie man das installiert, schreibe ich hier jetzt nicht gross auf. Warum sollte mittlerweile klar sein. Aber, ich werde jetzt auch so etwas wie eine FAQ hier im Blog einbauen, wo ich die Antwort auf genau diese Frage geben werde.
Nach der Installation wechselt man einfach in das Verzeichnis, wo die grosse Datei drin liegt. Zumindest mache ich das so. Man kann sich natürlich auch in einem extra Zielordner befinden und dann anstatt dem Dateinamen auch den kompletten Pfad zur Quelldatei angeben. Ist also auch kein Problem.
Ich für meinen Teil verwende das Programm dann so:
mp3splt -a -f -t 3.0 -o "@f @n" <quelldatei>
Also, was macht das jetzt?
-a
Mit dieser Option versucht das Programm eine geeignete Stelle für den Schnitt zu finden, die möglichst still ist. Dabei erlaubt es sich, den angegebenen Intervall auch etwas zu verschieben. Wie schon erwähnt, es klappt nicht immer, ist aber auch eigentlich nicht so tragisch.
-f
Gerade MP3 Dateien haben so etwas an sich, was beim schneiden schon ein bisschen zu Problemen führen kann. Die Datei ist komprimiert! Rein theoretisch könnte es also sein, dass zu der angegeben Zeit gar nicht die angegebene Zeit erreicht, oder schon überschritten ist. Mit dieser Option durchsucht das Programm jetzt die Frames der Datei und ermittelt aus diesen Daten den richtigen Zeitpunkt. Damit die geschnittene Datei dann auch wirklich die Länge hat, die man haben will.
-t 3.0
Was diese Option macht, dürfte ja fast schon klar sein. Hier gibt man an, ab welcher Länge geschnitten werden soll. In meinem Fall also alle 3 Minuten und 0 Sekunden. Dadurch erklärt sich auch das Format: Minuten.Sekunden. Während meiner bisherigen Arbeit konnte ich dann auch feststellen, die geschnittenen Dateien haben wirklich fast immer genau diese länge. Nur fast wegen den Optionen -a und -f. Das ist dann aber logischerweise in Ordnung.
-o “@f @n”
Mit dieser Option kann man angeben, wie die geschnittenen Dateien heissen sollen. Es wäre ja doch schon bescheuert, wenn diese Dateien immer den gleichen Namen hätten und sich dann gegenseitig überschreiben. Da könnte man jetzt irgendeinen Namen eingeben. Dann hätte man aber eben das Problem, jede Datei hätte den selben Namen und würde die zuletzt geschriebene Datei wieder überschreiben. Hier kommt also das @n ins Spiel. Mit dem Platzhalter wird an den Namen auch eine fortlaufende Zahl mit Führungs-0 angehängt. Wenn man, wie in meinem Fall, keinen extra Namen für die Dateien vergeben will, benutzt man noch @f. Damit wird der Name der Quelldatei verwendet.
Für dieses Beispiel käme dann etwas heraus wie: “quelldatei 01.mp3”.
Noch die Quelldatei angeben und schon kann es losgehen. Das Programm ist auch ziemlich schnell, man muss also nicht ewig auf das Resultat warten.
Und das ist auch schon die ganze Magie hinter dem Teil. Klar, da kann man noch mehr damit machen und wem es gefällt, der hat in den Optionen noch einiges zum rumspielen. Für mich reicht es so und deshalb denke ich, es hier zu zeigen, kann ja nicht so falsch sein.
In letzter Zeit werde ich immer wieder eine Sache gefragt:
SSH ist ja ein tolles Ding, aber kann man nicht verhindern, dass alles abbricht, wenn man die Verbindung beendet?
Die Antwort ist einfach, auch wenn ich hier einen anderen Weg zeige, als in den E-Mails. Sie lautet ja!
Wobei, ssh selbst wird immer alles hinter sich abbrechen, wenn die Verbindung beendet wird. Das ist aber gar nicht schlimm, denn es gibt kleine Helfer, mit denen man das trotzdem regeln kann.
Bislang habe ich immer Screen für diesen Fall genannt. Nun dachte ich, stelle ich das Ding hier doch einmal vor. Da ich Screen aber eigentlich nur mit seinem minimalsten Können benutze dachte ich, da lese ich mich mal tiefer ein und gebe hier ein bisschen mehr Informationen.
Tja, da bin ich dann über Tmux gestolpert, habe es mir angeschaut und mir persönlich gefällt es besser. Das ist aber alles irgendwo Geschmacksache, aber ich habe mich jetzt dafür entschieden, hier Tmux vorzustellen.
Und so funktioniert es!
Zuerst muss Tmux installiert werden. Aber Achtung! Es muss dort installiert werden, wo es auch ausgeführt werden soll! Sprich, wenn ihr es auf einem Server betreiben wollt, dann muss es auf dem Server installiert werden!
Wie immer, ihr solltet wissen, wie man ein Programm bei eurer Distribution installiert. Unter Arch wäre es:
sudo pacman -S tmux
Tmux ist aber auch auf dem heimischen Rechner von Vorteil. Also ohne das man vorher mit ssh auf einen anderen Rechner muss. Dabei unterscheidet sich nur eine Sache! Auf einem entfernten Rechner muss man sich erst zum Beispiel mit ssh verbinden, auf dem lokalen Gerät natürlich nicht. Alles Andere ist gleich!
Man startet Tmux über einen Terminal. Irgendwie logisch. Dazu reicht es schon, wenn man
tmux
eingibt. Ja, es reicht, aber es hat seine Vorteile, wenn man der Session einen Namen gibt. Das geht dann so:
tmux new -s <name>
Warum das Sinn macht? Nun, wer sagt denn, dass man nur eine Session starten will? Vielleicht hat man ja mehrere laufen und wer ein wenig mit Tmux arbeitet, dem wird das wahrscheinlich auch passieren, denn Tmux eignet sich auch wunderschön, um etwas zu organisieren! Ihr werdet sehen!
Dann mal los!
tmux new -s tut
Ja schau an, so viel ist da ja gar nicht passiert, oder? Da unten ist so ein grüner Balken, aber was nun?
Ganz einfach. Tmux hat eine neue Session mit dem Namen tut gestartet und darin läuft, man glaubt es kaum, der bevorzugte Terminal! In meinem Fall eben Bash. Warum ich nicht zsh benutzte? Na ja, da hätten wir dann ein ganz anderes Thema!
Okay. Aber was bringt das jetzt? Ganz einfach. Alles, was da drin nun passiert, passiert auch weiterhin. Egal, ob man ssh, oder den lokalen Terminal einfach schliesst. Das zeug darin läuft weiter!
Um das zu verdeutlichen, starte ich htop, schliesse den Tab, öffne einen neuen und verbinde mich wieder mit der Session.
Das funktioniert immer, solange der entsprechende Rechner läuft. Bei einem Neustart hingegen wird auch Tmux und die Session beendet. Wer das aber auf einem Server einsetzt, dem sollte das wohl egal sein.
Das ist im Prinzip schon die ganze Magie hinter Tmux.
Doch es geht weiter!
Hier sei aber mal klar gesagt, ich gehe nicht auf die ganze Funktionsvielfalt und die ganzen Konfigurationsmöglichkeiten ein. Dann müsste ich das alles binden lassen und als Buch verkaufen. Ausserdem bin ich durchaus der Meinung, Learning by doing ist die beste Art, sich wirklich mit etwas vertraut zu machen. Hier will ich nur grundlegende Dinge erklären, die man im Hausgebrauch wohl am ehesten verwendet.
Ganz wichtig hierbei ist der Umgang mit Tmux. Der wird eigentlich gar nicht mit der Mouse gesteuert, sondern man benutzt dafür Kommandos, die man mit Tastenkombinationen eingibt.
Wer keine extra Konfiguration angelegt hat (wer es doch hat, braucht den Artikel wahrscheinlich auch gar nicht), der kommt mit der Standardkonfiguration daher und in dieser ist eines dominiertend.
Strg+b
Gibt man diese Kombination ein weiss Tmux, aha, da kommt jetzt ein Kommando.
Strg+b d
Zum Beispiel wird benutzt, um Tmux wieder zu verlassen. Dabei sei zu beachten, hier gibt es nur ein Einziges +! Das heisst, man drückt die Tasten nicht gleichzeitig!
Strg+b
d
Warum ich das so deutlich schreibe? Weil ich selbst bei meinen ersten Gehversuchen daran hängengeblieben bin und das Internet Abhilfe schaffen musste. Wie ich dabei gesehen habe, viele stellen diese Frage und das ist Grund genug, es auch zu erklären!
Tabs
Das kennt man aus den meisten Terminals und im Video hat man ja auch gesehen, dass ich Tabs verwendet habe. Tmux kann das auch.
Neuer Tab: Strg+b c
Vorher
Nachher
Hier haben wir also zwei Tabs. Tab 0 und Tab 1. Hinter Tab 1 ist dann noch ein * der anzeigt, in welchem Tab man sich gerade befindet.
Natürlich kann man auch zwischen den Tabs wechseln.
Vorheriger Tab: Strg+b p
Nächster Tab: Strg+b n
Man kann aber auch mit Strg+b <n> direkt in einen Tab springen. Dafür sind die Zahlen dann wieder gut!
Jetzt eine Ausnahmeerscheinung!
Tab schliessen: Strg+d
Ja genau, hier gibt man kein b ein!
Tab splitten
Etwas, was ich persönlich unglaublich praktisch finde, ist das splitten von Tabs. Dann hat man also mehrere Terminals in einem Tab und hat alles im Blick!
Als Beispiel nehme ich meinen Server daher. Da drauf laufen zwei verschiedene Minetest-Server. Ich habe meinen Tab in Tmux also horizontal gesplittet, links läuft der erste Server, Rechts der Zweite. So sehe ich auf einen Blick, ob irgendetwas nicht stimmt und muss nicht erst Tabs wechseln!
Tab horizontal splitten: Strg+b %
Tab vertikal splitten: Strg+b “
Zwischen gesplitteten Tabs wechseln: Strg+b <Pfeiltaste>
Dabei kann man auch geteilte Tabs weiter unterteilen. Das kann man ziemlich exzessiv treiben, aber irgendwann wird es unübersichtlich.
Man kann auch eine Reihe von vordefinierten Unterteilungen auswählen.
Strg+b Leertaste
und schon hat man verschieden gesplittete Tabs. Durch mehrmaliges drücken kann man diese durchschauen und nutzt dann den, der einem am Besten gefällt. Ich bin mir sicher, in den Einstellungen kann man das auch selbst definieren, habe ich aber nicht versucht.
Sonstiges
Wem das nun Lust gemacht hat, der kann mittels
Strg+b ?
sich eine Liste der verfügbaren Shortcuts anzeigen lassen. Da Scrollt man mit Bild hoch und Bild runter durch.
Zum guten Schluss gibt es auch noch die Kommandozeile mittels
Strg+b :
Auch damit kann man spielen. Einfach ausprobieren!
Fazit
Tmux ist eine ganz hervorragende Möglichkeit, auf dem lokalen Rechner, oder einem entfernten Server, Prozesse am Leben zu erhalten, auch wenn die Verbindung geschlossen wurde. Tmux ist einfach zu bedienen, wenn man die Geschichte mit den Shortcuts mal verstanden hat und die Fülle an Funktionen ist beeindruckend! Dazu noch die Möglichkeiten der Konfiguration, Spielkinder werden daran genauso ihren Spass haben wie diejenigen, die einfach nur auf einem entfernten System Prozesse am laufen halten wollen.
Git ist so eine kleine Wunderwaffe. Egal was man versionieren will, oder wenn man Backups erstellen möchte, oder ob man einfach mit mehreren Personen an etwas arbeiten will, Git ist einfach der Hammer! Klein, schnell, super funktionell und sehr einfach zu beherrschen!
Ich sage aber eines vorweg. Das hier wird nur eine kurze Schritt für Schritt Anleitung, wie man schnell und einfach mit Git arbeiten kann. Wer tiefer in die Materie eintauchen will, mit Erklärungen wie was funktioniert, dem empfehle ich dieses Werk. Da schlage ich auch immer wieder gerne nach!
Lassen wir mal die üblichen Beschreibungen weg und nennen das Kind beim Namen. Wenn man an einem Projekt arbeitet, welches verschiedene Versionen haben wird, denn bekommt man mit Git ein mächtiges Ding an die Hand.
Programmieren
Als Beispiel. Sagen wir mal, man entwickelt eine Software. Version 1.0 war toll, 1.1 hat auch gerockt, 1.2 konnte ebenfalls überzeugen, aber mit 1.3 hat man so richtig Mist gebaut. Da steckt auf einmal so viel Schrott drin, den man im Leben nicht mehr von Hand ausgebaut bekommt. Treibt man sein Programm dabei in seinem Arbeitsverzeichnis voran, bleibt man aber auf diesem Stand stehen. Entweder fängt man bei 0 an, versucht 1.3 dann doch irgendwie zu retten, oder macht sich dann echt die Mühe, alle Änderungen seit Version 1.2 von Hand rückgängig zu machen.
Hat man mit Git jedoch für seine Versionen eigene Branches angelegt, sieht die Welt mit einem Mal viel freundlicher aus. Version 1.3 ist also Murks und rückgängig machen ist auch nicht. Also geht man einfach in den Branch 1.2 und arbeitet damit weiter. Eine sehr bequeme Sache!
Auch forken, also ein eigentlich fremdes Projekt nach seinen Wünschen anpassen, geht damit hervorragend. Man clont sich einfach den Code, legt einen neuen Branch an und los geht es. Ohne das Original zu verändern!
Backup / Cloud
Praktisch ist es aber auch, wenn man von bestimmten Dingen ein Backup erstellen möchte. Da sind Branches eher überflüssig, kann man aber definitiv auch verwenden.
Hat man seine Arbeit bis an den angestrebten Punkt voran getrieben, oder ist Backup-Tag, pusht man seine Arbeitskopie einfach auf den Server, oder wo auch immer man seine Gits liegen hat.
Das funktioniert auch beinahe wie eine Cloud. Sagen wir, normalerweise arbeitet man von seinem Desktop zuhause aus, pusht seine Änderungen nach getaner Arbeit und ist auf einmal irgendwo im Nirgendwo und hat Langeweile. Gut, da ist es dann natürlich praktisch, einen Laptop dabei zu haben.
Man clont sich einfach das Repository auf das Gerät, arbeitet, pusht anschliessend und pullt es zuhause wieder auf den Desktop. Einfach und bequem.
Gemeinsames Arbeiten
Viele werden das in Zusammenhang mit Git schon gehört haben. Da sich das jedoch eigentlich immer auf das programmieren bezieht, will ich mal ein anderes Beispiel hernehmen.
Sagen wir, da sind zwei Autoren, die am gleichen Buch arbeiten. Der Eine legt immer eine Szenerie in fünf Seiten grob vor, der Zweite arbeitet diese in den nächsten fünf Seiten weiter aus.
Autor 1 clont sich das Repository, schreibt seine fünf Seiten und pusht die im Anschluss zurück. Dann kommt Autor 2, pullt sich das Repository, schreibt wiederum seine fünf Seiten und pusht diese.
Am Ende ist das Buch fertig und vielleicht sitzen die Beiden dabei ewig viele Kilometer auseinander.
Installation
Zu installieren gibt es nicht viel. Man braucht eben Git. Oftmals ist das schon installiert, weil wirklich viele es einsetzen, aber falls nicht, muss man es eben doch hinzufügen.
sudo pacman -S git
So sieht das bei Arch aus. Ich denke aber, wer sich schon an Git heranwagt, der weiss auch, wie man es installiert.
Versuchsaufbau
Man muss seine Repositorys nicht auf entfernten Rechnern auslagern. Das geht selbst verständlich auch lokal. Da ich aber davon ausgehe, dass die Meisten dann doch irgendwie gerne ihr Krempel extern auslagern, so können auch andere Beteiligen besser dran arbeiten, gehe ich auf eben diese Variante ein.
Wer es lokal machen will, der kann einfach den ssh Krempel weglassen.
Okay. Ziel der Übung wird es also sein, ein Repository auf meinem Raspberry anzulegen, es auf meinen Desktop zu klonen, etwas drin zu arbeiten und alles wieder auf den Raspberry zu schicken. Im Anschluss zeige ich dann noch das mit den Branches.
Da ich davon ausgehe, dass Nutzer, die nicht programmieren, es schwieriger haben werden, Programmcode zu verstehen, nehme ich einfach mal ein Beispiel, was nichts mit programmieren zu tun hat. Deshalb sage ich, wir wollen ein kleines Notizheft anlegen. Einfacher Klartext.
Vorbereitung
Git bietet eine ziemlich grosse Fülle an Einstellmöglichkeiten. So kann man beispielsweise auch einen bevorzugten Editor zum commiten angeben und ähnliches.
Wir wollen uns aber im Moment nur mit den wirklich notwendigen Dingen befassen.
Wer hätte es geahnt, wenn man mit verschiedenen Benutzern an einem Projekt arbeitet, würde man unter Umständen gerne wissen, wer wann welche Änderung vorgenommen hat. Da Git kein Hellseher ist, muss man ihm diese Informationen auch mitteilen.
Peng. Das reicht schon. Einfach in den Terminal tippen, fertig. Natürlich sollte man anstatt “John Doe” und johndoe@example.com mit seinen eigenen Daten verwenden. Ja, hier kann man auch irgendwas eintragen. Wichtig ist eben, dass user.name und user.email in der Konfiguration vorhanden ist.
Da ich euch die Möglichkeit noch zeigen möchte, wie man commits mit einem Editor durchführt, sollten wir dieser Einstellung auch noch treffen.
git config --global core.editor nano
Ich wähle deshalb nano, da der normalerweise eh installiert ist und sehr einfach bedient werden kann.
Zudem sollte man noch das Verhalten beim pullen einstellen. Sprich, was passieren soll, wenn etwas aus dem Repository entnommen wird.
git config --global pull.rebase false
Fertig!
Ein Repository anlegen
Es macht natürlich Sinn, dass Repository direkt dort anzulegen, von wo man es hinterher clonen will. Zumindest mache ich das immer so. Auch macht es Sinn, einen eigenen Ordner für die Repositorys anzulegen. Muss man nicht, dient aber der Übersichtlichkeit.
Ich für meinen Teil habe dafür einen Ordner mit dem bezeichnenden Ordner git. Ja, ich bin schon sehr einfallsreich. Der liegt in meinem Home-Verzeichnis auf dem Raspberr und wartet auf seinen Einsatz. Da gehe ich jetzt rein.
Also. Da soll jetzt das Repository notizen angelegt werden.
Erster Schritt, hinsetzen! Ja, ja, irgendwann wird das Geheimnis hinter diesem Schritt gelöst.
Als Nächstes wird ein neues Verzeichnis angelegt, was sinnvoller Weise den Namen des Repositorys haben sollte.
mkdir notizen
Wer hier jetzt dankbar ist, dass ich diesen Schritt beschrieben habe, der sollte sich vielleicht zuerst einmal doch näher mit Linux beschäftigen.
Gut. In das Verzeichnis gehen wir nun rein und dort heisst es dann
git init
Die Hinweise sind tatsächlich nur Hinweise. Wir ignorieren die jetzt einfach. Wer sich damit näher beschäftigen will, siehe meinen Link am Anfang des Artikels.
Leeres Git-Repository in /home/diabolus/git/notizen/.git/ initialisiert
Warum erzählt der denn jetzt sowas? Ganz einfach. Man ist nicht darauf beschränkt, ein neues Repository in einem leeren Verzeichnis zu erstellen. Wer schon ein Arbeitsverzeichnis hat, was er nun gerne über Git verwalten würde, der kann auch direkt darin auf dem gleichen Weg ein Repository erstellen.
Seit ich jedoch mit Git arbeite, ist der erste Schritt bei allen Projekten immer das erstellen des Repositorys und, oh wunder, da ist das Verzeichnis dann eben leer.
Damit sind wir aber noch nicht ganz fertig, denn ein ganzes, reales Verzeichnis clont sich in meinen Augen ziemlich schlecht. Man sieht ja auch zum Beispiel auf Github, alles was man clont, ist eine Datei mit der Endung .git. Genau eine solche wollen wir auch!
Also wieder raus aus dem Verzeichnis und dann:
git clone --bare notizen
warning: Sie scheinen ein leeres Repository geklont zu haben.
Warum diese Meldung als Warnung gekennzeichnet ist, erschliesst sich mir nicht wirklich. Ich habe noch nie einen negativen Effekt gefunden, der auf ein leeres Repository zurückzuführen gewesen wäre. Einzig kann ich mir vorstellen, dass die Warnung ein Hinweis sein soll, um eventuell auf ein falsch angegebenes Verzeichnis hinzuweisen.
Schau an, da haben wir ja die Datei notizen.git, die wir nun ganz bequem clonen können.
Ich für meinen Teil lösche im Anschluss immer das Verzeichnis. Ist ja ohnehin leer und darin wird auch nicht mehr viel passieren. Wer jedoch ein bereits gefülltes Verzeichnis benutzt hat, will diesen Schritt wahrscheinlich gerne überspringen. Ist kein Problem! Einfach Verzeichnis bestehen lassen und gut ist.
Das Repository clonen
Da gibt es sehr viele Wege. Der Einfachste, für den man nicht noch gross was installieren und einrichten muss, ist ssh. Ich persönlich arbeite an meinen Projekten alleine, deshalb reicht es, wenn ich meinen Benutzer dafür verwende. Wer jedoch in einem Team arbeiten will, der sollte einen eigenen Benutzer für Git anlegen, dessen Zugangsdaten auch die Teammitglieder bekommen.
Wie man nun aber einen Benutzer anlegt, die Rechte vergibt und das alles, soll hier nicht Bestandteil das Artikels sein. Dafür gibt es schon X-Anleitungen im Netz und eigentlich hat jedes Linux irgendwo in seiner Anleitung diesen Schritt ebenfalls gut beschrieben drin.
Für diesen Artikel reicht es aber auch, wenn man mit seinem Benutzer den fernen Computer erreichen kann.
Auf dem Arbeitscomputer, in dem Verzeichnis seiner Wahl, kann man nun das Repository clonen. Dabei wird automatisch das entsprechende Verzeichnis angelegt! Würde man nun ein Verzeichnis notizen erstellen und dort drin das clonen durchführen, hätte man wieder ein Verzeichnis namens notizen. Ist also unsinnig.
Das hat ja hervorragend funktioniert! Natürlich wird man gebeten, dass Passwort einzugeben. Wäre ja auch zu schön, wenn da einfach jeder mal was clonen könnte.
Wer kein Passwort eingeben will, der kann hier auch Schlüssel generieren und die öffentlichen Schlüssel den jeweiligen Systemen bekannt machen. Darauf gehe ich hier aber nicht ein.
Im Repository arbeiten
Ja, wie arbeitet man nun damit? Ganz einfach! Genau so, wie man sonst auch arbeiten würde. Git ist es herzlich egal, mit welcher Software man hier was erstellt. Das spielt überhaupt keine Rolle.
Für unser Notizbuch reicht ein einfacher Editor. Egal ob grafisch, oder im Terminal. Spielt keine Rolle. Wichtig ist jedoch logischerweise, die Dateien müssen auch im Verzeichnis notizen liegen! Ich verwende einfach Nano und lege nun die Datei notiz.txt an.
nano notiz.txt
Da schreibe ich jetzt etwas rein.
Das ist also der kleine Text, den ich in die Notiz geschrieben habe. Eben eine ganz einfache Text-Datei. Juckt Git alles nicht. Das frisst, was man ihm vorwirft.
Nun war das genug Notizen für heute. Ich will das so jetzt auch auf dem Server haben.
Das muss man Git dann auch sagen! Denn derzeit hat Git noch überhaupt keine Ahnung, was es mit dem komischen Text auf sich hat. Auf welchem Stand Git gerade ist, kann man so abfragen:
git status
Aha. Git hat also festgestellt, dass sich im Verzeichnis etwas geändert hat. Aber wir sind hier der Meister und nicht Git! Von daher übernimmt Git nicht automatisch alles, was man ihm so vorwirft. Wir müssen ihm sagen, was mit den Dateien, die Git bislang nicht kennt, oder die verändert wurden, passieren soll.
git add *
Damit sagen wir Git, dass es alle Dateien übernehmen soll.
Ist das nicht nett von Git? Es sagt dazu einfach gar nichts. Hat es denn nun getan, was man von ihm verlangt hat? Fragen wir doch einfach wieder den Status ab.
Ausgezeichnet! Es gibt also Änderungen im Verzeichnis, die Git verwalten soll. Aber, wie ich ja gerade geschrieben hat, es hat sich etwas verändert! Um die Änderungen jetzt aber offiziell an Git zu übergeben, also zu commiten, müssen wir noch etwas tun. Eben es commiten! Dabei sollte man dann gleich noch eine gute Beschreibung hinzufügen, um es später besser nachvollziehen zu können.
git commit -m "Erster Eintrag in der Datei notiz.txt"
Ausgezeichnet! Damit sind wir mit der Arbeit auch schon fertig!
Das Repository veröffentlichen
Tatsächlich hat sich aber alles auf dem lokalen Computer abgespielt. Würde ein anderer Benutzer jetzt das Repository clonen, wäre von den Änderungen noch nichts zu sehen!
Das ist jedoch kein Bug, sondern ein Feature! Sagen wir, ein Autor ist mit seiner Arbeit noch nicht fertig, hat an dem Tag aber keine Lust mehr, noch etwas zu schreiben. Dann führt der seine Arbeit am nächsten Tag fort. Dennoch kann er die bisherigen Änderungen commiten. Vielleicht, um irgendwann einmal darauf zurückkommen zu können. Oder ein Programmierer hat die eigentliche Programmierung abgeschlossen, will aber alles erst einen Tag später noch sorgfältig testen, wenn er frisch und ausgeruht ist. Deshalb ist das veröffentlichen des Repository absichtlich eine manuelle Geschichte.
Das veröffentlichen ist aber sehr einfach. Wobei das Wort veröffentlichen hier vielleicht zu Missverständnissen führt. Natürlich veröffentlicht man seine Arbeit nicht sofort. Man aktualisiert quasi nur das Repository auf dem Server. Deshalb heisst es auch eigentlich push und nicht veröffentlichen.
git push
Magie, oder? Da ist es wirklich von Vorteil, dass wir alle in unserer Kindheit Raketenwissenschaft und Astronavigation studiert haben!
Im Team arbeiten
So. Da ist dann jetzt aber noch einer im Boot, der ebenfalls gerne mit dem Notizbuch arbeiten will. Ich simuliere das einfach mit meinem NetBook genannt Mini-Horst.
Was man dabei zuerst tut, sollte klar sein. Man setzt sich hin! Danach clont sich Mini-Horst das Repository, wie oben beschrieben. Er möchte eigene Notizen anlegen, aber liest auch die Notiz von Horst, sprich meinem Desktop. Da Mini-Horst ein gar lustiges Kerlchen ist, will er da einen Kommentar hinzufügen und editiert einfach mit dem Editor seiner Wahl die Datei notiz.txt.
Ach, er ist so nett, der Mini-Horst.
Gut. Nun will Mini-Horst aber eine weitere Notiz für sich erstellen und erstellt dafür die Datei notiz2.txt.
Ja! Cola ist wichtig!
Was sagt denn aber Git nun, wenn man den Status abfragt?
Genau! Git erkennt, dass die Datei notiz.txt geändert wurde und da noch eine neue Datei vorhanden ist, die es noch gar nicht kennt. Auch Mini-Horst muss seine Änderungen also adden, commiten und dann pushen.
Nun kommt wieder Horst, als mein Desktop. Vor der Arbeit will er checken, ob sich im Repository etwas getan hat. Das geht dann ganz einfach mit:
git pull
Also push (schieben), um etwas ins Repository zu bringen und pull (ziehen), um es zu aktualisieren.
Ach schau an, da ist ja was neues drin!
Git erkennt, wenn sich nichts geändert hat und meldet dann:
Bereits aktuell!
Horst würde nun gerne wissen, was sich da geändert hat. Okay, bei zwei einfachen Textdateien kann man sich das noch schnell mal anschauen, bei grösseren Projekten kann das aber schnell unübersichtlich werden.
Aber war da nicht was mit commit? Musste man da nicht vor dem pushen was eingeben? Dann könnte man doch da mal nachschauen, was so passiert ist!
Richtung! Deshalb sollte man beim commiten auch wirklich hinschreiben, was man geändert hat. Das erhöht die Nachvollziehbarkeit.
Und wie macht man das jetzt? So:
git log
Na ist das nicht schön? Alle wichtigen Informationen sind da. Wer hat da was geändert, wann und was. Letzteres zumindest dann, wenn das jeweilige Team-Mitglied seinen Job auch ernst nimmt.
Aha. Der hat also die Notiz kommentiert. Schauen wir uns das doch einfach mal an!
Was ein Klugscheisser! Aber, was hat er denn da notiert?
Oh Cola! Muss ich gleich mal in der Garage schauen, ob ich noch genug habe!
Ich denke mal, damit sollte das arbeiten in einem Team mit git verständlich sein.
Arbeiten mit Branches
Gut. Die Beiden arbeiten also mit den Notizen und finden das ganz toll. Was aber, wenn da jetzt eine neue Notiz auftaucht, die Horst für Mini-Horst hinterlegt hat? Klar, Horst hat das natürlich brav beschrieben und Mini-Horst sieht im Log, dass eine Notiz extra für ihn erstellt wurde.
Nun kommt Mini-Horst aber auf eine Idee! Er will das Format der Notiz etwas ändern, damit aus dem Inhalt schon ersichtlich ist, um was es eigentlich geht.
Er könnte jetzt einfach eine neue Notiz erstellen, wo er das neue Format einfügt. Das würde er dann pushen und Horst bitten, sich das anzuschauen. Oder er editiert direkt die Notiz von Horst. Wäre auch möglich.
Beides hat aber eine Nachteil. In beidem Fall wird das eigentliche Projekt “zugemüllt”. Entweder erscheint da eine neue Notiz, oder Horst hat etwas in seiner Notiz stehen und findet das gar nicht gut. Wäre doch schön, wenn man Änderungen vornehmen könnte, ohne dabei das Original zu verkratzen!
Hier kommen Branches ins Spiel. Also Zweige, die vom Baum abgehen. Mini-Horst erstellt also zuerst mal einen neuen Branch mit dem Namen format.
git branch format
Mit:
git branch
kann man sich alle Branches anzeigen lassen. Jenes mit dem * ist das, in welchem man sich gerade befindet. Mini-Horst will nun in den neuen Branch wechseln.
git checkout format
Er ist also jetzt in einem neuen Zweig des Projektes. Mal schauen, ob sich im Ordner was verändert hat.
Nö. Alles so, wie man es erwarten würde!
Mini-Horst editiert jetzt die Datei notiz3.txt und baut dort seinen Vorschlag für ein neues Format ein.
So gefällt ihm das. Das muss nun kommentiert und gepusht werden.
Hier geht das pushen jedoch ein wenig anders. Der Grund dafür ist simpel. Nur weil man da an etwas herumspielt, muss das ja nicht gleich für jeden relevant, oder interessant sein. Unter Umständen tut man da etwas, nur um was herauszufinden, etwas zu versuchen usw. Deshalb muss man einen Branch auch extra pullen.
git pull origin format
Nun kommt Horst daher, pullt alles und schreibt schnell was in die Datei notiz.txt, ohne sich um die Änderungen im Repository zu kümmern. Was heisst er kümmert sich nicht um die Änderungen? Er bekommt ja gar keine angezeigt! Das heisst, er bekommt trotz pull nichts von dem neuen Branch mit.
Das merkt dann auch Mini-Horst und will Horst trotzdem mitteilen, dass es da eine Änderung gibt. Also schreibt er es in die Datei notiz4.txt. Aber wieder unter dem Branch master, nicht unter format. Commiten, pushen und abwarten.
Horst pullt wieder und ihm fallen Änderungen auf. Er schaut in die Logs.
Hier fällt nun etwas auf. Die Ausgabe ist länger, als der Terminal hoch ist. Deshalb erscheinen unten die Doppelpunkte. Drückt man Enter, geht es nach unten weiter. Das kennt man aber wahrscheinlich schon und drückt deshalb einfach q.
Aha. Mini-Horst hat also einen Formatforschlag gemacht im Branch format. Schauen wir uns das doch einmal an.
Öhm. Es gibt aber gar keinen Branch namens format. Dann muss Horst den wohl manuell abholen.
git fetch origin format
Das hat ja geklappt. Dann muss der Branch ja jetzt da sein.
Mysteriös. Er ist nicht da! Was passiert denn aber, wenn man einfach in den Branch wechselt? Angeblich ist er ja heruntergeladen worden.
Ach ne. Da ist er ja! Ausserdem hat Git uns auch gleich in den Branch gewechselt. Interessant! Dann schauen wir doch mal, was Mini-Horst da vorgeschlagen hat!
Ah! Von, An, ja, sieht übersichtlicher aus. Machen wir so! Aber, ist das jetzt schon direkt so auch in der Datei notiz3.txt in master?
Nein! Das heisst, hätte Mini-Horst jetzt da irgendeinen unsinnigen Schwachsinn eingebaut, hätte man den Branch einfach löschen können und nichts weiter wäre passiert.
Aber gut. Was Mini-Horst da gemacht hat, was gut und ist sinnvoll. Aber muss Horst das jetzt in der Datei notiz3.txt so abtippen? Natürlich nicht!
Man kann ganz einfach die Änderungen übernehmen. Dazu muss man sich im Branch master befinden.
git merge format
Ach da schau her! Automatisch wird der eingangs ausgewählte Editor gestartet und man wird aufgefordert, den Grund für das Zusammenführen (merge) zu beschreiben. Prima, macht Horst doch gerne!
Nachdem die Beschreibung gespeichert wurde und der Editor wieder zu ist, werden die Änderungen übernommen. Aber Vertrauen ist gut, Kontrolle ist besser. Also schauen wir zuerst, ob wir im Branch master sind und ob die Datei notiz3.txt nun auch wirklich die Änderungen übernommen hat.
Jawohl, hat hervorragend funktioniert! Das kann man jetzt pushen und fertig.
Anmerkung:
Ich arbeite noch nicht so lange mit Branches. Es liegt deshalb im Bereich des Möglichen, dass man damit auch einfacher arbeiten kann. Sollte ich dafür einen Weg finden, dann werde ich das hier aktualisieren.
Falls mich dabei aber jemand unterstützen kann, eine Mail würde mich freuen.
Zum Schluss
Git kann einem die Arbeit wirklich erleichtern. Es macht genau das was es soll und man muss sich an keine Restriktionen halten. Ich habe mir schon Videos zu anderen Versionierungssysteme angeschaut und hab mich jedes Mal gefragt, warum man das einsetzen sollte. Da werden unter Umständen die Arbeitsweisen vorgegeben, jeder Branch ist gleich ein komplettes Verzeichnis mit allen Dateien, was bei grossen Projekten Zeit und Speicherplatz kostet, oder man bekommt direkt eine komplette Umgebung vorgesetzt, wo man nur mit den jeweiligen, vorgeschriebenen Tools arbeiten kann.
Git macht nichts davon. Eigentlich merkt man gar nicht, dass Git da ist, solange man nicht pullt, pusht, oder commitet. Das ist auch gut so. Es tritt nur dann in Erscheinung, wenn man es braucht und wenn man selbst entschieden hat, dass man es nun einsetzen will.
Ein kleiner Nachtrag zu Guake zum Thema Autostart.
Auch wenn ich es im Artikel Terminals wie in Quake etwas anderes behauptet habe, will Guake mit der Methode über ste Startprogramme in Cinnamon nur ein einziges Mal nach einem Neustart freiwillig mitstarten. Beim nächsten Reboot ist es verschwunden.
Dem wollte ich entgegenwirken, indem ich es händisch zum Autostart überreden wollte.
Das brachte auch den gewünschten Effekt. Jedoch wieder nur ein einziges Mal.
Die Lösung war dann schliesslich noch einfacher!
Man geht in die Einstellungen von Guake, nachdem man es einmal über den Terminal, oder auf eine andere Weise von Hand gestartet hat, indem man mit Rechtsklick auf das Symbol geht und dort Einstellungen auswählt.
Wie im Bild zu sehen, gibt es dort die Option Guake bei Anmeldung starten. Wählt man diese Option aus, startet Guake brav bei jedem Neustart mit. So wie es sein soll.
Was aber etwas nervig ist, bei jedem Start von Guake wird die Benachrichtigung eingeblendet, dass man es mit einem bestimmten Hotkey aufrufen kann. Das hat mir nicht gefallen. Guake bietet jedoch in den Einstellungen auch hierfür eine Option an.
Man muss nur den Haken bei Popup-Benachrichtigung beim Start einschalten und schon wird man von dem Popup nicht mehr genervt.
Korrekt müsste ich natürlich sagen, es geht um Terminal-Emulatoren, die an Quake angelehnt sind. Ich verwende, auch wenn es im Prinzip ja falsch ist, einfach nur die Bezeichnung Terminal. So als kleiner Hinweis.
Worum geht es also? Nun, in Quake drückt man ein Hotkey und ein Terminal öffnet sich. Das kenne ich zwar auch aus anderen Spielen, doch hier scheint es seinen Ursprung genommen zu haben. Dieses Prinzip gefällt mir tatsächlich wirklich gut und ich habe über die Jahre auch immer wieder solche Terminals ausprobiert, die mir aber schlussendlich nie wirklich zugesagt haben!
Nun habe ich im Artikel HefftorLinux jedoch Plasma als WindowManager eingesetzt und dort Yakuake entdeckt. Das hat mir direkt gefallen und mittlerweile läuft es auch auf meinem Desktop. Es basiert auf KDE, weshalb man für die Installation auch einiges dieses Desktop Enviroment installieren muss. Aber, was tut man nicht so alles?
Ein Artikel nur über Yakuake schreiben wäre dann ein bisschen dürftig gewesen. Die Installation ist simpel, genauso wie der Start und viel einstellen kann man da eigentlich auch nicht. Doch schon, aber da muss ich eigentlich nicht viel erklären. Das wäre also doch etwas knapp. Ich habe mich deshalb entschieden, auf meinem Arch in Qemu, welches ich damals für den Artikel Arch-Linux installieren installiert habe (aufgesetzt sage ich tatsächlich nicht gerne!), mal Yakuake und Guake zu installieren und auszuprobieren.
Noch als Hinweis, ich verwende dafür pacman, also keinen grafischen Paketmanager.
Yakuake
Man könnte meinen, der Name kommt irgendwie aus dem asiatischen Raum, doch nein. Er bedeutet tatsächlich Yet another Kuake. Zu gut deutsch, Noch ein anderer Kuake. Das sagt tatsächlich schon einiges aus, denn es handelt sich einfach um noch eine Variante von Kuake und das sagt wieder aus, alleine für KDE muss es da mehrere geben. Das K deutet daraufhin, denn eigentlich müsste es ja Quake heissen! Anders verhält es sich, wenn der Terminal auf GTK+ beruht. Dann heisst er zum Beispiel Guake, als mit G anstatt Q.
Aber gut, genug mit dem Namen. Bauen wir das Ding!
Installation
Das geht erschreckend einfach:
sudo pacman -S yakuake
Noch das Passwort eingeben und dann kann es auch schon losgehen!
154 MB für einen Terminal? Ist heftig, korrekt. Aber! Hier darf man nicht vergessen, wenn man nicht Plasma, oder ähnliches installiert hat, müssen die Komponenten, die man für Yakuake braucht, mitinstalliert werden. Also, los gehts!
Die Installation dauert nicht lange und verlief bei mir bislang immer reibungslos.
Autostart einrichten
Gut. Natürlich will man Yakuake nicht immer von Hand starten. Das soll mal schön beim starten mit gestartet werden. Natürlich könnte man da jetzt für Systemd etwas basteln, aber warum? So ziemlich jeder Desktop bringt irgendeine Möglichkeit mit, Autostart-Programme zu definieren. So auch Cinnamon. Dort trägt man Yakuake einfach ein.
Unter Cinnamon findet man diese Möglichkeit unter dem Begriff Startprogramme. So sieht das vorher aus:
Dann unten auf das kleine +, dann auf Anwendung auswählen und dort Yakuake suchen.
Fertig. Nun sollte Yakuake beim nächsten Hochfahren automatisch mitstarten. Schauen wir doch mal.
Ausgezeichnet! Hat hervorragend geklappt. Nun muss man noch auswählen, mit welcher Taste der Terminal aufgerufen, oder wieder eingerollt werden soll und fertig. Man sieht auch unten das kleine Symbol in der Leiste, über welches man den Terminal ebenfalls öffnen und schliessen kann.
Ich persönlich verwende ungerne die Taste F12. Die wird oft in Spielen zum anlegen von Screenshots verwendet und in Blender ist sie für den Renderer belegt. Was man hier aber schliesslich einstellt, muss jeder für sich selbst entscheiden.
Yakuake im Einsatz
Ja, es ist eben ein Terminal und man kann darin alles das machen, was man auch in jedem anderen Terminal machen kann.
Drückt man unten auf das +, wird ein neuer Tab gestartet. Das ist eine wirklich gute Sache, die aber eigentlich auch von vielen anderen Terminals unterstützt wird. Yakuake kann es eben auch.
Klickt man, anstatt auf das +, mit der rechten Mousetaste in die Leiste, kann man einen neuen Tab auch mit zwei Terminals gleichzeitig öffnen. Entweder horizontal, oder vertikal. Auch eine super Sache, wie ich finde. Terminator ist in der Hinsicht zwar noch flexibler, aber den muss ich auch immer erst starten und kann ihn nicht einfach so ausrollen.
Am unteren, rechten Rand finden sich drei Symbole. Das Mittlere, mit den drei Linien, öffnet ein Menü. Dort finden sich einige Punkte, wie man Yakuake auch noch anpassen kann. Da gibt es etliche Varianten für das Verhalten, die Fenster und auch das ganze Erscheinungsbild lässt sich ändern.
Klickt man hingegen mit Rechts in einen Terminal, so bekommt man auch die Möglichkeit, eigene Profile anzulegen und zwischen diesen zu wählen. Wie das Bild zeigt, wurde an Einstellungsmöglichkeiten dabei nicht gespart!
Meine Meinung
Tatsächlich ist meine Meinung subjektiv. Aus irgendeinem Grund gefällt mir Yakuake, seit ich es das erste Mal benutzt habe. Ich habe dabei allerdings nichts gefunden, was andere Terminals nicht auch können und genau genommen ist Terminator sogar auch etwas besser, aber dennoch hat es mir Yakuake echt angetan!
Guake
Dazu ist wohl nichts zu sagen. Es gilt das Gleiche, wie bei Yakuake. Es ist ein Terminal, der von oben ausgerollt wird und dort auch wieder verschwindet.
Installation
Auch hier ist die Installation einfach:
sudo pacman -S guake
In meinem Fall muss nichts von KDE nachinstalliert werden, von daher schlägt guake auch nur mit knapp 8 MB zu Buche. Lassen wir es laufen!
Viel passiert da nicht und alles läuft reibungslos, wie erwartet!
Autostart
Wie auch bei Yakuake, reicht es völlig aus, guake mit dem WindowManager, oder dem Desktop Enviroment zu starten. Unter Cinnamon bemüht man wieder Startprogramme. Dieses Mal muss man jedoch Guake-Terminal aufwählen.
Dann mal einen flotten Reboot und schauen, wie es so läuft.
Hat geklappt! Man wird darüber informiert, dass der Guake Terminal gestartet wurde und er den Hotkey F12 bekommen hat. Ich würde das jetzt normalerweise ändern, muss man ja aber eben nicht. Ausserdem zeigt sich in der Leiste das kleines Symbol. Wie bei Yakuake eben auch. Läuft!
Guake im Einsatz
Hier zeigt sich direkt ein Unterschied. Der ganze obere Bereich wird vom Terminal in Beschlag genommen. Das ist es auch, was ich bislang nicht so gut fand. Bei Yakuake ist es nur ein Teil. Dafür ist Guake teilweise transparent. Die Einstellmöglichkeit habe ich zwar bei Yakuake auch gefunden, aber funktioniert hat sie nicht.
Guake weiss jedoch zu punkten! Genau wie bei Terminator, kann man hier die einzelnen Terminals horizontal und vertikal teilen. Auch der geteilte Terminal lässt sich wieder teilen! Das gefällt mir seht gut!
Darüber hinaus beherrscht Guake auch Tabs, womit man dann noch viel mehr Terminals bequem verwenden kann. Also was die Ausstattung angeht, ist Guake definitiv im Vorteil. Auch scheinen mir die Menüs und alles intuitiver, als bei Yakuake.
Auch was die Einstellmöglichkeiten angeht, weiss Guake zu überzeugen und da gibt es auch die Möglichkeit, die Breite des Terminals zu reduzieren. Muss ich gleich mal ausprobieren!
Voll toll! Man kann nicht nur die Grösse anpassen, sondern Guake auch von unten ausklappen lassen. Ja, damit ist es nicht mehr so ganz Quake-Like, aber wer so lieber mag, der sollte die Möglichkeit auch haben.
Meine Meinung
Tatsächlich hat mich der Artikel dazu gebracht, nun wohl doch eher Guake auf meinem Desktop einzusetzen. Oder, ich verwende vielleicht auch einfach beide! Einer klappt von oben, der Andere von unten. Könnte lustig sein. Aber mal abwarten.
Auf jeden Fall ist es trotzdem so, dass Yakuake diesen einen kleinen Punkt hat wo ich sage, der gefällt mir was besser. Was, weiss ich aber leider nicht. Darüber hinaus ist aber Guake in meinen Augen Yakuake echt überlegen!
Fazit
Also, einen wirklichen Champion würde ich nicht küren wollen. Hier ist Guake etwas besser, hier wirkt Yakuake etwas ansprechender. Beide scheinen ihren Zweck hervorragend zu erfüllen und ich werde ja sehen, wie sich die Beiden in nächster Zeit so schlagen.
Wer sich unsicher ist, dem kann ich dennoch einen Rat geben. Wer einen WindowManager verwendet, der GTK+ verwendet, oder ohnehin aus anderen Gründen GTK+ installiert hat, der kann zu Guake greifen.
Wer jedoch ohnehin mit Plasma, oder sonstigen Anwendungen unterwegs ist, die auf QT5 basieren, der kann sich auch getrost Yakuake zu Gemüte führen.
Ansonsten, installiert das, was euch als Erstes in den Sinn kommt.
