Thema: git
-
Tags und Releases: Lightweight- versus annotierte Tags und wie sie sich verbreiten
Ein Lightweight-Tag ist nur ein Name für einen Commit; ein annotierter Tag ist ein eigenes Objekt mit Tagger, Datum, Nachricht und optionaler Signatur – deshalb ignoriert git describe Lightweight-Tags standardmässig, und deshalb sollten Releases annotierte oder signierte Tags verwenden; Tags werden nicht zusammen mit Branches gepusht, ausser mit --follow-tags oder --tags, und ein veröffentlichter Tag sollte nie verschoben werden.
-
Ab welcher Repository-Grösse brauchen Teams Monorepo-Build-Werkzeuge über blosses Git hinaus?
Offene Frage: Sparse Checkout, Partial Clone und Per-Verzeichnis-CI-Filter decken die erste Phase eines wachsenden Einzelrepositorys ab; bei welcher Grösse, Teamzahl oder Build-Zeit haben Teams festgestellt, dass ein Build-Graph-Werkzeug mit Remote-Caching nötig wurde, und was kostete der Übergang?
-
Eine Änderung so beschreiben, dass Reviewer sie prüfen können
Eine Änderungsbeschreibung nennt das Problem, den gewählten Ansatz samt Alternativen, wie getestet wurde und worauf Reviewer achten sollten; sie verlinkt das Ticket und listet Risiken und Folgearbeiten, sodass die Prüfung mit Verständnis beginnt statt mit Archäologie.
-
Wie betreiben Teams mehrere Coding-Agents in parallelen Git-Worktrees, ohne dass sich deren Caches, Hooks und Ports gegenseitig stören?
Offene Frage: Worktrees geben jedem Agent einen eigenen Branch und eigene Dateien, und die Dokumentation zu git worktree besagt, dass ein verknüpfter Worktree alles teilt ausser worktree-spezifischen Dateien wie HEAD und dem Index, sodass Hooks und Konfiguration gemeinsam genutzt werden, während Build-Caches, Abhängigkeitsverzeichnisse und lokale Ports oft fest verdrahtet sind; welche Konventionen haben parallele Agent-Läufe voneinander isoliert gehalten, und was ist zuerst kaputtgegangen?
-
Cherry-Picking: wann es passt und was es die Historie kostet
git cherry-pick spielt die Änderung eines Commits als neuen Commit mit anderer ID nach; es ist das richtige Werkzeug, um einen Fix auf einen Wartungs-Branch zurückzuportieren oder einen einzelnen Commit aus einem aufgegebenen Branch zu retten, doch jedes Pick erzeugt ein Duplikat, das Merges nicht erkennen können, daher den Ursprung mit -x festhalten und mergen statt picken, wenn der ganze Branch gewollt ist.
-
Verlorene Commits und Branches mit dem Reflog wiederherstellen
Der Reflog protokolliert jede Bewegung von HEAD und jeder Branch im lokalen Repository. Damit lässt sich ein missglückter Reset, Rebase, Amend oder eine gelöschte Branch rückgängig machen, indem die frühere Position gefunden und eine neue Branch darauf gesetzt wird; Einträge verfallen standardmässig nach 90 Tagen (30 bei nicht mehr erreichbaren), und uncommittete Änderungen waren nie darin enthalten.
-
Gute Commit-Nachrichten: das Warum festhalten
Eine Betreffzeile von rund 50 Zeichen im Imperativ, eine Leerzeile, dann ein Text, der Motivation, Alternativen und Folgen erklärt, statt den Diff nachzuerzählen.
-
Den Commit finden, der eine Regression eingeführt hat, mit git bisect
git bisect führt eine binäre Suche über die Historie zwischen einem bekannt guten und einem bekannt schlechten Commit durch; mit einem automatisierten Testskript findet es den schuldigen Commit ohne manuelle Durchsicht.
-
Änderungen, die Tests und Code zusammen anfassen, werden seltener zurückgenommen als reine Code-Änderungen ähnlicher Grösse
Hypothese: Eine Änderung, die zusammen mit ihrem Code Tests ändert oder hinzufügt, wurde von ihrer Autorin oder ihrem Autor mindestens einmal so durchgespielt, wie es die Tests beschreiben, und ihr folgt daher seltener ein git revert oder ein Korrekturcommit als einer reinen Code-Änderung gleicher Grösse und gleichen Bereichs; ein vorgeschlagener Test anhand der Repository-Geschichte mit Abgleich nach Grösse.
-
Rebase oder Merge: einen Branch integrieren
Mergen bewahrt die Historie so, wie sie geschah, und fügt einen Merge-Commit hinzu; Rebasen schreibt einen Branch auf eine neue Basis um, für eine lineare Historie. Nie Commits rebasen, auf denen andere bereits aufgebaut haben.
-
Commits und Tags mit einem SSH-Schlüssel oder GPG signieren
Git signiert Commits und Tags mit OpenPGP, X.509 oder, seit gpg.format=ssh, mit einem einfachen SSH-Schlüssel; die signierende Person setzt gpg.format und user.signingKey, Prüfende brauchen eine Allowed-Signers-Datei (SSH) oder einen vertrauenswürdigen Schlüsselbund (GPG), und Fälschungen werden mit git verify-commit oder dem Signatur-Abzeichen des Hosting-Anbieters geprüft.
-
Reformatierungs-Commits aus git blame heraushalten: -w und Ignore-Revs-Dateien
git blame -w ignoriert Whitespace beim Nachverfolgen von Zeilen, --ignore-rev und eine committete Datei .git-blame-ignore-revs überspringen benannte Commits wie Massen-Reformatierungen, sodass Zeilen der vorangegangenen inhaltlichen Änderung zugeschrieben werden, und -M/-C verfolgen verschobene oder kopierte Zeilen; GitHub liest dieselbe Datei automatisch.
-
Sicher stashen: Nachrichten, unversionierte Dateien und Stash-Branches
Ein Stash ist ein Commit, der unter refs/stash gespeichert wird, dessen ältere Einträge nur im Reflog dieser Referenz existieren; jedem Stash eine Nachricht geben, unversionierte Dateien gezielt einbeziehen, apply gegenüber pop bevorzugen, bis das Ergebnis geprüft ist, und git stash branch verwenden, wenn sich die Basis weiterentwickelt hat.
-
Conventional Commits: maschinenlesbare Commit-Typen
Die Spezifikation Conventional Commits fügt Commit-Nachrichten ein typisiertes Präfix (feat, fix und andere) sowie Markierungen für Breaking Changes hinzu, damit sich Changelogs und Versionssprünge automatisch ableiten lassen.
-
Arbeiten in einem grossen Repository mit Sparse Checkout und Partial Clone
Sparse Checkout begrenzt, welche Verzeichnisse im Arbeitsverzeichnis erscheinen (der Cone-Modus listet Verzeichnisse auf), Partial Clone mit --filter=blob:none verschiebt das Herunterladen von Dateiinhalten, bis sie gebraucht werden, und Shallow Clone kürzt die Historie; die drei lösen unterschiedliche Probleme und lassen sich kombinieren, doch Partial Clone braucht den Promisor-Remote online.
-
Mit git bisect den verursachenden Commit finden
git bisect sucht binär zwischen einem bekannten guten und einem schlechten Commit; mit einem Prüfskript findet es den ersten fehlerhaften Commit ohne manuelles Ausprobieren.
-
Choosing a Git branching workflow
How long-running and topic branches combine into a workflow, and which questions decide between trunk-based, feature-branch and release-branch models.
-
Linear history shortens regression diagnosis
Hypothesis: teams with a linear, squash- or rebase-based integration history locate regressing commits faster with bisect than teams with merge-heavy histories, because each step is a coherent, buildable change.
-
Removing large binaries from Git history with git filter-repo
A repository stays large after a big file is deleted because every clone carries its history; shrinking means finding the offending blobs, rewriting all commits that contain them with git filter-repo in a fresh clone, force-pushing every branch and tag, and having everyone re-clone, because rewritten commits have new IDs.
-
.gitattributes: line endings, diff drivers, merge drivers and export-ignore
A committed .gitattributes file settles per-path behaviour for the whole team: text=auto and eol normalise line endings, diff= assigns hunk-header patterns or textconv for binaries, merge= picks a driver such as union, binary marks files to leave alone, and export-ignore keeps paths out of git archive.
Maschinenlesbar: JSON