Skillbyte Podcast #64: So funktioniert GIT!

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: So funktioniert GIT!

// Inhalt //
01:00 - Vorstellung
01:39 - Was ist git eigentlich?
04:06 - Besonderheiten von git
05:57 - Nutzung von git in (großen) Teams
09:36 - Der typische git Workflow
11:50 - Repositories klonen mit git clone
12:32 - Änderungen historisieren mit git commit
13:22 - Eigene Änderungen veröffentlichen mit git push
15:32 - Featureentwicklung auf Branches
17:41 - Änderungen in bereits existierende Branches integrieren mit rebase
19:25 - Commits taggen
20:02 - So funktioniert ein Pull/Merge Request
22:06 - Merge Konflikte
24:08 - GitHub und Gitlab

Dezentrale arbeitsweise von GIT: https://de.wikipedia.org/wiki/Git#/media/Datei:SVNvsGITServer_2.png

Git Explained in 100 Seconds: https://www.youtube.com/watch?v=hwP7WQkmECE

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Und man kann sich der Maintainer, also der Verantwortliche für das Ursprungsprojekt, entscheiden, eure Änderungen wieder zurückzuführen in das Hauptprojekt. Das ist natürlich auch ein tolles Erfolgserlebnis, weil potenziell eure Änderungen dann von tausenden, Zehntausenden, hunderttausenden anderen Nutzern da draußen benutzt wird. Herzlich willkommen zu y Podcast Episode Nummer 64. So funktioniert gibt. Abonniert unseren Podcast für mehr spannende Themen aus dem Technologieumfeld, wenn ihr IT Entscheider oder IT Fachkraft seid. Wenn er eine Hörerfrage habt, schreibt gerne eine Email an Podcastet Skill bei D. Und wir freuen uns auch immer über bewährten und ganz besonders über Weiterempfehlung an eure Freunde und Kollegen. Ich bin in der heutigen Podcast Episode alleine und möchte mit euch über das Werkzeug Git sprechen. Ich heiße Maurice. Ich bin Data Engineer und Softwareentwickler bei Skillbyte und zudem auch Podcasthost. Ich setze Software Code Versionierung seit über 20 Jahren ein, habe angefangen mit Subversion und nach einigen Jahren habe ich für circa ein Jahr Mercurial benutzt. Das hat schon einige Features, die auch Git mit sich bringt und nutze nun das Software Werkzeug geht seit über zwölf Jahren in ganz vielen verschiedenen Projekten und Ausprägungen.

Also manchmal benutze ich nur sehr wenig Features von Git und manchmal auch die ganze Featurepalette, die ich euch heute näherbringen möchte. Ich möchte kurz mit euch zum Einstieg darüber sprechen, was Git eigentlich ist. Im Jahr 2005 hat der damalige Linux Körner Entwickler Linus Torvalds den Gedanken gehabt, ein neues Quellcode Management Software System zu implementieren. Es gab Probleme mit dem bisherigen und er wollte einfach eine neue Implementierung durchführen, hat dies auch getan und innerhalb von wenigen Wochen stand die erste Softwareversion von GIT zur Verfügung. Ursprünglich für die Linux Kernel Entwicklung gedacht, was natürlich ein großes Projekt mit Millionen Codezeilen ist und auch mit vielen, vielen 1000 Menschen auf der ganzen Erde, die zusammenarbeiten müssen, ist das natürlich schon eine große Anforderung an so ein Softwaresystem. Generell ist Git zur Versionierung von Software Quellcode entworfen worden, also der Versionierung von Textdateien. In den Textdateien steht auch Computercode drin und hat sich mittlerweile. Im Jahr 2022 befinden wir uns aktuell auf breiter Front durchgesetzt. Theoretisch könnte dir damit auch Binärdaten versionieren, also Photoshop Dateien, Bilddaten usw. Das wird auch in vielen Projekten gemacht, Teilweise die wirklichen Stärken oder viele, viele Stärken kann Git aber nur ausspielen, wenn man es für Textdateien in Anführungszeichen einsetzt.

