git-branch-strategielisted

# Branch-Strategie ## Grundform Feature-Branch-Workflow, ausnahmslos. Ein Branch trägt genau ein Issue. ```bash git fetch origin git checkout -b issue-<nr>-<kurzer-slug> origin/main ``` Nie direkt auf `main` committen. **Vorher nachsehen, ob es den Branch schon gibt.** Ein früherer Versuch kann abgebrochen sein — Zeitüberschreitung, erschöpftes Nutzungslimit, abgestürzter Lauf — und Commits hinterlassen haben, während das Issue sein Label behielt: ```bash git ls-remote --heads origin "issue-<nr>-*" ``` Kommt etwas zurück, wird **darauf weitergearbeitet**, nicht neu angefangen: ```bash git checkout -b issue-<nr>-<slug> origin/issue-<nr>-<slug> git rebase origin/main ``` Und dann zuerst `git log origin/main..HEAD` lesen, um zu sehen, wie weit der vorige Versuch gekommen ist. Ein neuer Branch mit demselben Namen wäre die schlechteste Antwort: Der Push würde abgelehnt, und ein `--force` darüber verwürfe stillschweigend Arbeit, die schon getan ist. ## Aktualisieren: immer Rebase, nie Merge Ein Feature-Branch wird **ausnahmslos per Rebase** auf den Stand seines Quellbranchs gebracht — nie per Merge. Merge-Commits aus dem Quellbranch erzeugen einen Historien-Salat, in dem später niemand mehr etwas eingrenzen kann. ```bash git fetch origin git rebase origin/main # Quellbranch; bei Child-Branches der Parent-Branch git push --force-with-lease ``` Pflicht an drei Stellen: - **mindestens einmal täglich**, solange der Branch offen ist - **bevor du neue Arbeit** an e