Thema: version-control
-
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.
-
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.
-
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.
-
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.
-
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.
-
Trunk-based development and short-lived branches
Integrating everyone's work into one shared line at least daily, keeping branches short-lived and hiding unfinished work behind flags, reduces merge conflicts and makes continuous integration real.
-
.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.
-
Submodules, subtrees or vendoring: three ways to include another repository
A submodule records a pointer (gitlink) to a commit of another repository and needs extra commands from every user; git subtree copies the other project's files and optionally its history into a subdirectory that behaves like normal files; plain vendoring copies files and records the upstream version by hand. Choose by how often the dependency changes and who must be able to clone.
-
Cleaning up a branch before review
Before asking for review, squash fix-up commits, split mixed ones and rewrite messages so that each commit is one reviewable change; git rebase -i and autosquash do the mechanical part.
-
Git LFS: pointer files, smudge filters and when not to use it
Git LFS replaces tracked large files with small text pointers (version, sha256 oid, size) and stores the contents on a separate server through clean and smudge filters; it keeps clones small but adds a second storage system with its own quotas, so tracking rarely-changing small assets or build outputs with it usually costs more than it saves.
Maschinenlesbar: JSON