Das können Softwarequellcode sein, das können auch einfach normale Texte sein, Dann Texte zum Beispiel. Das wird alles davon abgedeckt. Der Linux Kernel, den haben wir schon angesprochen, der wird natürlich mit Git entwickelt und seit 2017 auch das Microsoft Windows Betriebssystem, was ja sehr bekannt ist. Und das muss man sich vorstellen, das war natürlich ein großer Schritt von Microsoft, von einem eigenen System dann auf Git umzustellen, was ja aus der Linux Welt kommt. Und lange waren beide Welten, die Linux und die Microsoft Windows Welt verfeindet bzw. konnten sich nicht gut riechen. Ich habe eine Statistik gefunden auf OpenHAB. Im April 2019 verwendeten rund 69 % aller dort registrierten Softwareprojekte Git. Damit dominiert Git mit großem Abstand die Code Versionierung Charts. Der nächst platzierte ist Subversion mit nur 25 % und das dürfte sicher. Seit dem Jahr 2019 dürfte sich das Verhältnis noch weiter zu Git verschoben haben. Es gibt große Plattformen, GitHub, die bestimmt GitHub kommen oder GitHub gibt es auch, wo Open Source Projekte ihren Quellcode speichern und dieser wird dort auch weiterentwickelt. Also das ist quasi sind Hosting Plattformen auf den Quellcode von privaten Softwareprojekten und auch öffentlichen Projekten weiterentwickelt wird.

Okay, jetzt habt ihr ein bisschen Hintergrundinformation. Was ist denn das Besondere an Git? Ein ganz besonderes Feature bei Git ist, dass es dezentral arbeitet. Das heißt, man kann im Grunde fast alle Funktionen nutzen, ohne dass man einen permanenten Onlinezugang benötigt. Damit kann man zum Beispiel im Flugzeug entwickeln oder unterwegs, wie auch immer, wo auch immer man gerade ist und hat trotzdem eine Versionierung, kann Commits machen, kann in der Historie nachschauen von gewissen Dateien, ohne dass man verbunden sein muss. Dazu gibt es ein tolles Bild in der Wikipedia, das packe ich euch unten in die Shownotes zu dieser Podcastepisode. Damit kann man also auch alleine verwenden, wenn man nicht im Team arbeitet. Und dort ist es auch hilfreich. Man hat zum Beispiel das ist eine sehr große Erleichterung. Man muss keine Angst vor dem Löschen haben, wenn man zum Beispiel in Projekten große Umbauten macht und einfach alte Klassen löscht, die man nicht mehr benötigt. Normalerweise hat man vielleicht Angst, verschiebt die in Ordner, dass man zur Not noch mal nachgucken kann, dass diese Angst muss man nicht haben.

Man kann die Datei einfach löschen, wenn sie versioniert ist und kann in der Historie zurückspringen und dann erscheint die Datei wieder. Oder man kann schauen, was stand da drin. Das heißt, man kann völlig angstfrei entwickeln, auch große Umbauten machen. Man kann in der Story nachschauen von jeder einzelnen Datei, die versioniert ist. Wie hat sich die entwickelt? Über die Zeit? Man kann auf eigenen Branches, da kommen wir gleich noch zu etwas testen, also beispielsweise ein Versionsupdate einer bestimmten Bibliothek in der Datenbank. Zum Beispiel. Oder eine experimentelle Funktion implementieren, ohne Angst etwas kaputt zu machen an dem Hauptstamm. Also man kann sich sehr frei bewegen als Softwareentwickler. Das gleiche würde natürlich auch gelten, wenn ihr beispielsweise ein Buch schreibt und ihr eine Textdatei habt. Auf der Festplatte und schreibt euer Buch in dieser Textdatei, dann könnt ihr natürlich auch dort wieder zurückgehen. Im Kapitel Löschen habt die dann aber in der Versionierung drin usw. Also auch da ist es ja praktisch. Die gesamte Leistungsfähigkeit entsteht aber erst, wenn man Git in Entwicklungsteams einsetzt.

