Nicht alltägliche Git-Funktionen
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 95 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/32188 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FrOSCon 201792 / 95
4
8
9
15
20
22
23
24
25
27
29
32
36
37
38
39
40
45
46
47
48
49
50
51
53
54
59
63
64
65
74
75
76
79
83
84
86
87
88
89
91
92
93
94
95
00:00
Git <Software>XMLComputeranimationVorlesung/Konferenz
01:21
Git <Software>SystemverwaltungFunktion <Mathematik>Computeranimation
02:31
Netz <Graphische Darstellung>FreewareFunktion <Mathematik>Vorlesung/KonferenzComputeranimationJSON
03:29
ProgrammcodeCodeVersion <Informatik>Git <Software>Wiener-Hopf-GleichungVorlesung/KonferenzComputeranimationXML
07:26
OptimierungC++Funktion <Mathematik>Globale OptimierungGit <Software>SchnittstelleElectronic CommerceVorlesung/KonferenzComputeranimation
09:39
Git <Software>DateiComputeranimationVorlesung/Konferenz
10:24
DateiEbeneVollständigkeitRuhmasseGit <Software>Computeranimation
12:39
AliasingBefehl <Informatik>Nabel <Mathematik>IndexDateiParametersystemQuick-SortRepository <Informatik>SoftwareprojektGit <Software>Keller <Informatik>ComputeranimationVorlesung/KonferenzXML
15:44
Liniep-BlockBefehl <Informatik>
16:51
RelationalsystemBiproduktXMLComputeranimation
17:58
Git <Software>InternetWald <Graphentheorie>AggregatzustandJSONXMLUMLComputeranimation
20:57
VerknüpfungsgliedVersion <Informatik>PlattegrepGit <Software>JSONXMLUML
21:54
Dateip-BlockComputeranimation
23:13
Schreib-Lese-KopfEditorTropfenServerRepository <Informatik>AggregatzustandFormation <Mathematik>Große VereinheitlichungJSONComputeranimation
27:32
InternetInhalt <Mathematik>ZahlKettenregelRepository <Informatik>Befehl <Informatik>DateiDateisystemGit <Software>SpeicherbereinigungJSONXMLUMLComputeranimationVorlesung/Konferenz
31:14
OptimierungRepository <Informatik>Objekt <Kategorie>Ebene KurveGit <Software>CodeXMLComputeranimationJSONUMLVorlesung/Konferenz
32:00
Version <Informatik>DateiComputeranimation
33:08
Twitter <Softwareplattform>QuellcodeDateiRepository <Informatik>BinärdatenPasswortVersionsverwaltungServerIndexKlon <Mathematik>Elektronisches BuchArbeit <Physik>JSONXMLUMLVorlesung/KonferenzComputeranimation
36:59
Repository <Informatik>JSONXMLUML
38:00
Repository <Informatik>Befehl <Informatik>Arbeit <Physik>KonfigurationsraumDateiBinärdatenXMLComputeranimationVorlesung/Konferenz
40:26
OOXMLGit <Software>ProgrammiergerätXML
41:40
Repository <Informatik>Git <Software>BinärdatenAttributierte GrammatikDateiJavaScriptPDF <Dateiformat>XMLVorlesung/Konferenz
43:40
BinärdatenTermumformungRepository <Informatik>Git <Software>CodeMinkowski-MetrikAttributierte GrammatikVorlesung/KonferenzComputeranimation
44:45
Funktion <Mathematik>Git <Software>Komponente <Software>Implementierungt-TestDivisionCodeProgramminspektionChipkarteRichtungMinkowski-MetrikAttributierte GrammatikComputeranimationVorlesung/Konferenz
51:07
Git <Software>ProgramminspektionDateiUniformer RaumVerknüpfungsgliedVorlesung/Konferenz
57:21
ComputeranimationXML
Transkript: Deutsch(automatisch erzeugt)
00:07
Gut, wie der Titel schon dachte, nicht alltägliche Git-Funktion. Ach, da kommt's auch noch. Ich gehe hier von aus, dass die meisten halt schon...
00:21
Oder wer nutzt hier alles Git? Oder wer nutzt kein Git? Einer. Raus. Ist da die Frage, alle fit in Git? Gut. Das ist ein bisschen die Voraussetzung.
00:42
Diverse Sachen werde ich dementsprechend voraussetzen und dann nicht näher drauf eingehen. Da sich jetzt jeder drauf gemeldet hat, dass jeder Git kann, ist jetzt nicht das Problem. Ansonsten wäre hier noch was gewesen. Ich mache morgen noch einen Einsteiger-Workshop von 14 bis 18 Uhr. Könnt ihr euren Freunden sagen,
01:00
die noch kein Git können, wenn die da sind. Ansonsten, den Talk, da sind wir jetzt gerade. Ich hoffe, es ist noch keiner Hunger und rennt vorher weg zum Grill. Generell über den Talk, was erzähle ich hier, was werde ich hier so kennenlernen. Ich hoffe, ihr kennt ein paar Git-Funktionen, die ihr entweder nicht kennt oder nicht nutzt
01:22
oder den Sinn und Zweck dahinter nicht verstanden habt. Das sind alles Funktionen, die man nicht unbedingt jeden Tag braucht. Einige Funktionen, einige vielleicht mehr, andere weniger. Bei einigen kommt es darauf an, ob man Systemadministrator ist oder Entwickler ist. Das ist eine kurze Frage. Wer ist hier Software-Entwickler?
01:41
Und wer ist Systemadministrator? Gut. Genau, Talk ist nicht unbedingt für Git-Anfänger. Ich hoffe, ihr könnt halt Altes, Bekanntes mit Nützlichen verbinden, sodass ihr dann auch wisst, warum diese Funktion nützlich ist
02:01
und wofür man die nutzen kann. Was auch noch wichtig ist, ich mache das Ganze nur auf Git auf der Kommandozeile, weil Git eben ein Kommandozeilen-Programm ist und jedes GUI-Tool anders kacke ist.
02:21
Scheinbar verstehen das hier so viele. Ich mache das manchmal, wenn ich dann so vor Leuten, die mit Git anfangen, Kommandozeile, können wir nicht irgendwie ein GUI-Tool nutzen. Aber für mich ist es halt immer so, dass die Leute, die erst mal mit der GUI anfangen oder teilweise dann auf einem Workshop sitzen von mir, die dann die Kommandozeile nutzen, die verstehen erst dann, was diese ganzen bunten Buttons
02:41
in den GUI-Programmen machen und können es dann erst richtig anwenden. Dementsprechend hier so die Sachen, die ich jetzt voraussetze. Normal geht add, push, pull, merge, commit, alles das, was man so kennt. Auf Rebase werde ich später nochmal kurz eingehen, aber ich denke, das sollte jeder wissen. Das sind auch die Sachen,
03:01
die quasi morgen in meinen Workshop noch drankommen. Das ist quasi meine Lieblingsfunktion, die ich einmal gebraucht habe und ich sie zu dem Zeitpunkt nicht gekannt habe. Und zwar git bisect, wer kennt das? Das sind schon einige. Wie oft nutzt ihr das?
03:25
Ja, genau. Was jetzt der Punkt ist, den Fehler zu finden im Programmcode. Und da ist es aber so wichtig, in der Regel debuggt man ja den Code, guckt, was ist da jetzt genau kaputt, geht Zeile über Zeile oder baut sich irgendwelche Debug-Ausgaben aus.
03:40
Manchmal hatten aber trotzdem so Fehler, die man nicht so auf Anip findet und zwischen irgendwelchen Versionen eingeführt wurden. Und was git bisect macht, das macht ein Beine-Research über die Commits, zwischen zwei Commits, die man eingibt. Weiß jeder, was ein Beine-Research ist? Okay. Da kommt nämlich jetzt die Erläuterung dazu.
04:02
Und zwar habe ich jetzt hier mal so eine Git-Historie, so ganz einfach. Hier sind Versionen V01, V02, 1.0, 1.1 und Master. Master ist quasi gerade der aktuelle Stand und in V01 wurde ein Feature implementiert und danach kamen ganz viele Commits und dann kam eine neue Version
04:22
und dieses Feature hat ungefähr, um das durchzuführen, 100 Minisekunden gebraucht. Wir gehen jetzt davon aus, um Idealzustand, wir haben einen Testcase, dementsprechend es funktioniert einfach. Was jetzt auch ein Problem sein kann ist, wenn jetzt so ein größerer Versionssprung ist, wie hier zwischen 02 und 1,
04:41
da kann das Ganze schon mal eine Sekunde dauern, weil irgendwo plötzlich was eingebaut wurde, was einfach nur das ganze Prozess langsam macht. Was dann auch mal schlimmer machen kann ist, wenn das zum Beispiel irgendwie 10 Sekunden dauert und man weiß nicht, wo das Problem liegt, weil eben die ganzen, weil es irgendwo mal langsam wurde, aber das hat nichts direkt mit dem Feature eventuell zu tun.
05:02
Und was jetzt Git BISAC macht, es macht eine Binärsuche über die Historie, wie man sie angibt. Und zwar hatten wir hier, ich gehe mal wieder zurück, hier hat alles gut funktioniert, hier hatten wir einen schnellen Prozess, hier hat das dann nicht mehr so gut funktioniert und hier ist es nochmal langsam geworden. Das heißt, zwischen diesen beiden Versionen
05:22
müssen wir irgendwo die Commits finden, wo der Fehler quasi auftritt und hier zwischen auch nochmal. Wir machen jetzt als Beispiel einfach mal einmal. Und zwar habe ich hier jetzt Commits 09 bis 17, 09 ist das älteste, 17 ist das aktuelle. Und wir gucken mit Git BISAC, prüfen wir, ob dieser Fehler in den Commit schon drin ist
05:41
oder nicht. Und da kann man mit Git BISAC starten machen und sagt direkt Git BISAC bad, weil wir wissen, das ist der schlechte Zustand und der schlechte Zustand ist halt eben schlecht. Und dann markieren wir das schon mal so, das ist der fehlerhafte Zustand. Wir geben aber gleichzeitig auch noch an,
06:01
dass der Commit, oder in der Regel ein Versionstag oder eine Commit ID, dass das gut ist. Das heißt, irgendwo dazwischen liegt der Fehler. Und was man jetzt halt machen kann, das ist eine Binärsuche. Das heißt, wir wollen jetzt gucken, ist das jetzt am Anfang und Ende wissen wir jetzt, ob was jetzt richtig und was falsch ist. Das heißt, wir gucken jetzt einfach
06:21
in die Mitte, also eine klassische Binärsuche, ob der Fehler da auftritt bzw. ob der Prozess in dem Fall langsamer ist oder nicht. Also in dem Fall prüfen wir Commit 13, es checkt automatisch dann den Commit in der Mitte aus. Weil wenn wir über 1000 Commits haben und man müsste da händisch gucken, welcher Commit ist denn da jetzt genau in der Mitte,
06:42
dann kann das ein bisschen dauern. Und ich hab das schon mal händisch gemacht, das will man nicht machen. Und da kann man eben gucken, ok, funktioniert das jetzt, funktioniert das nicht. In dem Fall sagen wir jetzt einfach, das funktioniert. Das heißt, wir wissen, der Fehler ist halt nicht dort und auch nicht dort hier zwischen aufgetreten. Das heißt, wir müssen jetzt nur noch
07:01
diese Commits angucken. Jetzt geht dann der nächste Schritt für die Binärsuche und da geht halt eben Commit 15. Da prüfen wir jetzt auch und wissen, gucken, ok, da hat es auch noch richtig funktioniert. Das heißt, entweder ist Commit 17 oder 16 der Fehler drin oder halt eben langsam. Und dann können wir halt recht schnell sehen, ja,
07:21
in Commit 16 ist da ein Fehler drin. Wir können den Commit anschauen und nachschauen, was jetzt das Problem ist. Wir müssen zwar immer noch verstehen, was da passiert. Und im Idealfall weiß man hoffentlich, wenn man Coach schreibt, was man da gerade tut. Weil, als ich mal das in der Praxis das Problem hatte, dann war da halt irgendwie den Commit, den ich dann gefunden habe
07:41
und das ganze händisch gemacht habe, dann stand da halt irgendwie drin Optimierung von blablabla und das war dann halt irgendwie eine tiefe C++ Funktion, was eigentlich eine Optimierung sein sollte, was aber im Gegensatz genau das Gegenteil halt eben war. Und mit einer Binärsuche hat man halt eben nur, in diesem Fall halt nur drei Schritte gebraucht und damit geht das eigentlich recht fix.
08:03
Was wichtig ist, ist, dass das Projekt letztendlich immer kompilierbar, testbar bzw. ausführbar sein muss. Weil, wenn dies nicht der Fall ist, dann hat man halt immer das Problem, ok, ich kann das jetzt gerade nicht kompilieren, muss ich nicht wieder ein Commit weitergehen. Ok, es funktioniert immer noch nicht, also gehe ich wieder einen Schritt weiter. Wenn man das zu oft machen muss,
08:22
dann kann das schon ganz schön nervig sein. Und was das Ganze ein bisschen vereinfacht ist, dass man das per Skript auch automatisieren kann, sodass man einfach einen Testcase schreibt oder so, der das Ganze prüft. Ok, wenn das Ganze länger als 100 Millisekunden braucht, dann mecke ich hier und markiere das automatisch
08:41
als Fehler oder als korrekten oder halt nicht korrekten, also als gut oder als Bad Commit. Wenn das irgendwie eine Restschnittstelle ist, dann geht das sogar noch ganz einfach, dann lässt man einfach drüber laufen innerhalb von ein paar Minuten. Wenn man das Projekt nicht groß kompilieren muss, dann ist das recht einfach erledig, man muss eigentlich nur warten, bis das Ergebnis rauskommt. Genau, deshalb noch ein paar Pro-Tipps.
09:03
Es hilft auch nur, wenn die Commits nachvollziehbar sind, weil es hilft nicht, wenn man dann den Commit zwar gefunden hat, da aber so eine Änderung drin ist, die man nicht durchblicken kann, und dann immer noch nicht weiß, wo liegt jetzt der Fehler. Dann hat man das vielleicht ein bisschen eingegrenzt, es hilft aber immer noch nicht. Deshalb mein allgemeiner
09:22
Tipp, immer kleine und überschaubare Commits machen, das ist nicht für Git bisect praktisch, sondern auch, wenn man es reviewt. Und bei Mergen ist es auch immer einfacher, wenn es immer kleine Commits sind, und der das viel besser mergen kann.
09:40
So. Das nächste ist Git add minus P. Wer nutzt das? Wer nutzt das täglich? Also ich muss mich aufmelden. Das finde ich, ich habe das hier immer immer in der Hand. Und zwar geht es eigentlich nur darum, dass das Ziel ist, wenn man eine Datei bearbeitet hat und man hat mehrere Änderungen
10:02
da drin, dann müssen nicht unbedingt alle Änderungen, die da drin sind, in einen Commit rein. Weil die eventuell halt logisch getrennt voneinander sind. Wie ich vorhin auch schon gesagt habe, möglichst logisch getrennte Commits zu machen, ist halt auch wichtig, dass man die Sachen innerhalb von einer Datei auswählt. So und wenn wir jetzt eine Datei nehmen,
10:22
und wir haben oben halt irgendwie was angepasst und unten noch was angepasst, was aber irgendwie zwei verschiedene Paar Schuhe sind, dann wenn man normales Git add und den Dateinamen angeht, dann fügt das ja komplett hinzu und dann hat man eben ein Commit. Das will ich aber in dem Fall nicht. Das nutze ich eigentlich ziemlich häufig, wenn ich
10:41
eine große Datei bearbeitet habe, gucke ich immer an, ok, welche Änderungen sind da drin, welche möchte ich in einem Commit drin haben und die, die gerade drin sind, die will ich erstmal, also die, die ich gerade hinzugefügt habe, die packe ich dann in einen Commit und dann mache ich das nächste weiter. Grund ist halt auch eben hier möglichst kleine überschaubare und logisch getrennte Commits zu haben, um eben eine nachvollziehbare
11:02
Logik so eben drin zu haben. So das Ganze nennt man, also ich habe es vor allem häppchenweise genannt, man spricht von Hangs, was direkte Übersetzung auf Deutsch, halt eben Stückchen oder Brückchen oder Brocken. So, und zwar wenn man geht add-p und dann den Dateinamen
11:21
angibt, dann zeigt er eben an, ok, will ich ja, übernehme ich diesen Abschnittsendung, er unterteilt das automatisch in die einzelnen Abschnitte, weil wenn du oben was geändert hast, unten was geändert hast, dann hat er automatisch zwei Hangs und man kann dann sagen, ok, das erste nehme ich jetzt hinzu. Wenn man dann geht Status einfügt, ausführt, dann steht direkt
11:41
drin, ok, die Datei wurde sowohl gestaged, ist im Staging Area drin, als auch, da sind noch veränderte Daten drinne. So, und hier Vollständigkeit halber habe ich das jetzt mal mit ausgeführt. Häufig hat man auch noch den Fall, dass man halt direkt welche untereinander hat, die auch getrennt werden soll. Kann man halt recht einfach S für Split ausführen und dann
12:01
sagt er direkt, dann trennt er das nochmal auf und versucht das soweit zu trennen. Das mache ich eigentlich ganz gerne, um es halt eben schön übersichtlich zu haben. Viele Leute sagen zu mir, du machst da für jede Zeile ein Commit, aber dafür kann man das auch lesen und nachvollziehen, was ich da gemacht habe und aus welchem Grund ich das eben gemacht habe. Und da kann man halt auch eben sagen, ok, ich nehme jetzt
12:21
das Stück nehme ich, das nächste nehme ich nicht und dann bin ich fertig und dann mache ich halt den Commit. Und dementsprechend sind hier noch die anderen Anforderungen, ja, alles der Datei nicht mehr oder nur das nächste nicht mehr und alles davor nicht mehr und sowas halt eben. Das muss man sich jetzt nicht im Detail jetzt gerade angucken. So,
12:40
geht Alias. Wer hat Alias definiert? Gut. Ich nutze, effektiv nutze ich Alias kaum, was auch ein bisschen damit zusammenhängt, dass ich den Leuten noch geht beibringe. Und dann ist das immer schwierig, wenn man seine eigenen Alias gesetzt hat und dann tippe ich das lieber aus. Finde ich immer trotzdem praktisch bei einigen Sachen
13:00
das umzusetzen, damit man zumindest weiß und das eben entsprechend nutzen kann. Und zwar prinzipiell ist das kein Hexenwerk halt eben. Man kann genauso einen Shell Alias setzen. Was man, was halt eben praktisch sind so lange Befehle. Lösung ist Alias setzen und das passiert dann in der
13:22
Konfigurationsdatei. Und wenn man jetzt zum Beispiel nicht immer Checkout eintippen will, da kann man auch CEO eintippen. Ich glaube in Subversion ist das, meine ich, so automatisch sogar schon drin. Und da kann man ja alias.co. Der Teil ist dann eben das, was im Alias steht und das halt eben der einzelne Begriff, der ersetzt wird. Hier stellt sich aber immer wieder
13:40
die Frage, welche wann setze ich einen Git Alias und wann setze ich einen Shell Alias? Weil theoretisch kann man das Ganze, was man hier mitmacht, auch als Shell Alias setzen. Da gibt es einfach die einfache Regel, wenn es mit Git zu tun hat, dann geht es um Git Alias und wenn es nicht mit Git zu tun hat, dann macht man
14:00
einen Shell Alias draus. Hier so mal als Beispiel, wo sich das halt eben mal praktisch sinnvoll sein kann, einen Alias zu setzen. Kennt jeder die Unterschiede zwischen den verschiedenen Stash-Sorten? Also was macht Git Stash im Standard?
14:29
Genau, also es speichert die Änderung von die geänderten Dateien, die schon im Repository drin sind, die schon getrackt sind, die schiebt ihr dann halt eben in ein extra Stack und die kann man dann halt wieder rausholen.
14:40
So, was man aber halt eben machen kann, ist, wenn man den Index behalten möchte, dann kann man das zum Beispiel auch noch machen. Oder halt eben, wenn man Dateien hat, die noch nicht getrackt wurden, dann kann man die eben mit so einen langen Parameter ebenfalls hinzufügen. Oder wenn man sogar Dateien hat, die ignoriert werden durch die Git-Ignore-Dateien, dann kann man ja halt eben minus minus all angeben,
15:00
um wirklich alles in ein Stash zu packen. Und das Ganze zu merken, ist halt auch irgendwie ätzend und deshalb kann man auch so schön Stash und Stash machen, um eben dann nicht so viel tippen zu müssen. Um dann halt eben sinnvolle Alias zu nutzen, um ich kann mir das nie merken, wenn man das nicht täglich nutzt oder gerade braucht.
15:22
So, ein anderes Beispiel ist zum Beispiel, wenn man ein Kommando nutzen will, um hinten noch was anzufügen. Was man zum Beispiel machen kann, ist, also wenn man jetzt ein Softwareprojekt arbeitet, hat man in der Regel halt eben Commits, wo die Ticket-ID mit in der Commit-Message drin steht.
15:44
Ich hoffe, ihr macht das alle. Also zumindest ist das ganz sinnvoll. In Softwareprojekten, bei einigen Projekten macht es natürlich keinen Sinn. Das mache ich dann auch nicht immer, weil ich ja auch nicht für alles ein Ticket habe. Da kann man jetzt zum Beispiel, wenn man jetzt einen Befehl, einen Git-Block Befehl, Git-Block minus minus Purity One-Line, da gibt halt alle Commits
16:01
in einer Linie aus. Also eben One-Line, wie es das sagt, und gleichzeitig zum Grappen. Dann kann ich die Commit-Messages grappen und kann dann halt eben gucken, welche, kann dann halt eben den Suchbegriff eingeben. Man will aber diesen ganzen Befehl ja auch nicht immer eintippen. Dementsprechend kann man auch wieder Lock-Grappen machen.
16:21
Und dann macht er die, das ganze Konstrukt, was man dahinter ist, kann man dann halt eben vereinfachen und den Befehl, der dahinter steht, der wird dann eben angehangen. Ist eigentlich relativ simpel. Genau. Wir bleiben ein bisschen beim Lock. genau. Und aus dem Lock kann man eigentlich ganz viele Sachen rausholen.
16:43
was ich manchmal recht toll finde, ist, wenn ich dann nur gucken will, wenn ich eine Woche im Urlaub war, was ist in der Woche passiert? Oder halt eben so, das erste ist eigentlich relativ simpel. Minus drei, da zeige ich mir nur die letzten drei Commits. Manchmal will man nicht eben das ganze Ding haben, sondern eben nur die letzten paar Commits.
17:00
Dann kann man eben minus drei angeben. Man muss dann nicht so ganz viel hinterher tippen. Was halt auch praktisch ist, wenn man halt irgendwie im Urlaub war und gucken will, was ist jetzt auf diesem Branch passiert. SINs, Datum oder halt eben, also entweder Absolut oder Relativ. Man kann auch After und ganz viele so bestimmte Zeitabspannen angeben oder auch eben zusätzlich
17:20
angeben, wer hat das committed. Theoretisch kann das euer Chef also auch machen, wenn der Chef im Urlaub ist und er euch fragt, was ihr gemacht habt, könnt ihr schon eintippen und sagen, hier das habe ich gemacht, an diesen Tickets habe ich gearbeitet oder diese Commits habe ich gemacht. Gleichzeitig kann er es natürlich euch auch überprüfen. Und wo ich dann manchmal geguckt habe, was ist jetzt in diesem Projekt eigentlich passiert in den letzten
17:40
sechs Monaten. Und dann ich feststelle, okay, da ist jetzt irgendwie drei Commits drin gewesen im halben Jahr. Und eigentlich sollte da mehr passieren, wenn das irgendwie das zweitwichtigste Produkt der Firma ist oder sowas als Beispiel. Dann ist das manchmal ein bisschen doof, wenn man sich dann fragt, was ist denn jetzt hier?
18:00
Git diff, das nächste. Kennt ihr jemand Word diff? Zwei Leute, gut. Da lernt ihr heute. Und zwar gibt es ja ein normales Git diff, das zeigt da eigentlich nur einen Unterschied zwischen zwei Zeilen an. Einmal rot angezeigt, welche Zeile gerade gelöscht wurde quasi und welche neu hinzugekommen
18:22
wurde. Das ist bei ganz langen Zeilen, wo eventuell sogar mehrere Wörter herausgenommen wurden sind, manchmal doch relativ ätzend. Dafür gibt es dann Word diff. Das ist auch praktisch, wenn man Texte versioniert. Das mache ich auch ganz gerne. Und dann zeigt das hier innerhalb von einer Zeile direkt die Änderung an,
18:41
die man gemacht hat. Das ist jetzt nur zufällig ein Befehl, weil das hatte ich in den Folien, die ich eben hier vorhin gemacht habe, hatte ich einen Fehler gesehen. Statt One-Line habe ich online geschrieben. Das ist natürlich falsch. Und der hat dann halt hier Minus im Minus. Das heißt, das hier ist gelöscht und das hier ist hinzugefügt worden.
19:01
Hier fehlt jetzt noch die farbliche Unterlegung in Rot und Grün. Aber ich denke, das sollte dann ersichtlich sein. Und so sieht man dann deutlich besser, welche Änderungen jetzt in der Zeile nur gemacht worden sind.
19:32
An da geschaltet haben.
20:03
Es soll zum Starten den Knopf drücken. Bitte warten Sie, das System wird hochgefahren.
20:34
Internet of Things?
20:43
Kronjob? Oder Server Cloud? Nee, das kann ich nicht. Wie geht das?
21:20
Nach der kurzen Rechnung können wir dann ja jetzt weitermachen. Der informierte Techniker, genau. Jetzt muss ich mich erstmal wieder sammeln. Genau. GitGrep. Und zwar, Grep kennt wahrscheinlich jeder, hoffe ich.
21:41
Man kann das auch in Kombination mit Git nutzen. Damit man nicht nur, mit Grep kann man ja einfach nur die aktuelle Version, die gerade im Dateibaum gerade auf der Platte liegt, durchsuchen. Mit GitGrep kann man aber auch alte Versionen durchsuchen. Was halt relativ praktisch ist. Ich habe jetzt einfach mal hier einen BodyTag in der Datei gesucht und kann jetzt explizit gucken,
22:01
wo war das zu einer bestimmten ID, zu einem bestimmten Commit. Hier habe ich jetzt einfach Het1 gemacht. Also im vorletzten Commit. Man kann jetzt auch irgendwelche Branches oder andere Commits angeben. Und er zeichnet dann direkt an, in welcher Datei das war. Weil, was ich einmal das Problem hatte, ich hatte irgendeine Änderung gemacht. Ich wusste, wie die Zeile aussieht. Ich wusste aber nicht, in welcher Datei, die zu dem
22:21
Zeitpunkt damals drin war. Und ich musste also den alten Stand zurückholen. Und damit geht das eigentlich ganz einfach. Und man kann jetzt, das müsste ich jetzt nochmal ausprobieren, glaube ich. Damit Punkt Punkt, kann man ja noch zwei Commits angeben. Damit er zwischen diesen Commits halt eben sucht und die Ausgabe macht.
22:41
Was aber ein bisschen schöner ist teilweise halt noch, wenn man mit git log minus großes g dann nochmal sucht. Dann zeigt er explizit die Commits an, wo diese Zeile, wo der Suchbegriff drin ist, ersetzt wurde. Oder eingesetzt wurde. Oder explizit verändert wurde. Weil wenn man explizit eine Funktion hat, wo man dann weiß, ok, da oder eine Zeile hat.
23:02
Und dann wissen wir, wann wurde die eingeführt. Und welche Änderungen wurden genau an dieser Zeile halt eben gemacht. Dann findet man ganz schnell die entsprechenden Commits raus und muss da gar nicht mehr so viel dran machen. So, interaktives Rebase. Das ist für mich eigentlich schon fast täglich. Ich weiß nicht, wie es bei euch aussieht.
23:21
Wer kennt interaktives Rebase nicht? Ja, die eine Hälfte kennst, die andere nicht. Interaktives Rebase ist eine Art des Rebases. Der normale Rebase, ich gehe jetzt einfach mal an. So, weiß jeder, was ein normaler Rebase ist? Gut.
23:41
Und mit einem interaktiven Rebase kann man viele verschiedene Aktionen kombinieren, um die letzten Commits, die in dem Repository oder auf dem Branche gerade drauf sind, zu verändern. Und zum Beispiel die Commit-Reihenfolge verändern, Commit-Messages verändern, Commits zusammenfügen und so weiter. Das zeige ich dann gleich.
24:02
Dabei schreibt man aber die Historie neu. Dementsprechend haben wir neue Commits, die wieder drin sind. Mit getreebase-i und head tilde 2 kann man dann zum Beispiel auswählen, ich nehme die letzten zwei Commits. Dann öffnet sich ein Editor und das Ganze sieht dann so aus, dass hier vorne ein Keyword drin steht, die Commit ID.
24:21
Und dahinter dann eben die Commit-Message. Und das Keyword da vorne ist dementsprechend wichtig, was man da reinsetzt. Weil es gibt dementsprechend ein paar Keywords, die man da einsetzen kann. Und PIC ist ganz einfach. Wir nehmen den Commit so, wie er da drin ist. Das heißt, hätte ich den Editor an der Stelle einfach wieder geschlossen,
24:41
dann wäre nichts passiert, weil er die gleichen Commits einfach wieder verwendet. Die haben wir keine Änderungen gemacht. Und beim Reward ist es auch eigentlich relativ simpel. Commit-Beschreibung anpassen, also die Commit-Message anpassen und kommt eben wieder ein Editor auf und man kann eben eintippen, was man da verändert hat. Was ich aber häufig auch mache,
25:02
ist ein Edit. Weil ich dann weiß, ich habe jetzt diverse Sachen gemacht, aber an einem Commit vor fünf Commits habe ich eine bestimmte Impfabfrage irgendwas vergessen und weiß, das muss explizit da rein und es macht keinen Sinn, einen zweiten Commit zu machen, der wiederum den alten Commit fixt. Also kann ich auch Edit
25:21
angeben an den entsprechenden Commit und eben sagen, okay, dann möchte ich diesen Commit eben nachbessern. Was dann halt eben passiert ist, der geht dann wieder die alte Historie zurück, die Commits, die man sich angeklickt hat oder ausgewählt hat, bleibt dann an der Stelle stehen. Man hat die Möglichkeit, diesen Commit nachher zu bearbeiten
25:42
und dann kann man eben das Rebasing fortsetzen und die anderen Commits werden ja wieder draufgesetzt. Was auch toll ist, ist Squash und Fixup. Und zwar, da werden dann einfach Commits wieder zusammengeführt. Weil manchmal kennt ihr vielleicht auch irgendwelche Commits gemacht, weil man irgendwas auf irgendeinem Testsystem testen muss und macht so oft Commits, bis das auf ein Testsystem, das
26:01
automatisch aussteckt und das Ganze testet, das eben macht und dann hat man irgendwie Fixtest eins, zwei, drei, vier, fünf, sechs, manchmal ganz viele Commits und am Ende hat man eben das fertige Ding und dann kann man einfach sagen, okay, ich packe jetzt einfach mal die sechs Commits alle zusammen oder entferne halt eben ein paar Commits, geht dann auch mit Drop. Und
26:22
was man halt eben aufpassen muss bei dem Ganzen ist, man kann ganz schnell die Git-Historie kaputt machen und zwar oder also kaputt machen, sage ich jetzt mal, weil wenn man aus Versehen eine Zeile löscht oder halt eben Drop eintippt, dann wird der Commit einfach rausgeschmissen. ich weiß nicht, ich hatte eure Kollegen irgendwann mal so gesagt,
26:42
oh, irgendwie der Commit ist verloren gegangen. Und... die Historie habe ich neu geschrieben, dementsprechend sollte man das nur auf Feature-Branches machen, auf denen
27:01
entweder man selbst arbeitet oder wo klar ist, dass nur eine Person dran arbeitet, dementsprechend wird auch ein Force-Push benötigt, um das auf einen Server zu schieben. Und da muss man auch einige sagen, man sollte das nur machen, wenn es ein Branche ist, den man nicht veröffentlicht hat, das ist halt eine gute Daumenregel, wenn man es noch nicht veröffentlicht hat, irgendwo so hingepusht hat. Also völlig egal, dann liegt es
27:21
halt nur auf einen selbst, aber wenn klar ist, dass das eh nur in das eigene Repository ist und kein anderer da reinschreiben darf, dann kann man das ja auch pushen. Und da muss man darauf aufpassen. Genau. Getreflog, wer kennt Getreflog? Auch ein paar.
27:41
Genau, das ist das Medikament gegen, ich habe ja nichts getan, weil ständig Leute mir dann sagen, irgendwas funktioniert hier nicht, ich habe nichts getan, alles ist kaputt, ich weiß nicht, was ich tun soll, bitte hilf mir. Dann sage ich immer, gib mal eben Getreflog ein und zeige mir das, was da drin steht, weil da steht ganz genau drin,
28:01
was die Person gemacht hat. Und so kann man ganz schnell nachvollziehen, was man eben gemacht hat. Das hat eben das Problem, irgendwie zum Beispiel ein interaktives Rebase gemacht, man hat die Kometzwecke verloren, aus Versehen, man will sie wiederholen und die Person hat es aber überhaupt nicht gemerkt, was er da gemacht hat. Und das dritte Problem
28:21
ist, dass der, der dann supporten muss, also ich zum Beispiel, dann auch nicht weiß, was der Typ gemacht hat, weil ich saß ja nicht die ganze Zeit drüber und habe so über den Bildschirm geguckt. Da hilft halt eben Getreflog, weil da eben alles drin steht. Also eben Checkout, welche Branche wurde erzeugt oder gewechselt, welche Kometzungen gemacht, wann wurde gepusht, wann wurde gepult, wann wurde ein Rebase gemacht. Theoretisch eigentlich alles.
28:41
Aber es ist eben nur lokal. Dementsprechend kann man jetzt nicht gucken, was hat jetzt die Person da vorne gemacht in dem Git Repository, weil das ist eben komplett lokal. Und wenn man das Repository löscht und nochmal neuklont, dann ist die ganze Historie davon auch weg. Dementsprechend, das sieht dann zum Beispiel so aus, hier sieht man den Z und die Anzahl
29:01
und noch eine Zahl dahinter. Und da sieht man halt sofort, an welchem Stand das war. Das ist jetzt von irgendeinem echten Repository quasi. Hier wurde ein Checkout gemacht, hier wurde ein Komet gemacht, noch ein Checkout, Pull, noch ein Checkout, ein Rebase und noch ein Rebase. Man sieht dann sofort, was hat die Person gemacht, oder was hat man
29:21
selbst gemacht, wenn man gar nicht mehr sicher ist, in welcher Reihenfolge man irgendwas gemacht hat. Und das ist durchaus schon hilfreich. So. Git hat auch ne Garbage Collection. Und das ist jetzt nur so, das braucht man jetzt nicht unbedingt zu wissen, aber man sollte wissen, was es ist, dass es da ist
29:41
und was es bewirkt. Und zwar, wenn man ganz oft ein interaktives Rebase zum Beispiel macht, dann macht er jedes Mal neue Commits. Und die Commits, die schon im Repository drin sind, die sind ja dann nicht mehr verlinkt, weil die Alten, die werden dann einfach weg zur Seite geschoben quasi, liegen dann noch im Dateisystem irgendwo rum. Aber die sind halt unerreichbar.
30:01
Man hat dann sogenannte Dangling Commits, die dann halt da irgendwo rumschweben, aber halt nirgendwo verlinkt sind, weil die Git-Historie ist da letztendlich auch nur eine Kette von Commits, die miteinander verkettet sind. Wenn man sich einen Commit anguckt, dann ist halt eben der Vorgänger-Commit verlinkt und das zieht sich dann dooweit durch.
30:21
Wenn man ganz oft ein Rebase macht, dann kann das manchmal schon ein Schweicherplatzverschwendung sein, weil man dann ganz viele Dateien und Änderungen drin hat im Repository, die man gar nicht mehr erreichen kann oder die man gar nicht mehr braucht. Und wenn man einmal GC aufruft, dann löscht er das Ganze irgendwie weg. Und dann hat man teilweise halt auch schon deutlich
30:42
Platz gespart. Was nur im Standard halt eben gemacht wird, ist, dass es halt irgendwie, ich glaube, die letzten zwei Wochen behält und alles, was älter ist, wird dann weggeschmissen, sodass die ganz alten Sachen weg sind. Und dementsprechend, falls jemand einen Commit droppt, der Commit ist noch
31:00
da, nur nicht mehr referenziert. Das heißt, ich könnte den noch rausholen, da gibt es auch nochmal extra Befehle für Garbage-Collegen droppt regelmäßig auf. So. Was das auch noch macht, ist, das komprimiert nochmal zusätzlich, entfernt eben die unerreichten Objekte, die im Repository drin sind. Und eben als Option kann man dann zusätzlich
31:20
angeben alles auf einen bestimmten Datum. Dadurch ist das sowohl ein bisschen schneller, als auch gibt es eine Speicherplatzoptimierung. So. Git Blame ist eigentlich mein Lieblings, kennt wahrscheinlich die meisten. Wer kennt es nicht? Ja, ein paar kennen es nicht. Gut. Ich habe extra eingeschränkt, ich war das nicht, ich war das nicht.
31:41
Achso, doch, das war ich. Und zwar, wenn man sich eine Zeile Code anguckt und dann sich fragt, wer hat diese Zeile verbrochen? Das denke ich auch oft. Manchmal auch zu oft. Dann gucke ich nach, wer war das? Und stille fest, Scheiße, ich war das. Und zwar, irgendwie ein Problem, Feature funktioniert nicht, dann sieht man,
32:02
konnte ja irgendwie nie funktionieren. Wenn man Git Blame und dann die Datei angibt, welche man sich angucken will, dann gibt es solche Zeile für Zeile, wer hat das geredet, wann wurde das geredet, warum? Also Commit Message kann man nachgucken und womit hängt das zusammen? Das war gerade mehr so ein Witz, wer ist schuldiger oder so, aber häufig fragt man sich dann, warum hat man gerade diese Änderung gemacht
32:21
zu dem Zeitpunkt? Weil ich habe die Änderung zum Beispiel selbst gemacht und will wissen, warum habe ich die gemacht? Oder warum habe ich das so kommunistisch beübtet? Weil dann habe ich dann häufiger noch andere Fehler gesehen, okay, da habe ich einen Denkfehler drin, da soll ich an einer anderen Stelle auch nochmal prüfen, weil da habe ich das, glaube ich, auch nochmal gemacht. Deshalb ist es durchaus sinnvoll, dann manchmal nachzugucken, was man da gemacht hat und warum man das eben
32:41
gemacht hat. Weshalb auch wieder wichtig ist, ordentliche Commit Messages zu setzen, um dann nachzuvollziehen, was da gut ist und was nicht oder warum man das gemacht hat. Genau, Commit ID, Autor, Datum, Urzeit, Zeil, Nummer, Zeilinhalt. Häufig hälst du einfach mal zu gucken, wie alt ist eigentlich diese Zeile? In welcher Version ist die
33:01
quasi noch drin? Und wenn man sagt, oh, die ist schon 6 Jahre alt, dann weiß man, okay, das ist schon lange da drin. Und da ist es manchmal einfacher, als ganz alte Versionen rauszukraben. Genau, GitFilterWant ist das nächste. Wird das schon mal genutzt? Na, doch ein paar. Genau, mit GitFilterWant wird auch die Historie neu geschrieben.
33:21
Aber anders als das bei einem interaktiven Rebase der Fall ist. Und zwar ist es immer dann sinnvoll, wenn man etwa Zugangsdaten in einem Quellcode drin hat. Also irgendwie einen Skript hat, wo irgendwie Zugangspasswort zu irgendein Server oder sonst was drin steht. Dann will man die eigentlich raushaben. Die sollten auch nicht in einem öffentlichen Repository sein. Oder auch nicht firm intern das Repository.
33:44
das Problem ist, wenn man das nur einmal in einer aktuellen Datei entfernt, dann ist es immer noch in den alten Revisionen drin. Die Revisionen sind da nicht plötzlich weg. Und davon muss man wieder um eine komplette Historie neu schreiben. Und dafür hat FilterWant diverse Filter, die man nutzen kann, um diverse Sachen
34:00
wieder zu verändern. Das einfachste ist quasi ein TreeFilter. Das checkt dann halt jeden Commit aus und führt dann einen Befehl aus. Das kann dann zum Beispiel ein Seht sein, um eine Zeichenersetzung durchzuführen. Oder eben eine Datei komplett zu löschen.
34:21
Und der Rest wird aber komplett beibehalten. Sodass man dann wirklich die komplette Historie hat von dem einen Skript, was man da irgendwo liegen hat, wo das Passwort drin ist. Aber nur das Passwort dann halt ersetzt wurde durch XXXX oder sowas. Dann gibt es halt, da gibt es noch einige mehr. Ich habe jetzt noch so ein paar aufgelistet. Indexfilter, was dann halt nicht den ganzen Baum auscheckt.
34:42
Und wie lange habe ich noch mal Zeit? Bis Viertel vor, ne? Bitte? Na gut. Ja, ich bin da schon weit. Genau, und was man jetzt auch noch machen kann, ist ein Sub-Directory-Filter. Weil manchmal hat man noch irgendwie den Fall,
35:01
dass man ein Unterverzeichnis eventuell in ein komplett eigenes Repository auslagern will, weil es plötzlich eine Laibuie geworden ist, was man gar nicht vorher gedacht hatte. Da kann man dann die ganze Historie von dem Unterverzeichnis unabhängig vom Rest das Repository eben extraieren und dann in ein extra Repository schieben. Kann manchen sinnvoll sein, um eben die Historie
35:21
dabei zu behalten, aber trotzdem Teile des Repositories, sei es Dateien oder eben Ordner aus dem Repository eben rauszuholen. Da gibt es noch einige mehr Filter. Ich habe es letztendlich selbst nie direkt gebraucht. Mal manchmal Hinweise gegeben an Leuten, die das brauchen. Wichtig ist dann nur, die komplette Historie wird neu geschrieben.
35:41
Und das sollte man dementsprechend nie auf öffentlichen Repositories ausführen. Das hatte ich auch mal von einem Kollegen gehört, der sich dann jedes Mal über das eigene Software-Projekt aufregt. Und dann sagt er so, oh, die haben schon wieder alles kaputt gemacht, weil wenn die dann eben GitPool machen und dann haben die das ganze Repository gefilterbornscht, sage ich das jetzt mal,
36:02
dann ist das ein bisschen ätzend, weil das jedes Mal komplett neu klonen muss und weil die komplette Historie eben neu ist. Wenn man das jetzt intern macht, dann muss man dementsprechend mit den Arbeitsmitarbeitern kommunizieren. Das ist halt häufig der Fall. Wer hat eigentlich Binärdateien, also große Binärdateien, die sogar häufig aktualisiert werden,
36:21
im Repository drin? Da lacht schon einer. Ja. Und da ist es manchmal dann sinnvoll, die Binärdateien irgendwie rauszuholen aus dem eigentlichen Repository und irgendwie anders auszulagern und dann die ganzen Revisionen rauszuschieben. Und da gibt es zum Beispiel noch so ein Tool BFG Epo Cleaner.
36:42
Das ist dann ein bisschen benutzerfreundlicher, also ein bisschen einfacher, ist halt nicht ganz so mächtig wie ein Filter-Branch. Aber da kann man zum Beispiel sagen, lösche mir alle Dateien raus, die größer sind als 10 MB. Das ist in dem Fall ein Java-Tool. Und wenn man das mal braucht, kann man das mal machen. Und ist halt ein bisschen einfacher als der Rest.
37:00
So. Nutz das jemand. Das ist noch relativ, einer. Immerhin. Wer hat das schon mal, wer musste schon mal an mehreren Branches gleichzeitig arbeiten? Lass mich raten. Ich hab dann einfach das Repository nochmal geklont und darin dann in eigenen Branches gearbeitet.
37:24
Ja, gut. Manchmal, ich mach das meistens auch mit Stash. Was halt eben einfacher ist, was man halt eben auch machen kann. Das ist ein Worktree machen. Wo dann aus dem eigentlichen Repository dann halt eben ein zweites Arbeitsverzeichnis rausmacht. Wo man dann eintragen kann, wo man dann halt die eigene Änderung macht.
37:41
Das Problem beim Stashing ist dann ja auch wiederum, wenn man dann, also bei mir war das dann teilweise so, ich muss dann ein Projekt kompilieren, das dauert dann halt irgendwie eine halbe Stunde. Ich wollte gleichzeitig in einer anderen Branche noch eine Änderung machen. Und währenddessen konnte ich dann, da musste ich halt einen neuen Worktree machen und konnte das halt nicht stashen, weil er gleichzeitig auf dem Datein das Arbeitsverzeichnis geschrieben hat.
38:02
Genau, dementsprechend kann man mit Worktree mehrere Arbeitsverzeichnisse zu einem Repository machen. Und das ist die mögliche, also eine mögliche Lösung ist halt eben das Repository mehrfach zu klonen. Was halt aber eben ätzend ist, weil wenn man mehrere Remote Repositories hat, die man hinzufügen muss, dann muss man die jeden machen und jedes Mal noch mal die einzelnen Konfigurationen machen, je nachdem wie aufwendig
38:21
das Projekt ist und das kann ganz schön nervig sein. Und geht Worktree prinzipiell relativ neu, ich glaube, das ist noch gar nicht so alt, dementsprechend ich kenne das noch gar nicht so viele. Ich gehe jetzt nicht auf die genauen Befehle ein. Aber damit kann man halt eben einen Arbeitsverzeichnis noch mal zusätzlich an einem anderen Ort
38:41
hinschieben, um das eben, um darin weiter zu arbeiten. Dann muss man halt eben nicht die ganzen Einstellungen machen. So. Nee, einfach in einem höheren, also daneben quasi. Wenn du jetzt ein Repository hast, ABC, also ich habe zum Beispiel mein
39:00
Home Directory in den Repositories-Orden und darunter liegen dann alle Repositories und dann habe ich halt die nebeneinander liegen. Und man kann sich dann auch eben ausgeben lassen im Repository, wie viele Worktrees hat man? Welche, was, wie bedennt man, welche Warrantie ist da drin? Bitte?
39:21
Wahrscheinlich irgendwie so, also prinzipiell ist das nichts Kompliziertes, ja? Genau. Du brauchst prinzipiell, also im Standard hast du ja immer das Repository mit einem Punkt Gitverzeichnis da drin. Theoretisch kann das ja ganz woanders liegen. Und so kann man damit dann halt auch eben arbeiten.
39:41
So, was auch noch möglich ist, ist Binaire-Dateien, ein Diff von Binaire-Dateien zu machen. Und prinzipiell Binaire-Dateien gehören eigentlich nicht in einem Repository. Mancher macht das schon Sinn, weil in einem Git-Repository eben das Problem, die ganze Datei wird jedes Mal
40:01
in das Repository, wenn es aktualisiert wird, reingeschoben. Dementsprechend, wenn man das bei einer 1MB Binär-Datei halt eben 100 Mal macht, dann ist es halt mal eben 100 MB. Und wenn man das ganz oft macht, dann eben deutlich mehr. Was man aber trotzdem machen kann, ist ein Diff von Binaire-Dateien.
40:22
Und was da aber wichtig ist, ist, dass man davon aber dann, dass der Text, oder dass da eben ein Text drin ist, den man dann diffen kann, oder auch ein Bild. Das geht theoretisch auch. Man kann nämlich in Git sagen, für diese Datei-Endung möchte ich jetzt folgendes Diff-Programm nutzen, beziehungsweise folgende Extraktion zu nutzen, um dann
40:40
daraus die Ausgabe zu erzeugen. Und zwar kann man, was ich zum Beispiel gemacht habe, ist, ich hatte LibreOffice-Dokumente, also ODT-Dokumente, die ich in einem Git-Repository hatte. Und die wollte ich trotzdem versionieren. Die wollte ich versionieren, wollte trotzdem ein Diff haben. Weil eigentlich hat man ja so ein ganz schönes Diff. Und in vielen Linux-Distributionen ist ODT to Text
41:02
drinne. Theoretisch gibt es das auch für DocX und Konsorten. Und das zeigt dann in der Kommando-Zeile eben auch an, welcher Text da drin ist und was man da verändert hat.
41:32
Also die Frage war, dass Subversion auch diverse Paket, also gesippte Sachen extragerieren kann und automatisch
41:41
einen Diff macht. Ich habe keine Ahnung. Also ich weiß, dass man eben diverse Tools mit einklinken kann. Und um die eben das durchzuführen, wie ODT to Text oder PDF to Text geht wohl auch. Das habe ich jetzt nie selbst gebraucht. Das habe ich nie ausprobiert. Aber damit geht das prinzipiell.
42:01
Man kann auch SIP-Dateien auch entpacken und daraus dann irgendwie, hatte ich auch ein Beispiel gesehen, aber da fehlt mir so der Praxisbezug zu, warum man das jetzt unbedingt machen sollten, müsste. Genau. Und das müsste man dann halt eben Git Attributes und Git Config konfigurieren, damit die Dateiänderung entsprechend beachtet wird. Was auch manchmal
42:20
praktisch ist, Dateien, die zwar Textdateien sind, aber als Binärdateien behandelt werden sollten, explizit als Binärdatei zu klassifizieren. Weil ich hatte das bei irgendeiner Anwendung. Ich weiß gerade gar nicht welches, hatte irgendwie so ein XML-Format ausgegeben. Und das wollte ich halt versionieren, aber mir bringt das Diff nichts, wenn da halt so ganz
42:41
kryptisches XML drin ist. Dann habe ich halt explizit angegeben, okay, das ist jetzt eine Binärdatei und steht dann einfach nur drin, okay, das ist jetzt eine Binärdatei, weil dann ist es einfacher, wenn man irgendwas mercht und dann hat man nicht plötzlich Merch-Konflikte in irgendwelchen XML-Dateien, die unlesbar sind. Das kann man halt umgekehrt halt auch eben machen.
43:02
Ja, also bei JavaScript-Kompilierten Sachen zum Beispiel, ja, zum Beispiel. Wobei die will man ja eigentlich auch nicht im Repository haben. Theoretisch will man die nicht im Repository haben. Genau. Die schöne Theoriesache. Genau. Was es auch noch gibt, es geht Attributes, also die Dateipunkt geht Attributes,
43:21
wo man Attribute zu einer Repository setzen kann. Da gibt es ganz viel. Ich habe jetzt erstmal nur ein paar Beispiele drin. Und zwar dass diverse Dateien anders behandelt werden soll. Das war auch das, was ich gerade erwähnt habe, dass eben diverse Dateien als Binärdatei
43:40
behandelt werden sollten. Was auch praktisch ist, wäre schon mal auf das Problem gestoßen, wenn ihr mit Windows-Leuten... Es kommt so gar nicht den Satz zu Ende, natürlich. Ich hatte gerade ein Uniprojekt, wo dann jeder seine eigene Zeilenänderung reingeschoben hat und auch überhaupt nicht mal in das Dip reingeguckt hat.
44:02
Und dann war da so ein schöner Mix aus Carriage, Linefeed und Linefeed, was halt total unbrauchbar war. Vom Rest des Projektes mal abgesehen. Ja, ich will jetzt nicht mit Tabs und Spaces und... Das ist ja noch so, wenn man sich dann das Dip anguckt und der Code dann so ist.
44:22
Nee, und dann kann man eben im Repository angeben, dass er dann eben die Umformung automatisch machen soll, wenn man das eben outcheckt oder halt eben in das Repository. Nachdem ich das gemacht habe, war das deutlich angenehmer für mich. Da konnte ich eigentlich nicht mehr ganz so schlimm, aber immer noch schlimm.
44:41
Und das kann man halt eben zum Beispiel in den Git Attributes Sachen machen. So, ich bin jetzt prinzipiell durch. Jetzt würde ich gerne an euch fragen, welche Git Funktion ihr gerne nutzt, die eventuell nicht so bekannt sind, aber trotzdem sinnvoll ist zu wissen. Ich hoffe, da kommt jetzt was. Ja.
45:13
Wie von Diff2 styles? Kennt ihr den Unterschied zwischen Diff2 und Diff3? Diff2 ist das Standard, das zeigt an, das ist
45:20
hier und das war vorher. Die eine Richtung hat das gemacht. Die andere Richtung hat das gemacht. Und Diff3 zeigt in der Mitte auch den gemeinsamen Nenner an. Also woher kommen denn beide? Sprechen wir, der eine hatte Attribute in der Funktion hinzugefügt, der andere auch. Dann würde ich vielleicht auch ein bisschen was fahren an vorher. Und das
45:40
kann man über die Git Konfig einstellen. Ja. Also das war jetzt ein Beispiel für die Aufzeichnung halt eben, dass man Diff3 war, dass jetzt Diff3 als Merge Tool verwenden kann, um eben sinnvoller nachzuvollziehen. Oder so. Ja.
46:00
Muss ich dann nochmal nachgucken. Nächster. Genau, das ist sowas Standard. Also eigentlich ist ein Git Pull immer doof, vor allem im Standard. Bei Git Pull macht halt Git Fetch und dann Git Merge. Da hast du immer so ganz viele Merge-Konflikte. Nicht Merge-Konflikte, da hat man vielleicht
46:21
auch, aber hat man ganz viele Merge-Commits, die man überhaupt nicht braucht. Und mit Riebe ist es halt viel schöner, wenn dann einfach die neuesten Commits, die dann drauf sind, oben draufpackt und dann eben nicht diese ganzen Merge-Commits drin sind. Das ist auch unfassbar schwer, Studenten beizubringen. Ja. ...
46:43
... ... ... ... ... ... Ja. Also du meinst jetzt, dass man Merge machen kann, um
47:02
gleichzeitig squaschen. Ja. Also das mag ich halt eben nicht, weil du dann eben nicht mehr so nachvollziehen kannst. Also ich persönlich mag das halt eben nicht. Das kann man halt eben machen. Merge und Squash sofort, aber man verliert halt die ganze Historie, die dazwischen ist.
47:23
Ja, aber hinterher hat man 2000 Branches, weil jeder einen Feature-Branch macht. Also das kann man machen. Finde ich nicht so toll. Ja.
47:41
Ja, also wenn es kleine Sachen sind, kann man das natürlich machen. Vor allem wenn man allein arbeitet oder sowas. Also wenn ich jetzt eh mit Code-Review arbeiten muss und das dann halt eben wieder zusammenfügen muss und das also eh alles eine abgeschlossene Einheit ist, dann squasche ich das einfach in den Branchen noch selbst und lasse das dann Mergen.
48:00
So, hier vorne war noch was. Ja. Kann man machen, ja. Also Hux hatte ich jetzt hier gar nicht drinnen. Habe ich sonst glaube ich auch häufig drin. Um eben, was man auch schon machen kann, ist ich meine, Hux gibt es sowohl
48:21
kleinseitig als auch serverseitig, um eben das ganze eben, also die Aussage halt eben zu kompilieren und zu testen auszuführen. Je nachdem wie man die Commits macht, ist das manchmal doch praktisch, um eben zu gucken. Wenn es kleine Projekte sind, wenn es zu lange dauert, ist das glaube ich auch zu ätzend. Und gleichzeitig aber im Standard ist da meine ich ja schon ein Commit-Hook drin, der nicht aktiviert
48:42
ist, dass dann Spaces oder Taps am Zeilenende halt eben angemerkt werden, also Trailing, White Spaces, angemerkt werden, dass man die wieder entfernen kann, bevor man die überhaupt committet. Ja. Und zwar habe ich noch eine gemeine Frage. Ja. Ob Sie vielleicht ein best practice
49:02
für die Mitnachrichten haben? Also wir haben zum Beispiel die Antwortungen, es sollte zuerst zustimmen, was ist der Feature, man kriegt von einer allgemeinen Änderung, dann was man getan hat, und dann eine Referenz zu den Tickets. Ja. Und wir haben dem Fall, dass einfach alle Tickets mitbekommen, oder
49:21
einfach nur bei Karten. Ja. Und das in 20 Commits. Ja. Also die Frage, das war ja meine Frage, best practice ist für Commit-Messages, weil da eben halt viele Leute nicht ordentlich hinschreiben, was da genau hingehört. Was ich für meinen Team, wo ich damals drin war, eingeführt hatte, ist, bzw. wo wie es vorher war, ist, jeder hat nach
49:42
dem Master gepusht, und dann wurde nur Implementierung, Ticketnummer hingeschrieben, oder Implementierung plus Test, Ticketnummer. Und das war dann insbesondere dann lustig, wenn dann ein Tippfehler bei der Ticketnummer drin stand, und man dann überhaupt nicht verstehen konnte, was hat der Typ da gemacht, und da das jeder auf Master gepusht hat, und
50:01
keiner nachgeprüft hat, hat er sehr viel Spaß gemacht. Was ich danach halt eben eingeführt hatte, ist, wenn das ein relativ großes Projekt ist, erst mal die Komponente hinzuschreiben, also ist das jetzt ein Test, ist das jetzt irgendwie die Core-Komponente, ist das irgendeine andere Komponente, die da mit drin ist, also irgendwie keine Ahnung, Frontend, Backend, irgendwie sowas halt eben,
50:22
oder Module, die es da so gibt, dann die Ticketnummer, und dann eigentlich nur eine kurze Beschreibung, was gehört da rein, oder was wurde da gemacht, und auch explizit zu schreiben, welche Funktion das war. Das hat bei mir geklappt, wobei das auch noch drei Leute waren, von den drei Leuten war auch einer ich,
50:45
und das hat da in dem Fall geklappt, aber ich kann mir gut vorstellen, dass viele Leute darauf keinen Bock haben, da muss man aber eigentlich nur auf die Finger hauen, beim Code Review oder sowas eben, und dann so sagen, ne, so nicht, weil nachdem ich da Code Review auch eingeführt hab, haben die Leute nachgemerkt,
51:01
ok, wenn das jetzt nicht gemercht wird, dann muss ich das ja korrigieren, dann haben sie es automatisch ordentlich gemacht. Also Code Review ist immer schön, weil dann merken sie endlich so, ok, ich muss das ja fertig machen.
51:22
Ja. Genau, Adminusp geht auch, genau. Bitte? Ja, genau, auf die Dateien angeben. Genau.
51:41
So, noch was? Nochmal nochmal.
52:22
Ja. Ja, so spontan wüsste ich jetzt auch nicht, wie man das super schön machen kann, quasi.
52:44
Ja, Filter Want ist aber auch mit Genau. Filter Want ist nicht Frage, die Antwort ist nein. Ja?
53:13
Ja. Tipp des Tages, Merchstuhl-Konfügerin, wie, welches war das jetzt? Cardiff 3.
53:23
Ja. Ja. Also das war das Tipp des Tages. Ich hab noch eine Sache, ich mach noch eine kleine Verlosung, ich hab nämlich so ein hoffentlich tolles Gitbuch geschrieben und das wird das jetzt irgendwie verlosen, ich hab nur noch, jetzt immer noch
53:41
keine Idee, wie ich das verlosen soll. Wer hat denn, wer hat noch nicht wer die größte Beule hat, gewinnt's, ne?
54:02
Verschätzender Seitenzahl, wer am nächsten dran liegt. Ja, das kann jetzt jemand schnell googeln. Gewicht. Hier sitzt da eh schon viel. Wer hat denn, die meisten haben ja schon genug Ahnung von Git. Deshalb brauchen die Leute mit genug Ahnung
54:20
eigentlich nicht das Buch. Wer sagt jetzt von sich Wer sagt jetzt von sich selbst, hat heute nicht so viel verstanden. Bitte?
54:44
Ihr lacht hier über CVS und Git und ich durfte mich zuletzt in der Uni-Projektgruppe darüber aufregen, dass ich ernsthaft mit Leuten, die im Masterstudium im vierten Semester da so sind, diskutieren musste, dass Git besser ist als Dropbox.
55:07
Gut, dass es aufgezeichnet wird, das muss ich den Leuten dann mal verlinken. Ich hoffe, euer Lachen hört man noch gut genug. So, jetzt mal die melden, die glauben, sie hätten sich das verdient. Vier Leute. So, dann muss jetzt jeder
55:21
von euch eine Begründung sagen, warum und der Rest genau nach Lautstärke des Klatschens wird entschieden, aber wir hören uns erstmal die vier Sachen an. Bitte?
55:46
Das legt die Latte schon mal sehr hoch.
56:03
So, nächste Person.
56:29
Also da war ich im Moment nicht so viel. So, da war noch eine vierte Person. Ja?
56:56
So, dann
57:11
kannst du den gleich abholen. Genau, gibt es sonst noch irgendwelche Fragen? Ansonsten hier noch vielen Dank für die Aufmerksamkeit
57:22
und hier noch die wichtigste Folie.