Git-Grundlagen

Git ist ja eine sehr, sehr mächtige Versionskontrolle, um Softwareprojekte zu verwalten; nicht nur, aber ich möchte Ihnen mal aus diesen vielen verschiedenen Grundlagen vier Begriffe erklären, die für unsere Übungsdateien wichtig sind. Das sind: Was ist ein Repository? Was sind Commits? Was sind Branches? Und: Wie unterscheidet sich eigentlich Git von GitHub? Fangen wir damit an, was ein Repository ist. Ein Repository ist nichts anderes als ein Projekt quasi, eine Sammlung von Dateien. Wenn Sie nach github.com/LinkedInLearning gehen, dann sehen Sie die verschiedenen Repositories, die verschiedenen Repos, sagt man auch, für die jeweiligen Kurse. Also, wenn ich jetzt hier beispielsweise mal nach WordPress suche, dann sehe ich jetzt hier, es gibt sechs verschiedene Repositories, die sich irgendwie mit WordPress beschäftigen. Und wenn ich jetzt hier reingehe in eines, dann habe ich hier ein Repo, das heißt, es sind alle Übungsdateien mit ihrer Versionsgeschichte zu einem Training. Das ist ein Repo, nichts anderes, einfach nur ein Projekt innerhalb von Git. Schauen wir uns an, was Commits sind. Stellen Sie sich vor, Sie haben eine Datei, die heißt app.ext, Extention, beispielsweise, und da ist eine Funktion definiert, die heißt a und die gibt nichts anderes als 1 aus. Jetzt sagen Sie: "Na ja, ich möchte eigentlich diese Funktion ändern, die soll etwas Neues machen, die soll 'okay' ausgeben." Das heißt, ich gehe in diese Datei, ändere diese Datei, speichere sie erneut ab und jetzt ist diese alte Änderung eigentlich nicht mehr da, außer Sie benutzen Git. Das heißt, ich kann später wieder auf diesen alten Zustand zurückgreifen. Wenn Sie jetzt weiter an Ihrer App arbeiten, dann fügen Sie beispielsweise eine neue Funktionen hinzu, function b, die soll nur ein "true" zurückgeben, speichern das Ganze auch wieder in dieser Datei app.ext und Sie können jetzt später wieder auf diese beiden vorherigen Zustände zurückgreifen. Das hier sind die einzelnen Commits. Und jetzt gehen Sie weiter und Sie sagen hier: "Na ja, gut, anstatt 'okay' möchte ich nur ein 'ok' zurückgeben und anstatt ein 'return true' ein 'return false'." Und mit Git kann ich diese einzelnen Änderungen, diese einzelnen Zwischenspeicherungen, später immer wieder hervorholen und die reihen sich einfach so hier, wie auf einer Perlenkette. Das heißt, ich habe quasi einen riesigen Strg+Z-Button und kann immer zurückgehen. Und jeder einzelne dieser Zwischenspeicherungen, die nennt man Commit. So ein Commit muss nicht nur aus einer Änderung in einer Datei bestehen, sondern er kann auch aus Änderungen an einer Vielzahl von Dateien bestehen. Das heißt, Sie haben in der einen Datei was geändert, Sie haben eine Datei gelöscht, eine andere hinzugefügt und all diese Änderungen, die Sie als ein Commit zwischenspeichern möchten, auf die können Sie später wieder zugreifen. Das sind die einzelnen Commits, also die einzelnen Zwischenspeicherungen, auf die man später zugreifen möchten. Dann brauchen wir noch die Erklärung: Was sind den eigentlich Branches? Denn die verwenden wir in unseren Übungsdateien auch sehr intensiv. Schauen wir uns das mal an. Ich habe hier eine Datei, die hat eine Funktion, die heißt login, und da steht zunächst einmal nur einen Kommentar: "do s.th.", tue irgendwas, und das habe ich als Commit tatsächlich so gespeichert, dann habe ich das mal. Und jetzt sage ich, okay, dieser login, der soll ja auch irgendwie eine Funktion ausführen, also er bekommt hier ein User übergeben in der Variablen $u und setzt dann den User auf diese Variable. Das ist jetzt hier Pseudo-Code in irgendeiner ausgedachten Programmiersprache. Wie geht es jetzt weiter? Stellen Sie sich vor: Sie möchten eine neue Funktion programmieren und die heißt logout, dann könnten Sie einen neuen Branch aufmachen, einen neuen Zweig, und da programmieren Sie hier diese Funktion logout hinzu, die bekommt ein Benutzer übergeben und dann wird dieser Benutzer hier wieder gelöscht. Und das möchte ich nicht auf dem Main-Branch machen, denn die Entwicklung dieser neuen Funktion, die kann mehrere Tage und Wochen dauern, auf jeden Fall viele verschiedene Commits, ich möchte weiterhin meinen sauberen Hauptzweig haben, der wird nämlich immer veröffentlicht auf der Webseite, und neue Features baue ich hier der Reihe nach ein. Und wenn Sie genau hier hinschauen, dieser Pseudo-Code ist schon ein bisschen komisch, denn ich kann jetzt auch einen fremden Nutzer oder eine fremde Nutzerin ausloggen; natürlich braucht diese Funktion keinen Nutzer übergeben, sondern es wird einfach nur der aktuelle Nutzer ausgeloggt. Weiterhin ist der Hauptzweig von dieser Änderung völlig unbeeindruckt, das heißt veröffentlicht auf der Website, beispielsweise, ist genau dieser Zustand, und im Verborgenen kann ich in einem zweiten Branch, in einem zweiten Zweig, diese Änderung vornehmen. Der Vorteil ist, wenn jetzt jemand herkommt und sagt: "Na, ich möchte doch eigentlich in meinem Hauptbranch noch eine Änderung vornehmen, z.B. einen Fehler ausmerzen, einen Bug fixen, beispielsweise hier noch ein "return true" zurückgeben, dann habe ich von meiner Software jetzt zwei verschiedene Varianten in diesen Branches. Der eine Branch heißt main, den gibt es immer, das ist der Hauptbranch, entweder heißt der main oder master, und diese verschiedenen anderen Branches, denen kann ich neue Namen selber geben, wie ich das möchte. Und ich kann jetzt hier auch weiterarbeiten, ich kann sagen, na ja, der soll nicht immer nur true zurückgeben, sondern der soll nur dann true zurückgeben, wenn dieser Nutzer auch tatsächlich gesetzt wurde; wenn es da einen Fehler gab, dann wird hier natürlich ein false zurückgegeben. Das heißt, in diesem Branch kann ich arbeiten unabhängig von dem anderen Branch. Und wenn ich in diesem Feature-Branch hier unten fertig bin und sage: "Okay, jetzt habe ich meine logout-Funktion vollständig programmiert und getestet, jetzt möchte ich diesen Branch mit diesem wieder verbinden", dann kann ich beide Branches mergen. Das heißt, die Änderungen von beiden werden von Git automatisch zusammengeführt. Und das ist das Spannende. Das heißt, ich habe hier die aktuelle logout-Funktion, hier, wie sie in diesem Commit festgelegt wurde, und ich habe die login-Funktion, wie sie hier oben programmiert wurde, und nicht mehr, wie sie hier unten drin steht. Und das ist das Spannende, dass Git diese Verknüpfung von diesen verschiedenen Branches automatisch macht, das ist eine ganz, ganz große Stärke von dieser Versionskontrolle. Damit haben wir die Branches. Das heißt, ich habe in meinem Repo verschiedene Zustände meiner Software und ich kann jetzt auf dem Branch arbeiten, auf dem ich eben arbeiten möchte. Dann brauchen wir zu guter Letzt noch den Unterschied zwischen Git und GitHub. Git ist die Versionskontrolle und GitHub es einfach ein Server, auf dem man gemeinsam Repos teilen kann. Also, hier auf github.com/LinkedInLearning habe ich verschiedene Repos, die sind öffentlich zugänglich, kann ich reingehen, und wenn ich jetzt mit diesem Repo arbeiten möchte, dann klone ich mir dieses Repo, habe dann eine lokale Kopie, die mit der öffentlichen Version auf dem Server nichts mehr zu tun hat. Das heißt, für unseren Übungsdateien klonen wir dir Repos von GitHub, von dem öffentlichen Server, und arbeiten dann ausschließlich lokal. Noch mal zusammengefasst, die vier Git-Grundlagen, die wir für unsere Übungsdateien brauchen. Ein Repository ist einfach nur eine Sammlung an Dateien, das sind Übungsdateien für einen Kurs. Commits sind die einzelnen Zwischenspeicherungen, es kann sein, dass Sie im Alltag, wenn Sie mit unserem Übungsdateien arbeiten, mit diesen Commits gar nichts zu tun haben. Wichtig sind aber die Branches, das heißt, das sind verschiedene Verzweigungen, verschiedene Versionen des Quellcodes. Und dann noch der Unterschied zwischen Git und GitHub besteht darin: GitHub, das sind die öffentlichen Repos, und um damit zu arbeiten, müssen Sie ein öffentliches Repo lokal klonen.