Also wenn mehrere Leute gleichzeitig an einem Code Repositorium, also an einer Codebasis arbeiten. Also die Entwickler können ohne Angst zu haben, an allen möglichen Stellen im Code Änderungen vornehmen. Das ist ganz typisch passiert das zum Beispiel, dass die Fronten Entwickler ihren Teil weiterentwickeln, die Backend Entwickler ihren Teil weiterentwickeln und das eben zusammengeführt werden kann, einfach durchgeht, dass verschiedene Module von verschiedenen Mitarbeitern betreut werden. Auch teilweise können die Leute gleichzeitig an einem Modul arbeiten. Das ist auch kein Problem. Und viele, viele dieser Änderungen können von Git automatisiert zusammengeführt werden. Es kann auch sein, wenn genau die gleiche Codezeile beispielsweise von zwei unterschiedlichen Entwicklern editiert wurde und das System jetzt nicht entscheiden kann. Was ist denn die richtige Zeile oder wie kann ich die Änderung zusammenführen? Da muss der Mensch helfen, das spreche ich gleich auch noch mal an. Das sind die sogenannten Merge Konflikte. Aber generell in 98 % der Fälle schafft das System das komplett autark, diese Änderungen zusammenzuführen. Und man muss überhaupt keine Angst haben, dass Änderungen verloren gehen, beispielsweise Versioningsysteme. Dazu gehört Git, aber auch Subversion und ältere Systeme wie CVS Conversioning System sind der Grund, warum heute so effektiv und effizient Software gemeinsam überhaupt entwickelt werden kann.

Also über das Internet, über mehrere Zeitzonen hinweg, in globalen Teams auf unterschiedlichen Kontinenten, die teilweise auch tausende Mitglieder haben können. Der Linux Kernel zum Beispiel wird von tausenden freiwilligen Entwicklern entwickelt, die alle ihre Änderungen zusammenführen müssen der Grafikkarten, Treiber, Entwickler, die Systementwickler, Entwickler und und und und und USB Subsystem Entwickler. All diese Änderungen werden zusammengeführt oder müssen zusammengeführt werden. Und ohne ein Code Versionierungssystem wie GIT wäre das überhaupt nicht möglich, weil der Arbeitsaufwand riesengroß wäre. Das heißt, eine sehr, sehr große Wertschöpfung entsteht erst dadurch, dass man eben im Team einsetzt. Hat man eine Online Netzwerkverbindung, kann man eben die Änderungen, die man lokal gemacht hat auf seinem Rechner. Wir haben ja eben schon gesehen, das geht auch ohne Netzwerkverbindung funktioniert. Kann man diese Änderung auf andere Repositorien pushen, also zum Beispiel die Änderungen, die man gemacht hat, wieder in ein Ursprungs repositorium zurückzuführen. Beispielsweise wenn man sich an einem Open Source Projekt beteiligt, liegt das Ursprungs repositorium oft bei GitHub oder einem anderen Githoster. Manchmal lohnt es auf die eigene Festplatte zunächst oder SSD arbeitet darauf meistens auf einem Branch.

Macht eine Änderung, passt das für sich an und wenn man diese Änderungen in der Community wieder zurück zur Verfügung stellen möchte, kann man diese Änderung pushen. Auf GitHub geht diese Änderung dann wieder zurück und dann kann sich der Maintainer, also der Verantwortliche für das Ursprungsprojekt, entscheiden, eure Änderungen wieder zurückzuführen in das Hauptprojekt. Das ist natürlich auch ein tolles Erfolgserlebnis, weil potenziell eure Änderungen dann von tausenden, zehntausenden, hunderttausenden anderen Nutzern da draußen benutzt wird und zum Einsatz kommt. Also im Falle des Linux Kernel sind es Millionen von Usern, die unser Code verwenden, wenn der Quellcode in den Hauptzweig zurückgeführt wird. Das heißt, die dezentrale Organisation von Git Repositorien ohne den permanenten Zwang zur Onlineverbindung ist eine große Stärke. Jeder kann autark arbeiten und auf Anforderung, wenn die Internetverbindung besteht, kann man eben diese Repos wieder zusammenführen. Okay, wunderbar. Jetzt haben wir so einen groben Überblick, was Git ist, also ein System zur Quellcode Verwaltung, was man allein und im Team benutzen kann und was es ermöglicht, in sehr, sehr großen Teams verteilt zu arbeiten.

