Versionskontrolle

Sie sind drei Dateien tief in einem Feature-Branch, noch nichts committet, als ein Kollege wegen eines Null-Pointer-Crashs in Produktion anklopft. Der übliche Weg: git stash, zu main wechseln, den Fehler fixen, pushen, dann git stash pop – und hoffen, dass nichts in Ihrer halbfertigen Feature-Arbeit von den Dateien abhing, von denen Sie gerade weggewechselt sind. git worktree macht dieses Hin-und-Her überflüssig: Es checkt den Hotfix-Branch in einen zweiten Ordner aus, neben Ihrem Feature-Branch, beide auf Basis desselben Repositorys. ...

Die Test-Suite ist seit drei Wochen grün. Heute schlägt npm test bei einer Assertion fehl, die nichts mit Ihrer letzten Änderung zu tun hat, und git log v1.4.0..HEAD zeigt 340 Commits von vier Personen seit dem letzten Release, von dem jemand sicher war, dass er funktioniert. Jeden Diff zu lesen kostet Sie einen ganzen Tag. Wahllos Commits auszuchecken geht schneller, ist aber immer noch kein Plan. git bisect macht daraus eine Binärsuche. Sie nennen ihm einen Commit, der nachweislich gut ist, und einen, der nachweislich kaputt ist; das Tool checkt den Commit in der Mitte dazwischen aus und wartet, bis Sie genau diesen Commit testen und das Ergebnis melden. Jede Antwort halbiert den Bereich. 340 Commits lassen sich in höchstens 9 Tests auflösen, denn 2^9 = 512. ...

Sie holen sich das neueste main per Pull, und Git bricht ab mit CONFLICT (content): Merge conflict in checkout.js. Sie lösen den Konflikt, und im Log steht jetzt ein Commit namens Merge branch 'main' into feature/checkout, oben auf den drei Commits, die Sie tatsächlich geschrieben haben. Vier Commits, eine einzige echte Änderung. Ein Kollege, der diese Historie nächsten Monat liest, kann nicht erkennen, welcher welcher ist. git merge und git rebase beantworten dieselbe Frage: Wie bringe ich meinen Branch auf den Stand der Änderungen, die anderswo gemacht wurden. Sie hinterlassen sehr unterschiedliche Spuren, und die falsche Wahl auf einem geteilten Branch richtet echten Schaden an. ...