Lieber Zuschauer, dieser Untertitel wurde automatisch generiert von YouTube und dementsprechend (sehr) fehlerhaft. Wenn du kannst, hilf uns bitte gute Untertitel zu erstellen: https://c3subtitles.de/talk/1519 Danke!
okay jetzt sind wir nach und darum an
der Stelle einen großen willkommen an
Florian has mit seinem Vortrag ein
kurzer Blick ins git
Applaus okay jo hallo willkommen zu
meinem Vortrag für alle die schon mal
von Git verwirrt worden sind
ähm ja wenn man täglich mit G arbeitet
hat man meistens mit einer Handvoll
einfacher Kommandos zu tun die meistens
das tun was man will aber manchmal fällt
einem Gitter dann doch in den Rücken und
gibt D irgendeine kryptische
Fehlermeldung aus und man muss den
lokalen gitguru suchen oder Dinge
funktionieren einfach nicht so wie man
es sich wünscht dann kann es hilfreich
sein wenn man versteht was git im
Hintergrund eigentlich tut wenn wir uns
das angucken wollen brauchen wir erstmal
ein leeres
Verzeichnis und darin legen wir uns ein
Repository an g sagt hier hat ein leeres
Repository angelegt aber tatsächlich
gibt es in dem Verzeichnis jetzt ein
Unterverzeichnis nämlich dieses Punkt
git und da hat git einige Dinge angelegt
paar davon sind Beispieldateien die
brauchen wir
nicht aber der Rest ist durchaus
interessant wir haben da die Config
Datei da wird ja Grundeinstellung für
dieses Repositories konfiguriert das
interessiert uns heute nicht es gibt die
Beschreibung die können z.B gitlab
anzeigen oder andere Tools und es gibt
noch eine dritte Datei die da liegt head
die entht Moment eine Referenz auf einen
Dateinamen der den aktuell ausgecheckten
branch beschreibt das Verzeichnis in
diese Datei liegen liegen soll Refs
heads können wir oben in der Liste sehen
aber die Datei gibt es noch nicht das
Verzeichnis ist leer und auch wenn man
guckt fast alle anderen Verzeichnisse
die git angelegt hat sind leer aber wenn
wir jetzt mehr mit git arbeiten sehen
wir dass darin einiges passieren wird
und deshalb werden wir ein paar von
diesen Verzeichnissen für den Rest des
Vortrages rechts im Auge behalten was
git mit diesen Verzeichnissen macht ist
dass es über das normale Dateisystem
indem man Dateien über ihren Namen
identifiziert ein virtuelles
inhaltsadressiertes Dateisystem legt
indem Dateien über ihren Inhalt
identifiziert werden der Unterschied ist
das bei einem normalen Dateisystem man
einen Dateinamen hat und dann sagt man
dem Dateisystem okay gib mir eine Datei
mit diesem Namen z.B divog background
Ping um hier den Hintergrund um mich
herum zu bekommen und wenn man das macht
dann gibt ein das Dateisystem diese
Datei zurück die so heißt egal was da
drinne ist bei einem inhaltsadressierten
Dateisystem kennst du dagegen den Inhalt
der Datei z.B die Häschen und Karotten
da und du bittest das Datei syem gibt
mir eine Datei mit diesem Inhalt und das
Dateisystem macht genau
das das klingt jetzt erstmal doof ich
meine warum soll ich die Datei vom
Dateisystem anfordern wenn ich den
Inhalt schon kenne dann habe ich den
doch schon der Trick ist das geht für
die Identifizierung einer Datei nicht
direkt den kompletten Inhalt benutzt
sondern einen eindeutigen
Hashwert gucken wir uns ein Beispiel an
und wir nehmen die zeich
und schicken die an den Befehl Gish head
object dann bekommen wir ein Hash zurück
hier BC 56
C4 und dieser Hash identifiziert
eindeutig eine Datei mit dem Inhalt Fu
wir können diesen Hash z.i nehmen und
ihn zusammen mit ein paar
Schlüsselworten die ein GIT Repository
einigermaßen eindeutig identifizieren an
eine Suchmaschine unseres Vertrauens
verfüttern und wenn wir dieseanfrage
jetzt abschicken sehen wir hoffentlich
gestern war das Suchergebnis noch da
eine Datei in dem Sourcecode Explorer
von Chromium diese fals 1 bar wir können
die Datei
aufmachen und wir sehen okay das ist ein
Blob mit genau dem Hash BC 56 C4 und der
Inhalt dieser Datei ist vu genau der den
wir haben wollten wir haben die Datei
über ihren Inhalt
gefunden jo google hat so eine Datei
muss cool sein wir wollen auch eine
haben und wir machen Sie mit Kit add g
auch gleich
bekannt diese Aktion git add da sagt man
auch dazu man hat die Datei dem Index
hinzugefügt wenn ihr euch gefragt hat
woher dieser Ausdruck kommt wenn ihr
jetzt rechts guckt ihr seht wir haben
eine neue Datei die heißt Index in
dieser Datei verwaltet git Information
über den Zustand der ihm bekannten
Dateien im Arbeitsverzeichnis das ist
eine Binärdatei mit der man normale Fall
nicht viel zu tun hat aber man kann mal
direkt reingucken mit od und man stellt
fest dass wir da paar Dinge drinne
wiederfinden die wir schon kennen
nämlich genau unseren Hash BC 56 C4 und
so weiter den wir hier in der Mitte
sehen und auch rechts unten in der Ecke
der Dateiname Fu Text und das T dann
noch in der nächsten
Zeile ja die andere neue Datei die wir
da rechts sehen ist in diesem objects
Unterverzeichnis entstanden und der
Dateiname ist offensichtlich direkt von
unserem Hash ab abgeleitet es liegt in
einem Unterverzeichnis PC du hast es
gerade die hexdarstellung des ersten
bites von dem Hash und der Rest des
Dateinamens in der Datei ist dann auch
einfach der Rest des
Hash wenn man git schon mal benutzt hat
dann sieht dieser Hash der Datei erstmal
nicht anders aus als der Hash von
irgendeinem commit und tatsächlich kann
man sich mit gitsow nicht nur commits
angucken sondern ebenso gut einzelne
Dateien also jetzt gitsow mit genau dem
Hash wenn das jetzt der Hash von einem
commit wäre würden wir erwarten dass wir
irgendwie das commit Datum kriegen den
Namen des committers oder der
committerin und
committext aber das ist jetzt halt kein
commit Hash sondern ein dateihh und wenn
wir jetzt get Show mit einem dateihash
abschicken was kriegen wir den Inhalt
der Datei keine große Überraschung
wenn wir unsere neue Datei jetzt
kommitten passiert wieder ein bisschen
was in dem git Unterverzeichnis rechts
wir kriegen zwei neue Dateien in dem
object
Verzeichnis die eine Datei ist
offensichtlich das commitobjekt wir
sehen der Dateiname unter Verzeichnis 84
und dann Datein weiter
e748b und so weiter ist genau pas genau
genau zu dem Hash von unserem komit auch
84
e748b und was ich auch gesehen was ich
auch geändert hat wir sehen jetzt
endlich unsere Ref heads Master Datei
auf die head ganz oben schon die ganze
Zeit verwiesen hat und wenn wir da
reingucken sehen wir der Inhalt dieser
Datei ist auch wieder genau der Hash von
dem comit 84 E7 48b und so
weiter
ja und wenn wir uns jetzt diesen comit
angucken mit dem
Hash dann finden wir das was wir
erwarten es ist ein Commit den habe ich
gerade angelegt er hat eine commit
message nämlich genau Import Fu was ich
oben als commit message angegeben habe
und wir sehen da ein difff der zu dem
commit gehört was ich gegenüber dem
Vorgänger commit geändert hat in diesem
Fall war ein leeres
Repositories er hat genau eine Datei
hinzugefügt namens foodtext mit dem
inhaltshash
bc564cd genau mit der einen zahile drin
Fu wir sehen hier aber noch einen
zweiten Hash der in diesem comit
referenziert wird hier oben mit dem
Schlüsselwort tree dieser Hash 8f
3761e und so weiter passt genau zu dem
zweiten Objekt das in dem
objectsverzeichnis neu angelegt worden
ist ähm den können wir uns auch wieder
mit GET Show
angucken sehen wir nicht so richtig viel
sagt uns es ein treeobjekt und es gibt
genau eine Datei die in diesem tree
liegt nämlich fullext wir kriegen ein
bisschen mehr Information wenn wir g LS
tree benutzen dann sagt er uns nicht nur
dass wir die Datei fotext haben sondern
auch dass es ein Blob ist das gibt's
Name für eine ganz normale Datei die
irgendeinen Inhalt haben kann wir sehen
vorne Standard Unix dateiugriff Rechte
und wir sehen wieder genau den kommit
den Datei Hash den wir für eine Datei
mit dem Inhalt Fu
erwarten fügen wir noch eine weitere
Datei hinzu hat den gleichen Inhalt wir
machen sie git bekannt und wir sehen
rechts erstmal dass ich nicht viel in
dem git unter Verzeichnis geändert hat
der Inhalt der Indexdatei hat sich
natürlich geändert aber den können wir
in dieser Ansicht nicht sehen aber
obwohl wir eine neue Datei hinzugefügt
haben haben kein neues Objekt in unserem
Unterverzeichnis einfach weil die Datei
hat den gleichen Inhalt wie die Datei
die schon da ist und damit ist es für
git dasselbe
Objekt wir können jetzt die Datei kom
Mitten und wir sehen rechts wieder zwei
neue Objekte eins ist wieder das commit
Objekt 8b 16 8C und so weiter können
genauer angucken wir sehen hier wieder
den tree und wir sehen natürlich der
tree rechts ist genau der gleiche und
der Inhalt von diesem tree Objekt ist
sind jetzt zwei Dateien eine heißt vtext
eine heißt bartext und beide haben genau
den Hash von einer Datei in der einfach
nur Fu drinne
steht was gegen dem über dem ersten
comit noch neu ist ist dieses parent
Feld in dem comit der den Hash des
vorherigen komits enthält wir sehen wir
genau das 84 ist genau der Hash von
commit Objekt das wir rechts in dem
objectsverzeichnis sehen
können diese Verweise auf parent commits
sind alles was aus dem
inhaltsadressierten Dateisystem git ein
Versionsverwaltungssystem
macht wir haben die fundamentalen
Objekte von GB ist der
kommit der verweist immer auf ein tree
also auf den momentanen Zustand des
Dateisystems also des
projektverzeichnisses in diesem Fall ist
es halt das treeobjekt mit diesen zwei
Dateien Fu und
bartext und wir haben parents also
parent Felder die aus dieser Menge von
commits also von Dateisystem Zuständen
eine Versionshistory macht dadurch wird
git halt zu einem
Versionsverwaltungssystem und das macht
aus dieser Menge von commits
einingerichteten Grafen den können wir
uns mit gitlock Graph angucken und wir
sehen wir haben jetzt einen relativ
einfachen Grafen er hat einfach nur zwei
comits die mit einer Linie verbunden
sind das ist im Prinzip das gesamte
dateimodell von Git was man hier auf
dieser Folie jetzt sehen kann es gibt
commits es gibt die treeobjekte und es
gibt die eigentlichen Daten in Blobs und
alles wird gleichermaßen über Hashes
identifiziert die man da rechts in dem
objects Verzeichnis sehen kann
zusätzlich gibt es dann noch branches
wir haben hier diesen einen branch den
master Branch und dem Ref heads
verzeichnet
das aber nur aber so ein branch in git
ist erstmal nur eine einfache Datei die
den Hash eines komits
enthält das ist anders als bei manchen
anderen
versionverwaltungssystemen darauf gehe
ich aber später noch genauer
ein jetzt möchte ich erstmal eine sehr
angenehme Eigenschaft von Git
erläutern das ist gibt wirft diese
ganzen Objekte die es da an
anlegt typischerweise ganze Zeit lang
nicht weg selbst wenn nichts mehr auf so
ein Objekt verweist typischerweise
bewahrt es alte Objekte selbst die man
nicht mehr braucht noch zwei Wochen auf
und das macht es häufig möglich wenn man
einen Merch oder rebase Unfall hatte und
meinte man hat sich den
komplette Repository zerschossen alles
besteht nur noch aus konfliktmarkern
macht das das häufig möglich die
verloren geglaubten Daten
wiederherzustellen wenn man weiß wo man
suchen muss
nehmen wir z.B an dass wir unseren
letzten commit durch ein falsches
Kommando verloren haben ich mache das
einfach indem ich jetzt hart den kom den
kommit davor auschecke jetzt ist unsere
neue Datei bartext weg und auch in dem
Grafen aller Versionen in dem Repository
taucht der zweite commit nicht mehr auf
aber rechts in dem git unterfzeichnis
können wir sehen dass alle die Objekte
die wir hatten auch das commit Objekt
von dem zweiten commit
alle noch da sind und wir sehen eine
neue Datei
oriket und die enthält den Hash das
gerade eben verlorenegangenen kommits
enthält darüber könnten wir den commit
jetzt wiederfinden wenn uns der Fehler
rechtzeitig auffällt aber halt nur wenn
wir das gleich merken eine andere
Möglichkeit die auch immer funktioniert
wenn man auch ältere kommits oder eine
Stunde später oder so das erst merkt
oder so wiederzufinden ist dass man über
das reflog geht das enthält
Informationen darüber welche comits
schon mal ausgecheckt waren hier sehen
wir das reflock wir hatten drei
verschiedene kommits ausgecheckt während
dieses repositore existiert halt ganz am
Anfang haben wir den Initialen kommit wo
wir halt full text importiert haben dann
hatten wir den zweiten comit wo wir
bartext hinzugefügt haben und dann der
dritte Stand den wir aus gecheckt haben
das war als wir wieder auf den ersten
komit den branch zurückgesetzt haben der
komit den wir jetzt haben wollen ist der
zweite aus dieser Liste den können wir
GS den commit hchmerken und wir können
den aktuellen branch z.B ebenso wir ihn
hart auf den falschen kommit
zurückgesetzt haben jetzt wieder hart
auf den
ursprünglichen kommit zurücksetzen und
wenn wir das machen sind wir genau da wo
wir eben schon mal waren wir haben
wieder
zwei komits die durch diese eine Linie
verbunden
sind eine andere Situation in der man
sich manchmal
befindet insbesondere wenn man alte
Version im reflock untersucht ist die
dass man einen Commit ausgecheckt hat
sich aber nicht auf einem branch
befindet hier checke ich z.B jetzt
einfach mal den commit vor dem aktuellen
comit
aus jetzt zeigt head nicht mehr auf
einen Bran Namen sondern direkt auf
einen
Commit hier sehen wir jetzt in der
grafenansicht wir haben den masterbranch
der oben auf den comit 8b16 bezeich
verzeichnet aber der Head also das
momentan ausgecheckte Zustand ist unten
der erste commit 84
E7 und wir können auch die head Datei
angucken da war vorhin die Referenz auf
Ref headads Master drinne also Verweis
auf eine Dateinamen von einem einer
branchdatei da steht jetzt direkt die ID
eines komits
drinne das ist zunächst mal eigentlich
überhaupt kein Problem man kann in
dieser Situation fast normal
weiterarbeiten wenn man jetzt aber
irgendwie ein Dinge ändert und die
committet dann hat man es eventuell
schwierig diesen comit wiederzufinden
und man muss ihn dann irgendwie im
reflog suchen was häufig eine dove
Situation ist und vor allen nach zi
Wochen wä der kommit dann tatsächlich
weg
aber gibt uns hier mit dieser langen
Mitteilung eine Möglichkeit od sagt uns
wie wir aus dieser Situation rauskommen
einfach W man sich das durchliest steht
da wenn Sie einen neuen branch erstellen
möchten um Ihre erstellten commits zu
behalten können Sie das jetzt oder
später durch einen weiteren Checkout mit
der Option - B tun machen wir das noch
einfach wir legen einen branch morfu an
jetzt zeigt head wieder auf einen branch
nicht mehr auf ein kommit nämlich auf
die neue Datei in Ref
heads und der branch der da neu angelegt
worden ist zeigt genau auf unseren
commit 84
E7 können uns das auch noch mal in der
grafenansicht Ansehen der Graf sieht
genauso aus wie davor nur unten ist head
jetzt nicht mehr direkt auf dem comit
sondern head zeigt erstmal auf den morfu
branch der auf den komit
zeigt mit diesem branch können wir jetzt
ganz normal arbeiten als wenn nichts
gewesen werden wäre wir können z.B eine
Datei ändern z.B eine Zeile hinzufügen
so können wir uns angucken die Datei ist
eine Zeile länger geworden wir füen
machen sie git bekannt oder die Änderung
sagen git add Datei und wir sehen es ist
ein neues Objekt rechts angelegt worden
das gerade halt das Objekt ist von
dieser Datei mit zwei Zeilen können das
kommitten und Kriegen wieder zwei
weitere neue
Objekte in dem
objectverzeichnis der Head ist immer
noch unser
branch aber der branch zeigt jetzt nicht
mehr auf den comit 84 E7 sondern
natürlich auf den neuen comit
e50d
72b W uns den Grafen angucken sehen wir
wir haben jetzt eine
Abzweigung wir haben di anfangsomit und
von der zwei comits die von diesem
anfangsomit abgehen der eine hat die
Datei bartext hinzugefügt und der andere
hat noch ein paar Fuß in die erste Datei
hinzug fügt ja jetzt können wir diesen
branch in den Master Mergen dazu
wechseln wir erstmal wieder auf den
master
Branch wie erwartet hat sich jetzt der
geändert er zeigt nicht mehr auf
resheads morfu sondern auf reshes Master
das genau heißt es den branch zu
wechseln und wir können den branch
Mergen und Löschen der branch ist
gemerged wir brauchen ihn eigentlich
nicht mehr das ist eine gute
Angewohnheit branches die gemerged sind
möglichst bald zu löschen das macht
viele Dinge
übersichtlicher jetzt könen wir uns
Komet auf dem Master
angucken und wir sehen sieht genauso aus
wie ein normaler Komet der einzige
Unterschied zu den comits die wir bisher
gesehen haben ist dass er zwei parent
Felder hat und das ist dann auch der
einzige Unterschied zwischen einem Merch
commit und einem normalen commit ein
Merch commit hat zwei oder mehr parents
ein normaler comit hat höchstens einen
parent
W den Grafen angucken sehen wir auch
genau die Situation wir haben drei
einfache commits der unterste der
allererste hat keinen parent dann die
beiden kommen jetzt da drüber
8b16 und 5e0d haben beide einen parent
nämlich den ersten und der letzte commit
hat Hal die beiden anderen commits als
parents das sind
ja
jo
jetzt haben wir mit zwei branches
gearbeitet zwischen ihnen gewechselt und
Dinge gemerged und jetzt ist eigentlich
ein guter Punkt um noch mal darauf
einzugehen was eigentlich ein branch
ist in vielen Versionsverwaltung sind
branches schwierig schwerwiegende
aufwendig zu verwaltende Dinge
Subversion z.B hat man dann fast ein
Kopie des ganzen Repositories um ein
branch anzulegen und wenn man Code
zwischen verschiedenen
branches zusammenfügen will kann das
schon mal schwierig sein oder muss auf
jeden Fall gut darüber nachdenken was
man da machen will verglichen damit gibt
es in git eigentlich fast gar keine
Branche wie gesagt branch ist wirklich
einfach nur eine Datei da rechts unten
in dem Resets Verzeichnis und in der
Datei steht der Hash eines komits
drinne ja branch ist wirklich nur ein
Name der auf einen Commit zeigt und
macht es das einfacher macht diesen
kommit wiederzufinden und es gibt Hal
nur noch diese eine zusätzliche
Konvention die wir eben auch schon in
Aktion gesehen haben wenn der Head auf
einen branch zeigt und ich da einen
neuen commit anlege dann wird der branch
so aktualisiert dass er auf diesen neuen
komit
zeigt gucken wir uns den Merch commit
von eben noch mal
an branches und Bran Namen werden hier
tatsächlich nur in dem an zukünftige
Benutzer gerichteten Freitextfeld der
commit message erwähnt für git und für
die Versionshistory die git verwaltet
sind nur die Verweise auf die parent
commits wichtig und transitiv dann deren
parents aber ob diese kommits jeweils
auf einem branch waren oder ob dieses
alles mit losgelösten heads passiert
wird und man nur irgendwie später
nachdem man alles gemerged hat dann ein
branch auf den letzten kommit gesetzt
hat das ist g völlig egal das kann man
anhand der git history auch nicht
feststellen diese Information ob dieser
commit früher also sagen wir jetzt der
parent commit
8b16 ob der irgendwann mal auf dem
masterbranch war oder auf irgendeinem
anderen branchpart diese Information
gibt es in gibt nicht auch wenn man sich
in der grafenansicht anguckt hier sehen
wir eine Referenz auf einen branch
nämlich ganz oben in der allerersten
Zeile dass der Head der gerade
ausgesteckte head auf den master Branch
verzeigt der gerade dann wiederum auf
den Merch commit zeigt sonst diese
ganzen Linien sind einfach nur Beziehung
zwischen einem commit und seinem parent
commit aber es gibt keine Identität von
branches entlang dieser Linie also diese
Linien ja man denkt bei branch ist ein
Ast oder ein Zweig und das ist irgendwas
was irgendwo Abzweig und hinwächst aber
in der Konzeption von G diese Linien
erstmal kein branch zugeordnet branch
ist eigentlich nur der Name für den
aktuellen Stand des
Repositories das branches im
Wesentlichen nur Namen nur Schall und
Rauch sind ist was das für manche Leute
die von anderen Systemen kommen anfangs
Schwierigkeiten
bereitet das führt dann manchmal dazu
dass sie komische Regeln aufstellen wie
man mit branchis umgehen soll und das
dass man irgendwelche
branchverwaltungsregeln aufstellen die
eigentlich nicht hilfreich sind und auch
überhaupt nicht zu den Konzepten von Git
passen klassisches Beispiel dafür ist
dieses gitfow das vor ein paar Jahren
aufgekommen
ist das ist um die Idee strukturiert
dass der branch auf dem ein comit
gemacht wurde eine ganz wesentliche
Eigenschaft dieses dieses komitz ist das
sieht man dann ich weiß nicht wenn
jemand die Grafiken von von der Webseite
kennt an diesen langen geraden Linien
die alle komits einer Farbe verbinden ja
Master ist alles blau und die vop ist
alles gelb und
sowas aber das passt überhaupt nicht zu
den Konzepten von
Git git haben comits einfach keine Farbe
und Branche sind nicht irgendwelche
langlebigen Versionen von Sourcecode
oder sowas sondern wirklich die
verweisen auf den aktuellen Stand ist
ein Name für einen bestimmten Stand des
Repositories
es kann sein dass es Projekt Setups gibt
wo man tatsächlich solche
schwergewichtigen branches haben will
aber
wenn man das möchte sollte man überlegen
ob git wirklich das System ist das man
haben will weil so wie es in in
gitfow realisiert wird führt das meiner
Ansicht nach nur dazu dass ein ganzen
Haufen Bürokratie gibt ein ganzen Haufen
Merch commits die eigentlich überhaupt
nichts dazu beitragen die Geschichte des
Projekts irgendwie einfacher
verständlich oder besser handhabbar zu
machen ja das sind so die grundlegenden
Konzepte
haben ganzen Haufen Objekte angegt wir
sehen rechts da das passt gar nicht mehr
in das Fenster das läuft schon über die
Baumansicht von diesem objects
Verzeichnis da mag man sich fragen äh
wenn ich so
viele Dateien in vielen Verzeichnissen
anlege äh wird das nicht auf Dauer
ziemlich langsam wenn gibt da immer
diese ganzen Verzeichnisse durchsuchen
muss
m im Prinzip würde es das tun wenn das
alles ist also wie gesagt das ist das
logische Modell logisch man kann alles
was geht
macht mit dem einfachen Modell verstehen
aber physikalisch aus Effizienzgründen
macht gibt noch ein paar andere Sachen
ist
und zwar räumt es regelmäßig dieses
Verzeichnis auf oder auch auf Verlangen
dazu gibt es den Befehl g GC für Garbage
Collection oder Müllabfuhr und wenn ich
den
ausführe dann räumt git das objects
Verzeichnis auf und packt alle die
Objekte da die da waren in eine
sogenannte packdatei
m weniger Dateisystem überhabt das eine
binär Datei in der git effizient da
drinne suchen und mit arbeiten kann die
Objektdateien sind alle weg aber die
Objekte selbst leben halt weiter in den
packdateien und ich kann sie alle noch
sehen hier jetzt der Graf alles noch da
alle unsere comits sind da und mit den
comits natürlich auch die referenzierten
tree Objekte und die ganzen Blops in
denen Fu drinne
steht dieses aufräumen ist übgens eine
der wenigen Situationen wo in denen git
tatsächlich mal Daten weg wirft
nicht mehr referenzierte Objekte die ein
gewisses gewisses Alter
übersteigen normalerweise sind das halt
wie gesagt zwei Wochen werden bei einer
Garbage Collection unwiderbringlich
gelöscht und dann hilft es auch einem
nicht mehr wenn man die commit it noch
im reflock
findet oder sie von früher irgendwie
noch weiß weil sie irgendjemand mal
ausgedruckt hat dann sind die Daten weg
aber vorher nicht also wenn man letzte
Woche einen Fehler gemacht hat kann man
sich relativ sicher sein wenn man g in
der Default Konfiguration
äh betreibt dass man die Daten die man
letzte Woche aus Versehen mal gelöscht
hat einfach auf einfach noch mal
wiederfinden
kann
ja das ist so mein kurzer Einblick in
das was GB da alles an Magie in diesem
Punkt git Unterverzeichnis macht ich
hoffe es hat ein paar Leuten geholfen
besser zu verstehen was da passiert und
vielleicht auch
die eine oder andere
Fehlermeldung besser verständlich
gemacht über die man in der Zukunft
stolpert und
die senkt vielleicht auch die
Arbeitslast für den lokalen gitguru ja
vielen Dank für eure Aufmerksamkeit habt
ihr
Fragen das ist sehr gut dass ich
anfangen kann dafür müsste ich jetzt den
Fragen t aufhaben so das kann sich nur
um ich habe so viele Fenster auf ja so
ist das halt
manchmal
ja ich hö ih gerade nicht so ich rede
ah so jetzt bin ich im mumel an sehr
schön dann kommen wir jetzt zur Fr
Session und ich war ja gerade dabei die
wenn ihr wüsstet wie viel Fenster ich
auf
da so sehr gut ich gehe nach hier oben
zack in diesem Pad er l sehr schön also
wassermarsch und irgendjemand schreibt
oben drüber schließe deine Fenster okay
hast du Recht so weißt du eventuell
warum die Indexdatei binary ist und
nicht irgendwas lesbares
äh weiß ich nicht vermutlich weil es
dann schneller geht keine Ahnung
m hast du ein paar Beispiele aus der
Praxis wo dir dieses Wissen was bringt
m es bringt ein manchmal mal was wenn
bei irgendeinem Merch Config Dinge
verloren gegangen sind und man dann
später mal genau wissen will wann wann
war das eventuell wenn wenn oder wenn
Merch und rebase war einfach dass man
gucken kann noch mal ob der comit den
schon nicht mehr in der offiziellen
history gibt ob man den noch mal finden
kann es ist genau der täglichen Arbeit
wie gesagt hat man seine sech sben
Kommandos die das meiste tun aber es ist
manchmal hilfreich wenn halt irgendwas
schief gegangen
ist wo ist das
reflock oder dessen Information im
dgitordner das ist auch ein dt gitordner
das ist ein von den Verzeichnissen die
ich ausgeblendet habe wenn ich hier noch
mal sehen wir hier noch ein neues
Verzeichnis dass ich rechts nicht
angezeigt habe weil das ohnehin schon
voll war das ist dieses
Logs refset Master und so daraus da
liegen diese Information
drinne okay wie teilen sich die
Indexinformationen der komits in den
packfiles auf wie funktioniert die Datei
packed
s da habe ich nicht
reingeguckt also muss muss auch
irgendeine Dateisystem ähnliche Struktur
halt haben auf die git
einfacher zugreifen kann weil sie halt
auf den einen Anwendungsfall
spezialisiert ist und nicht in
Allgemeines Dateisystem
ist wie funktioniert das mit git LFS
werden da nur die Blops extern
gespeichert wei ich nicht LFS habe ich
bisher nicht gearbeitet wir hatten ein
Projekt wo wir das benutzen sollten aber
irgendjemand hat das nie fertig
aufgesetzt
gekriegt wie funktionieren Sub modules
und warum ist die Nutzung davon so
komisch in der Kommandozeilen Tools
integriert beispielsweise Folge im
Submodule bitte dem Upstream branch
XY sind im Prinzip ein
Hack wo ich einfach in git halt W
verzeichn eine Datei anlege wo drin
steht Blende hier dieses andere
Repository an und mach irgendwelche
komischen Dinge wenn du was
auscheckst das ist ja es ist Versuch mit
einem System das ja Mono ganz viele
einzelreos zu
emulieren und das ja das beißt ein es
ist schwierig
wie kann ein Projekt das in zwei
verschiedenen Repros angefangen wurde
für zwei verschiedene Module in ein
einziges Repro überführt werden man kann
einfach das in dem einen Repository
gehen und das andere Repository als ein
Remote hinzufügen und P
fetchen und dann kann man einfach ein
z.B den wenn wenn die
Datei Namen sich also die Verzeichnisse
sich nicht überlappen kann man dann z.B
einfach ein branch aus dem zweiten
Repository in das erste Repository
Mergen dann hat man halt eine
Versionshistory die nicht so aussieht
wie ein normaleso normalerweise sieht es
ja aus wie ein Baum man hat einen
anfangscomit und dann geht das hoch und
dann Zweigen vielleicht verschiedene
Versionen davon ab
und bei dem herangehen hatte man halt
zwei anfangskomits die beide ihre
history haben und bauen deravon abzeig
und irgendwo oben Merch man die zusammen
dann hat man halt ein Commit der hat
zwei parents und der eine parent hat
halt ursprünglich in dem einen
Repository gelebt und der andere parent
hat ursprünglich in dem anderen
Repository gelebt aber das ist geh
relativ
egal das ist ja auch der der Trick
glaube ich den git für
die Webseiten zu Projekten mal gemacht
hat man hatte die normale Repository
history mit dem master Branch und einen
branches die davon abzweigen und in dem
gleichen Repository liegt ein eine
zweite history die mit der anderen
überhaupt nichts zu tun hat die ihren
eigenen Initialen kommit hat wo dann die
Projektwebseite drinne
ist okay du sagtest gitflow macht keinen
Sinn aber wenn z.B ein Feature über ein
längere Zeit von mehreren Personen
entwickelt wird wäre es doch schon
hilfreich einen Namen für den aktuellen
Stand des Features zu haben oder ja
natürlich und die Benutzung von Feature
branches und auch die Idee dass Feature
Branche eigentlich möglichst kurzlebig
sein sollten ist gut das ist das eine
Ding weshalb gitflow funktioniert was
nicht funktioniert ist dieses komische
ewige zurückmergen in den master Branch
was ich auch komisch finde ist dass der
der Haupt develop branch anders als bei
git Def einfach nicht Master heißt
sondern develop das macht einfach man
Standard git tooling oder benutzt macht
das irgendwie komisch weil man immer auf
dem anderen branch ist als man
glaubt also ja also die Idee feature
branches zu haben ist definitiv richtig
die Idee kurzbige Feature branches zu
haben ist noch besser aber der
bürokratische Overhead mit diesen
komischen Master branches und hotfex
branches die in verschiedene Richtungen
gemerged werden ist ist meiner Ansicht
nach im Wesentlichen nur
Overhead okay was sind denn gute
Workflows mit git und Code Review im
Gegensatz zu gitflow ich vermute
e-mailbasierte Workflows aber was gibt
es
noch muss es für das Projekt
ausprobieren was gibt es gibt halt
was viel propagiert wird das halt dieses
Trunk basierte development dass man halt
den den develop hat man versucht den
develop immer lauffähig und deplbar zu
halten mit kurzlebigen Feature
branches das ist was was ich auch gerne
empfehle wenn man eine Situation hat
dass man mehrere Versionen von einem
Produkt unterstützen muss weil man hat
eine Version ausgeliefert entwickelt
eine neue und wenn man die neue
entwickelt muss man an der alten noch
was ändern was dass man sich anguckt was
free BSD bei ihrem CVS branching Modell
machen das kann man meiner Ansicht nach
auch auf git übertragen und dann ssten
ja man muss sich überlegen was was haben
wir haben wir halt z.B single page web
application wo es immer genau den ein
Stand gibt da macht man Trunk based ohne
irgendwelche versionsbranches oder haben
wir was wo wir halt
ein Produkt haben mit mehreren Versionen
die gleichzeitig
benutzt werden gleichzeitig im Markt
sind oder wo man rückwärts komf oder
alte Version noch unterstützen muss dann
muss man halt gucken dass man sich die
entsprechendes branchmodell
überlegt mhm was ist dein schlimmstes
git Setup mit dem du bisher zu tun
hattest
ähm was was immer schwierig ist ist wenn
man mehrere Repositories haben die sich
relativ eng parallel
entwickeln dann hat man dann hat man dre
vier Repositories wo man immer die
richtige Version von dem richtigen
branch ausgecheckt haben will haben muss
und wenn man dann irgendwie was machen
will wie ein G bisect um einen backg zu
finden wird man wahnsinnig weil das bisc
natürlich auf die einen dieser
Repositories
ist aber nicht auf den anderen die auch
immer mit parallel ausgecheckt worden
sind und aber man weiß nie so genau
welche Version jetzt von dem einen
Repository zu der gerade ausgecheckten
Version zu dem anderen Repository gehört
das ist so eine Situation wo man denken
vielleicht wären submodules auch gar
nicht so falsch
aber ja submodules haben auch ihre
Schmerzen
idealerweise hat man eine Projektgröße
das alles in ein Repository passt dann
funktioniert geht am besten sollen ich
glaube die Frage bezieht sich auf die
Frage davor sollen also feature branches
auch sofort gelöscht werden oder sollen
sie für Bugfixes und Erweiterungen
bestehen
bleiben wenn Feature Branchen Feature
branch ist wird er nicht mehr benötigt
sobald er gemerged ist wenn man das
anderes hat ich habe das andere ist wenn
ich mehrere Versionen haben ich habe
eine Version 4 oder ich fange an Version
5 zu entwickeln dann muss ich mein mein
Version 4 branch am Leben halten um BU
fixel in version 4 zu machen weil es
kann ja sein dass ich ein back in
version 4 in dem codeeteil fixen muss
den es in Version 5 gar nicht mehr gibt
weil ich ih refact
habe okay gibt es Anwendungsfälle bei
denen es Sinn macht manuell im dogit
Verzeichnis manuell etwas zu bearbeiten
z.B mit dateikommandos wie MV RM und so
weiter wenn man die Konfiguration ändern
will natürlich ich würde glaube ich die
Finger von den objects und sowas lassen
wobi im Prinzip ja man weiß was man tut
könnte man das vermutlich tun aber ich
würd es nicht machen außer um zu gucken
ob es
geht virtual file system forgit wie
funktioniert das und ab wann bringt es
was habe ich noch nicht raufgeguckt ich
denke das ist ein so ein Userspace fil
System für Linux wo man dann auf
Repository zugreift das läuft dann ganz
normal wie so ein Userspace Dateisystem
ich weiß nicht genau was was das System
jetzt
ist okay g zum Verwalten von nicht
Textdateien binary blubs Bilder Videos
docx PDF kann das abseits vom coden
technisch Sinn machen beispielsweise als
verteiltes
Dateisystem schwierig also wenn sich die
nicht ändern vielleicht aber wenn es
Versionen von also verschiedene
Versionen von der gleichen Binärdatei
gibt unschön git wird bei großen Dateien
irgendwann auch
langsam das ist ist nicht der der Fall
für für den git geschrieben ist geht es
wird den Linux Kernel geschrieben und da
sind typischerweise wenig Blops drinne
so sieben Leute fragen insgesamt mich
interessiert mit welchem Tool du die
Shell Aufzeichnung gemacht und
ausgeführt hast also temux sei schon im
Hintergrund erkannt worden ja es ist gar
keine Shell Aufzeichnung das ist ein
Script wie gesagt es ist ein Fenster
ganz normales shellfenster habt ihr ja
gesehen ich habe hier eben diese Dings
die das getri aufgerufen das andere ist
ein Skript das irgendwo anders
liegt das ist ein objective Kamel Script
das die gesamten Logik und meine gen
Notizen enthält das fängt wo fängt an
genau hier fängt's
an das hab hier dies Note die zeigt mir
meine Notizen an was ich sagen möchte es
gibt Kommandos die es dann ausführt in
dem richtigen Moment wenn ich auf Enter
gedrückt habe hier z.B das leere
Verzeichnis anlegt und dann hier geh
Inet und so
weiter paar Dinge irgendwo ist da weiter
unten macht er komischere Dinge hier
genau hier hier macht er mit diesem
Befehl macht er hier den diesen recht
Rechte Teilfenster
auf genau das ganze läuft einfach
darüber dass ich halt in dem Script
irgendwo hier das ist diese Funktion
muss man jetzt nicht verstehen sieht
häslich aus ist einfach auch nur führt
diverse Dinge aus legt TX Session an
startaret dann genau macht in dieser
Session die die die
Titelseite dann Genom Terminal das mit
einem Skript genau diese TMAX TMAX
Session
ausführt genau was noch Wicht was noch
eine interessante Funktion ist ist hier
diese kommandounktion die die
eigentlichen Kommandos ausführt die
zeigt mich hier erstmal
an in meinem Fenster mit den Notizen und
sowas wir in Set hervorgehoben das den
nächsten Befehl den er ausführt und
führt ih dann aus und hiertig auch diese
wi Funktion die zerlegt den die Ausgabe
halt das Kommando das
in in einzelne Zeichen und schickt dann
jeden einzelnen Buchstaben mit einem
zufälligen Zeit ftezeit dazwischen damit
es aussieht wie ganz schnell und exakt
von Hand getippt an TMAX und was auch
noch wichtig ist
ist diese Funktion retitle die rufe ich
hier ab und zu mal auf die ändert den
Titel des gerade aktiven also meines
Notizen Fensters und das benutze ich
dann in obs um da automatisch
senenübergänge zu zu triggern also ich
bin jetzt hier in dem Fenster wo ich mal
die Sachen einfach Anzeige wenn ich
jetzt wieder auf mein notizenfenster
klicke mit einem Klick bin ich
wieder in der Gesamtansicht ein Klick
ein Klick und das ganze Skript ist halt
so geschrieben dass sie einfach mit
Enter enter enter enter enter durch den
ganzen Vortrag
durchgehe sehr gut dazu passen die
beiden nächsten Fragen Slash Kommentare
findet man die Slides dann auch in dem
git oder kannst Du so das Skript
publizieren es gibt es in dem git aber
das ist Moment in meinem git ich werde
das nachher vermutlich einfach mal auf
meinem GitHub zu tun das
ist
vielleicht noch ein https dazu fürute
die
das das sollte die URL sein wo wo unter
der das dann nachher zu finden sein
sollte so just in time
Release nächste Frage kann ich einen
defekten gitbaum komitz zeigen auf 00
einfach
abschneiden die Situation hatte ich noch
nie ich weiß auch nicht wie ich in die
Situation
komme insofern dann die nächste mit
welchen Konzepten können mehrere
gleichzeitig lebende Versionen einer
Software maintaint werden wenn nicht mit
langlebigen branches wie in
gitflow die es gibt zwei Arten von
branches es gibt langlebige branches wie
ein Release branch für Version 4 ein
branch für Version 5 und die Leben
soangee wie Version 4 und Version 5
released werden was der die langlebigen
branches in gitflow es gibt ein develop
branch und es gibt ein master Branch und
wenn
ich Version 5 Release dann dann merge
ich den develop branch in den master
Branch und was ich d mit Version 4 mache
weiß ich nicht weil Version 4 habe ich
auf master Branch jetzt über
überschrieben und ich weiß auch nicht
wenn ich ein Bug in version 4 fixen will
der in Version 5 nicht mehr gebraucht
wird der Fix sag kann ich den eigentlich
auch nicht auf den master Branch fixen
weil dann habe ich das nächste Mal wenn
ich Version 5 auf Version auf den Master
merger habe ich dann merge Konflikt weil
ich habe den Bug in version 4 auf master
Branch gefixt aber nicht in den
developbranchen Version 5 gemerged weil
er da gar nicht reingehört das ist das
Problem also das Problem ist an gitfow
ist nicht dass es branches gibt die die
die lange leben sondern dass es
diese diese langlebigen Branchen nicht
wirklich eine Funktion haben um die die
History und die die Projektverwaltung
einfacher zu machen sondern nur
irgendwie bürokratische Feature ist
damit der aktuelle Release also die
aktuelle offiziell freigegebene Version
immer der aktuelle Stand von Master
ist okay wie unterscheiden sich subtrees
von submodules im dgit und sollte man
subtrees gegenüber submodules vorziehen
ähm fragt da musste jemand Fragen der
mit beiden Erfahrung gehabt gemacht
hat ja dann an der Stelle das war die
letzte Frage normalerweise gehen ja
manchmal sogar auch Leute ans Mikrofon
und sagen ein Feedback wie danke das
kann wenn du in deine hier reinuckst
gleich ins Ding da werden ganz viele
positives Feedback ist schon angekommen
an der Stelle einen riesigen Applaus
oder was auch immer man sagt für Florian
ha mit ein kurzer Blick ins git und ja
ich habe auch wieder viel gelernt Dank
und ja weiter gitten für den Weltfrieden
tschüss