Wie sieht denn ein typischer Workflow aus? Da haben wir jetzt schon einige Punkte angesprochen, um ein Git Workflow selber durchlaufen zu können, zum Beispiel auf eurer eigenen Kommandozeile. Ist es zunächst notwendig, euer eigenes Betriebssystem jetzt zu installieren? Das ist sehr einfach, denn Git gibt es für fast alle Betriebssysteme, die in der Breite vorkommen. Also natürlich Microsoft, Windows, Linux, Mac. Überhaupt keine Frage. Müsst ihr einfach nur googeln und findet sofort die Installationsdateien. Es gibt ein sehr ansprechendes Video, was in 100 Sekunden den GitWorkflow zeigt und einige Beispiele aufführt. Das packe ich euch auch unten in die Shownotes zu dieser Podcastepisode. Das könnt ihr in einer ruhigen Minute oder in ruhigen 100 Sekunden gerne mal anschauen. Und wenn ihr euer Betriebssystem installiert hat, kann man auch schon loslegen. Im Grunde am besten öffnet die Kommandozeile und erstellt ein eigenes Verzeichnis. Work zum Beispiel oder test oder git und innerhalb des Verzeichnisses ruft. Dann gibt init auf zwei Wörter, die einfach git sagen. Dieses Verzeichnis möchte ich unter Kontrolle bringen. Das war es schon.

Jetzt könnt ihr Dateien diesem Verzeichnis hinzufügen. Und wenn ihr alle Dateien habt, zum Beispiel eine Textdatei oder mehrere Quellcode Dateien, könnt ihr die hinzufügen einzeln auf der Kommandozeile mit git add, dateiname oder git Punkt. Wenn ihr noch in dem Verzeichnis steht, dann werden alle Dateien in dem Verzeichnis hinzugefügt und ab nun sind die Dateien versioniert und git kümmert sich darum. Das heißt jetzt aber nicht, dass jede Änderung automatisch protokolliert wird, sondern an einem gewissen Punkt macht ihr einen Commit und die Commits werden historisiert. Was man auch noch sagen sollte, ist, dass nicht alle Dateien versioniert werden sollen. Also wenn ihr eine typische Projektdatei habt, dann kann es ja sein, dass darunter auch temporäre Dateien liegen. Lokale Einstellungen, die nur euren Codeeditor betreffen oder euren PC betreffen. Zum Beispiel baut das Java Home liegt. Das möchtet ihr natürlich nicht einchecken und diese Dateien würdet ihr nicht Mitglied hinzufügen, weil die nur für euch gelten und euren Rechner und eure Settings notwendig sind und nicht für gegebenenfalls andere Entwickler, die auch an dem Projekt arbeiten.

Das ist ganz, ganz wichtig. Jetzt haben wir gelernt, wie man ein Verzeichnis unter git Version skontrolle nimmt, inklusive der Dateien einer Alternative. Und das ist ehrlich gesagt der häufigere Fall ist, dass es schon ein Repositorium gibt, etwa in eurer Firma, wo ihr drauf arbeiten möchtet, oder ein Repositorium von GitHub. Com Ein Open Source Projekt beispielsweise besteht bereits. Dann würde man das ository klonen, damit man eine lokale Kopie davon erhält. Dafür gibt es den Befehl git clone und dann Leerzeichen dahinter paketurl oder https url wird der Pfad zum Repositorium angegeben. Den könnt ihr auch bei GitHub immer ablesen oben und dann wird eine lokale Kopie von dem Repositorium, was auf GitHub gehostet ist, auf euren Rechner übertragen, wo ihr dann wieder völlig autark arbeiten könnt. Jetzt könnt ihr Dateien ändern Textdateien, Source Code, Dateien, XML, Dateien, Marker down Texte usw.. Wenn ihr mit den Änderungen dann immer zufrieden seid, also beispielsweise habt einen weiteren Absatz Dokumentation in eine Textdatei geschrieben und entschließt euch Ja, das ist jetzt ein guter Zeitpunkt, um einen Comic zu machen, also um diese Änderung zu historisierend.

