№ 25: Oh Git oh Gott! mit Michael van Engelshoven

Shownotes

Begrüßung: Vorstellung Michael – [00:00:53]

Retro

Constantin: PC kaputt – [00:04:27]
Moritz: MacBook am Limit: Software Live-Stream-Encoding – [00:06:57]
Michael: Bootstrap Utilities => Tailwind – [00:11:05]
Moritz: The Web Development Glossary – [00:16:29]
- Tweet

Property der Woche: Object.entries() – [00:18:06]

MDN / caniuse

Tagesthema: Git – [00:21:28]

Grundkonzepte: Hashing, .git-Ordner, Struktur, Referenzen – [00:22:01]
- git cat-file -p {commit-hash}
- „Directed Acyclic Graph (DAG)“ Definition auf techopedia
Branch-Umbenennung (z.B. master -> main) – [00:45:27]
- git branch -m master main
Command-Übersicht, Graph-Darstellung, visuelle Lern-Tools – [00:50:08]
GUIs und Git-Workflows für Einsteiger – [00:56:21]
- GitHub for Desktop
Rebase vs. Merge Commits / Rebase-Merge-Konflikt-Hölle – [00:58:45]
- Merging vs. Rebasing
- git rerere
Commits zusammenfassen (sqash/fixup) – [01:14:00]
- git rebase -i origin/master
- git config –global core.editor „{Pfad zum Editor}“ (Editor-Pfad mit zusätzlichem Parameter, z.B. -wait für VS Code und Atom, oder -w für Sublime Text, damit git auf das Schließen der Datei wartet)
- pick ändern zu fixup (oder squash für neue Commit-Message)
- Speichern in vim: Esc > :wq > Enter
Warum überhaupt Versionsverwaltung / gute Commit-Messages – [01:29:50]
Commit aufsplitten – [01:45:17]
- git add -p
Team/Arbeitsprozesse auf git umstellen / Git vs SVN – [01:49:35]
- O’Reilly: Version Control with Git (Affiliate Link)
- A successful Git branching model
- GitHub flow
„geheime“ Git-Commands, die praktische Dinge tun – [02:00:22]
- git bisect
- git-filter-repo

GeilTeil

Michael: Coding Adventure: Ant and Slime Simulations (YouTube) – [02:07:36]
Constantin: Gitlet.js – [02:11:13]
- Git in 600 Wörtern und 1000 Zeilen JavaScript
- „Git from the inside out“: Textversion / Talk auf YouTube

Kommentare

Danielkommentierte

am 19.04.2021 um 0:50

zu ~1:22:30 Wenn man vim mit :cq schließt, gibt er einen Fehlercode zurück. Dann muss man nicht die Datei leer machen, falls man sich nicht sicher ist, ob man gerade was falsches eingetippt hat.

Danielkommentierte

am 19.04.2021 um 0:54

Zu ~1:25:30 wenn man statt „git push –force“ „git push —force-with-lease“ nimmt, kann man nicht aus versehen was von anderen überschreiben. https://stackoverflow.com/a/52823955/10559526

Michaelkommentierte

am 19.04.2021 um 18:52

Danke für den Hinweis. Den Punkt habe ich total vergessen. Allerdings verhindert `–force-with-lease` lediglich, dass du bereits gepushte commits wieder überbügelst. Es sorgt aber nicht dafür, dass deine Kollegen darüber in Kenntnis gesetzt werden, dass sie auf die „neue History” rebasen.

Danielkommentierte

am 19.04.2021 um 1:03

Zu ~1:33:00 Das „WIP“ in gitlab sorgt dafür, dass man den Merge Request nicht mergen kann. Die Pipelines laufen trotzdem.
https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html

PS: Euer E-Mail & Name speichern Knopf tut nicht in Brave

Moritzkommentierte

am 19.04.2021 um 16:35

Danke für deine Kommentare!
Wir schauen uns das Problem an! 🙂

Moritzkommentierte

am 26.10.2021 um 18:41

Problem ist jetzt behoben!

Larskommentierte

am 21.04.2021 um 0:20

git commit -m „Danke für die tolle Folge 👍“

Moritzkommentierte

am 21.04.2021 um 22:57

🥰

Denniskommentierte

am 03.06.2021 um 8:47

N gutes Mühlenkölsch!

Meise2000kommentierte

am 25.04.2022 um 11:34

Also zu dieser Folge möchte ich doch einmal ein etwas kritisches Feedback geben. Vorab: ich finde Konstantin und Moritz machen die den Potcast großartig – und Git ist ein super gutes Werkzeug, aber…
Es kann doch nicht sein, dass sich Entwickler permanent damit rumärgern müssen, bei einem Rebase, immer wieder die gleichen Mergekonflikte beheben zu müssen. Ich finde, Moritz und Konstantin, da hättet ihr euch nicht mit einer „Ich erkläre euch jetzt erst einmal die Konzepte von Git“-Rede abschmettern lassen sollen. Hier hatten ihr dem guten Michael ruhig Mal etwas mehr Kontra geben können.
Stellt euch vor, ihr klagt euer Leid, was ihr mit Apple Music habt, einem Entwickler (von Apple Music) und der erklärt euch erst Mal, warum das so ist, wie es ist. Selbst, wenn das nachvollziehbar ist, wird man sich doch trotzdem weiter an den Macken stören…
Gute Usability in Software erkennt man daran, dass sich die Software nach dem Benutzer ausrichtet und nicht, dass der Benutzer erst Mal ganz viel Wissen aufbauen muss, um die Software bedienen zu können.
Lieber Michael, wenn du das liest: Die Usability von Git ist leider 🙈🙉🙊

Constantinkommentierte

am 25.04.2022 um 16:11

Danke für dein Feedback! Allerdings ist Micha ja auch nur User und entwickelt Git nicht, von daher trifft ihn da keine Schuld für die Usability! 😉

Kommentiere!