Dann würdet ihr mit git commit ein absetzen. Dann müsst ihr noch eine Commit message eingeben. Die Message sehen dann alle. Das heißt, hier ist es ganz, ganz wichtig, dass er einen aussagekräftigen Text eingibt, also was ihr gemacht habt. Edit Documentation for function zum Beispiel. Und diese Nachricht könnt ihr dann bestätigen. Jetzt ist ein Commit erzeugt und stellt euch vor, ihr arbeitet jetzt den ganzen Tag an diesem Quellcode Repositorium. Es stellt immer weiter Commits, wenn ihr einen Arbeitsschritt erreicht habt und dann entsteht eben diese Commit Historie. Ganz wichtig an dieser Stelle diese Änderungen, diese Commits sind bisher nur lokal in eurem eigenen Repository auf eurer eigenen Festplatte bzw. SSD vorhanden. Es ist aber meistens so, wenn man mit anderen zusammenarbeiten möchte, dass man die Daten auch auf einen zentralen Server hochladen möchte, pushen und um dann eben diese Änderungen den anderen Teammitgliedern wieder zur Verfügung zu stellen. Der Push kann auf den GitHub Server erfolgen. Das kann auf einen Firmenserver erfolgen, wo das Firmen Repositorium liegt, je nach Einsatzzweck. Die Bezeichnung für dieses Remote Repositorium, also etwa auf GitHub oder dem Firmenserver ist genau das Remote Repo oder Origin spricht man auch von.

Also man pusht seine Änderungen zurück auf Origin oder auf das Remote Repo. Wir haben jetzt alleine arbeitet, sind die Änderungen, die man macht und die Commits, die man macht relativ unspektakulär. Dennoch, wie eben schon angesprochen, hat man natürlich dann alle Versionen einer Datei und kann immer wieder zurückspringen. Das auch, wenn man ganz alleine an einem Source Code arbeitet oder an einem Buch oder einem Text, würde ich empfehlen, dass man auch da Commits macht, um Sicherungspunkte zu haben. Wenn man abends beispielsweise seine Arbeit speichern möchte. Einfach zu schauen, wie hat sich eine Datei über die Tage entwickelt. Das lässt sich auch für Dokumente, also beispielsweise Dokumente oder Präsentationen, nutzen. Dann hat man keine. Wir kennt das vielleicht, dass man ein Dokument hat, eine Präsentation, dann heißt man Final Final zwei wirklich Final 123 final, weil man immer noch eine neue Version macht. Das muss man mit Git nicht machen, sondern man überschreibt die Datei immer und kann dann eben ein Commit ausführen und kann beliebig in der Zeit zurückspulen, um sich die alten Versionen von vorgestern oder so dann wieder zu holen.

Bei Binärdokumenten wie Präsentationen oder Microsoft Word ist es oft leider so, dass man nicht zwei Dokumente nebeneinander halten kann und die Unterschiede erkennen kann. Auch bei Photoshopdateien wäre das nicht so einfach möglich, das es bei Textdateien sehr einfach möglich. Deshalb ist Git am geeignetsten, wenn man mit Textdokumenten im Master Downfall XML Software Source Code arbeitet. Aber auch alleine um das abzuschließen kann man Commits machen in seinem lokalen Repo, um seine Arbeit zu protokollieren. Würde ich auch empfehlen. Man gewöhnt sich dran und später, wenn man im Team entwickelt, ist der Sprung nicht mehr so groß und man hat sich schon an den. Gewöhnt. Wenn man nun mit mehreren Entwicklern im Team arbeitet, gibt es noch weitere Funktionen, die die Arbeit vereinfachen. Potenziell können ja Tausende von Menschen an so einem Open Source Repositorium arbeiten und Funktionen erweitern. Und das passiert auch bei großen Open Source Projekten wie dem Linux Kernel oder verschiedenen Apache Projekten. Und man kann von der Hauptversion, die ihr direkt seht, das wird Hauptzweig genannt oder man kann man ab Branchen. Also da hilft euch das eingangs erwähnte Video, was diesen Workflow zeigt.

Wenn ihr das würde ich immer empfehlen, ein eigenes Feature entwickeln möchtet oder eine Änderung entwickeln möchtet und ihr wisst, dass sie mit mehreren im Team arbeitet, dann macht einen eigenen Branch, der nur für euch da ist oder für nur dieses Feature da ist, wo dann ihr und eure Kollegen darauf arbeiten können. Die Eigenentwicklung findet dann auf dem Branch statt. Nennen wir ihn mal Feature eins. Hier ist man dann alleine oder mit den anderen Kollegen unterwegs, dieses Feature umzusetzen. Wenn das Feature fertiggestellt wurde, zum Beispiel in fünf Commits, können diese Änderungen dann wieder in den Hauptzweig Main zurückgeführt werden. Man spricht in diesem Fall auch von einem. Also man Branch von dem Hauptzweig ab, macht seine eigenen Änderungen und die Änderungen. Wenn sie denn fertig sind, macht man die eben zurück in den Hauptzweig. Und meistens ist es dann so, dass dieser Hauptzweig, also Main, wird dann auf das Testsystem ausgespielt oder vielleicht sogar auf das Produktionssystem auf ausgespielt. Man kann auch einzelne Commits dann eben releasen oder mit einem Tag versehen. Dann steht an dem Tag zum Beispiel dran, dass es einfach nur ein Zeiger auf einen Commit Release eins, so dass man dann diesen speziellen Commit weiß, dass dieser released werden soll.

Das ist auch noch ein Vorgehen, aber das sind auch nur Details. Ganz wichtig ist, dass ihr euch vorstellt, wie man von dem Haupttentwicklungsstamm sozusagen abzweigt, eigene Entwicklung macht und wenn die eigene Entwicklung abgeschlossen ist, kann die wieder zurückgeführt werden von diesen Zweigen. Von den Branches kann es beliebig viele geben, also das Können einer sein, zehn Hunderte, wenn ihr 100 Features gleichzeitig entwickelt. Und bei großen Softwareprojekten wird das sicher der Fall sein. Dann gibt es 100 Bridges oder mehr als 100 Branch. Jetzt nehmen wir mal an, wir brauchen zur Implementierung von eurem Feature eine Woche und innerhalb dieser einen Woche gelangen aber Änderungen Merkies von anderen Features auf den Hauptstamm. Also dann habt ihr diese Änderungen natürlich nicht auf eurem Branch, weil ihr ja schon vor einer Woche abgebrochen habt oder abgezweigt habt. Diesen neuen Code Bugfixes zum Beispiel oder auch neue Features oder neue Bibliotheksfunktionen von allen Kollegen möchtet ihr dann auch auf eurem Entwicklungs Branch haben? Dann könntet ihr die Änderung aus Main in eurem eigenen Arbeits Branch. Wir hatten ihn Feature eins genannt wieder rein Möhrchen.

Somit bekommt ihr dann den frischen Code von Main dann auch in euren Arbeitsbereich rein. Es gibt auch noch die Möglichkeit des Rebays. Das würde jetzt aber zu weit führen in dieser Episode anzusprechen. Macht aber im Grunde das gleiche. Also führt die Änderungen aus dem Hauptzweig in euren Entwicklungszweig nur beim Rebase. Jetzt spreche ich es doch an, ist die Zeithistorie eine andere. Da werden die Änderungen nicht einfach rein gematcht, sondern euer Branch wird auf die Spitze des Hauptzweiges des Man Branch ist wieder aufgesetzt, so dass man eine saubere Commit Historie hat. Wenn euch der Rebeis interessiert oder das Zurückmelden interessiert, würde ich auch hier empfehlen, euch noch mal dediziert zu informieren. Das ist einfach viel einfacher. Wenn man das Video anschaut und visuell dann da durchgeführt wird, dann versteht man das sehr leicht, auch wenn das jetzt rein auf der Tonspur sich sehr komplex anhört. Kurz noch mal zusammenfassend Wenn er eine neue Funktion implementiert, dann erstellt ihr einen Branchenarbeitet auf diesem Branch, führt die Änderungen hinterher auf den Hauptstamm, also auf mein zurück. Mein enthält dann alle getesteten Funktionen und wird dann entsprechend auf das Test oder Produktionssystem ausgerollt.

Meistens, wenn man einen speziellen Commit hat und sagt okay, diesen möchten wir jetzt auf das Produktions oder Testsystem ausrollen, dann wird dieser Commit getaggt. Das könnt ihr euch vorstellen. Wirklich wie eine Lasche, die einfach an ihm dranhängt, wo dann draufsteht Release eins oder ein beliebiger Text. Die Tags sind einfach nur dazu da, Commits zu kennzeichnen, damit man den Commit wiederfindet. Wenn man einen Comet One Tag hat, hat ein Comet einen sehr langen Hash. Darüber ist er auch eindeutig identifizierbar. Aber das macht natürlich nicht so viel Spaß, diese langen Hashes zu suchen und rauszusuchen, sondern da hängt man dann einen Tag dran mit einem Namen, den man frei vergeben kann, um einfach mal deutlich zu machen, worum es sich bei diesem Commit handelt. Ein weiteres Konzept ist der sogenannte Pull Request oder Merge Request. Den möchte ich auch noch mal erklären. Meist läuft das so. Ich habe jetzt gerade eben gesagt, wenn ihr euer Feature auf eurem Branch fertig entwickelt habt, dann merkt ihr, dass zurück in den Main.

In der gelebten Praxis ist es etwas anders und zwar stellt ihr eine Anfrage euer Feature zurück in den Main Stamm zu machen. Und jetzt schaut ein Kollege. Darüber. Guckt eure Änderungen noch mal an, hat gegebenenfalls Anmerkungen und Verbesserungsvorschläge und ihr unterhaltet euch darüber. Ihr macht gegebenenfalls Änderungen zusammen, bevor dann diese Funktion zurück in mein gemacht wird. Im Grunde macht man das Vier Augen Prinzip oder sechs Prinzipien, nachdem wie viele Personen darüber schauen sollen. Eine Qualitätssicherung, ein Pull Request oder ein Request ist eben genau das. Ihr stellt einen Request, eine Anfrage. Okay, ich würde meinen Feature eins Branch gerne in den Main Stamm zurück merken. Liebe zweite Person, schau doch bitte noch mal drüber und nicke meinen Code ab und erst dann erfolgt der Marsch in den main Branch. Das heißt man öffnet sozusagen eine Anfrage, eine zweite Person schaut drüber und nickt dann diesen Code ab. Im Grunde wie eine Kontrolle für euch selber und auch die zweite Person. Im Zuge des Wissenstransfer lernt dann, was ihr da gemacht hat und wie euer Feature funktioniert.

Sollte natürlich dann auch eine technische Person sein. Nichts anderes ist ein Pull Request. Ich kann sich ja vorstellen, wenn ihr beim Open Source Projekt entwickelt und ihr habt ein tolles neues Feature implementiert auf eurem Branch und habt das in eurem GitHub Repo implementiert. Aber in dem Hauptprojekt in der Quelle ist es noch nicht drin, dass ihr dann den Maintainer des Hauptprojektes anschreibt und sagt Puzzle durch meine Änderung ein Pull Request aufmachen, dass er eure Änderung ziehen möge und die dann wiederum in seinen Haupt repositorium integriert, damit das ihm allen Nutzern des Open Source Projektes zugutekommt und nicht nur den Leuten, die genau euren Source Code benutzen. Das ist ganz wichtig. Ein weiteres Thema, was ich noch ansprechen möchte, sind die sogenannten Merge Konflikte oder merge conflicts. Wir haben ja eben den positiven Fall besprochen. Ihr seid mit eurem Feature fertig, Ihr möchte die Änderungen zurück in den Hauptmeinstamm Morgen klickt auf mich und das geschieht einfach so ohne Probleme. Jetzt kann es natürlich sein, dass ein anderer Mitarbeiter, ein anderes Teammitglied, genau die gleiche Stelle im Code verändert habt wie ihr bei euerm Feature.

Also stellt euch vor, nicht beim Source Code, sondern schreibt ein Buch und in dem ein Stamm gibt es einen Satz, der heißt Ich magister grünes Eis und ihr habt den Satz geändert Ich mache blaues Eis und ein Kollege hat den Satz geändert auf Ich magister rotes Eis. Jetzt haben wir die Situation, wenn die beiden Änderungen zusammengeführt werden und ihr beide sozusagen den Satz Ich mal grünes Eis gelesen habt und ihr macht die Änderung wieder zusammen, weiß das System nicht. Ja, was gilt denn jetzt? Blaues Eis oder rotes Eis? In dem Fall würde ich jetzt sagen, ich habe hier einen Merge Konflikt. Lieber Mensch, du musst mir helfen bei den meisten git Implementierung. Wenn git integriert ist in Visual Studio Code oder auch in Intellj, dann geht eine Maske auf, ein diffuser und euch wird links und rechts, wenn die beiden Versionen nebeneinander gehalten und dann sagt Git okay, was möchtest du denn zu blaues Eis oder rotes Eis? Lieber Mensch, du musst entscheiden. In dem Fall musste ich dann mit eurem Kollegen abstimmen und schauen okay, was wollen wir denn jetzt da haben?

Softwaretechnisch kann man das eben nicht auflösen. Wenn die Änderungen dann. Wenn ihr die mithilfe eurer Kollegen gelöst hat, kann man dann sagen okay, ich mache blaues Eis ist die richtige Version oder Ich magister rotes Eis, ist die richtige Version und geht dann helfen, dass die Änderungen korrekt übernommen werden können. Auch da gibt es eine tolle Visualisierung. Das geht Wort Fluss in der Wikipedia auch diesen Link packe ich euch in die Shownotes unten zu dieser Podcast Episode. Jetzt haben wir viele Themen besprochen Branching, Marketing, Repizing, Tasks, Merch, Conflicts und deren Auflösung sind wir durchgeflogen. Ich würde wirklich empfehlen schaut euch die Videos und die Informationen, die ich als Links zu dieser Podcast Episode hinzu packe, noch an.. Als letztes Kapitel möchte ich noch kurz Services ansprechen. Wir haben schon über GitHub gesprochen. GitHub kommen. Meine ich damit. Viele Open Source Projekte lagern ihren Source Code dort. Ihr könnt diese Projekte forken, das heißt das Repositorium komplett übernehmen, in eurem eigenen Bereich darauf Änderungen durchführen und das nach eurem Gusto anpassen.

Das passiert auch regelmäßig und diese Änderungen können dann über Request zurückgeführt werden in das Hauptprojekt, wenn ihr das möchtet, oder wenn der Besitzer des Hauptprojektes das möchte bei GitHub zusätzlich, desto mehr Code ihr bearbeitet, selbst schreibt, Commits macht und bei bestehenden Projekten mitarbeitet. Das kann natürlich auch passieren und das ist eigentlich der häufigste Fall, dass man sich ein Projekt nimmt, was schon existiert und implementiert dann eben Features dazu, die man braucht. Dann bekommt ihr sogenannte Badges dafür von GitHub, also kleine Belohnungen, die zeigen Ihr seid sehr fleißig, sammelt viele Sterne und integriert euch gut in der Community. Da gibt es dann ein Belohnungssystem. Die meisten Repositorien bei GitHub kommen, sind offen, aber man kann dort natürlich auch geschlossene Repos anlegen. Also eure privaten Projekte oder Projekte könnt ihr auch nur für euch oder Authentifizierung Benutzer zugängliche Repositorien anlegen. Bitte beachtet dann das GitHub dann kostenpflichtig wird. Das ist nicht teuer und lohnt sich meistens viel mehr als ein eigenes Repositorium oder einen eigenen GitHub Server aufzusetzen. Aber ich wollte es nur gesagt haben.

Meistens. Wenn ihr für Firmen arbeitet, die Software entwickeln, haben die schon ein internes System um git Repositorien zu hosten. In den letzten Jahren ist mir immer mehr GitLab untergekommen, also nicht GitHub, sondern GitLab. Das ist ein anderes Produkt, was vielfach intern auch eingesetzt werden kann von Firmen und dann auch für eigene Projekte verwendet wird. Das funktioniert total ähnlich wie GitHub. Wenn man das eine benutzen kann, kann man auch das andere benutzen und findet sich sofort zurecht. GitHub ist halt eher für die Community da draußen und GitHub ist eher für interne Projekte. Man kann aber auch beides wechselseitig benutzen, da gibt es keine Präferenz. Um einen ganzen Software Lebenszyklus abzubilden. Ist natürlich nicht nur Versionskontrolle erforderlich, sondern auch noch Continuous Integration continuous delivery. Also wenn zum Beispiel eine Source Code Änderung erfolgt ist, kann ja sofort aus dem Off dem Testsystem ausgespielt werden. Dieses Kapitel lasse ich hier weg, weil ich mich eben auf Git konzentrieren wollte und euch da einen groben Überblick geben möchte, was man alles machen kann und warum dieses Werkzeug die Source Code Welt im Sturm erobert hat in den letzten Jahren, weil es im sehr mächtig ist kostenfrei ist.

Open Source ist auch immer wieder noch neue Funktionen hinzukommen, obwohl es super ausgereift ist und auch große Projekte mit vielen vielen Millionen Zeilen Code damit umgesetzt werden können. Wenn unsere Zuhörer Fragen haben, schickt uns gerne eine Email an Podcast etc. Wir freuen uns immer über Bewertungen und ganz besonders über Weiterempfehlung an Freunde und Kollegen. Abonniert unseren Podcast und schaut auf Skillbyte.de vorbei. Vielen Dank!