Ein Durchlauf des Tutorials Auf falschem Branch commitet: wie Sie einen Commit von main auf einen Feature-Branch verschieben, mit git branch und git reset, ohne die Arbeit zu verlieren.
Dieses Szenario ist der klassische „Mist, das ist auf main gelandet"-Moment. Sie haben ein Feature direkt auf main commitet, obwohl es einen eigenen Branch hätte bekommen sollen. Die Korrektur erhält den Commit und bringt main zurück, wo es hingehört.
Die Situation
Dieser Commit ist auf dem falschen Branch gelandet. Das Ziel ist, ihn auf den richtigen zu verschieben.
main hat zwei Commits: den Initial commit und Add skills section, der index.html einen Skills-Abschnitt hinzugefügt hat. Dieser zweite Commit war für einen Feature-Branch gedacht, nicht direkt für main.
Nichts ist kaputt, aber main trägt nun unfertige Feature-Arbeit. Ziel ist es, diesen letzten Commit von main zu entfernen und auf einen Feature-Branch zu setzen, damit main wieder sauber ist.
Starten Sie mit git log --oneline. Add skills section als jüngsten Commit auf main zu sehen bestätigt genau, was Sie verschieben müssen.
Die Korrektur Schritt für Schritt
git branch feature hält den Commit auf einem neuen Branch fest.
Prüfen, was auf main ist
git log
Das Log zeigt Add skills section an der Spitze von main. Das ist der zu verschiebende Commit.
Den Commit auf einem neuen Branch sichern
git branch feature/skills
Das erstellt einen Branch-Zeiger auf den aktuellen Commit. Die Add skills section-Arbeit ist nun sicher auf feature/skills festgehalten, auch wenn Sie noch auf main sind.
main einen Commit zurücksetzen
git reset --hard HEAD~1
Das spult main vor den Skills-Commit zurück. Da der Commit bereits auf feature/skills gesichert ist, geht nichts verloren: Nur der Zeiger von main bewegt sich.
Auf den Feature-Branch wechseln und weiterarbeiten
git checkout feature/skills
Jetzt ist main sauber, und die Skills-Arbeit lebt auf ihrem eigenen Branch, bereit zur Weiterentwicklung oder für einen Pull Request.
Warum die Reihenfolge zählt
Die Sicherheit dieser Korrektur hängt komplett davon ab, den Branch vor dem Reset anzulegen:
git branch feature/skills sichert den Commit.
git reset --hard HEAD~1 bewegt dann nur noch main.
Wenn Sie zuerst git reset --hard ausführen, ohne den Branch anzulegen, bewegt sich main zurück, und der Commit ist auf keinem Branch mehr. Er ist meist noch mit git reflog rettbar, aber zuerst zu branchen vermeidet den Schreck komplett.
reset --hard schreibt Historie um. Hier ist es sicher, weil main nicht gepusht wurde. Auf einem geteilten main machen Sie es stattdessen mit git revert rückgängig.
Commits zwischen Branches verschieben: die gängigen Rezepte
cherry-pick kopiert den Commit auf den Ziel-Branch: dieselbe Änderung, ein neuer Hash.
Die Korrektur hängt davon ab, wohin der Commit soll und ob er bereits gepusht wurde:
- Auf
main commitet, will es auf einem neuen Branch (nur lokal) — git branch feature, dann git reset --hard HEAD~1 auf main. Der Commit lebt nun auf feature.
- Ihn auf einen bestehenden Branch verschieben —
git checkout target, git cherry-pick <commit>, dann ihn mit git reset --hard aus der Quelle löschen.
- Mehrere Commits verschieben — zuerst branchen, um alle zu behalten, dann
git reset --hard HEAD~N; oder einen bestimmten Bereich per cherry-pick auf den Ziel-Branch übertragen.
- Der Commit wurde bereits gepusht — schreiben Sie keine öffentliche Historie um. Machen Sie ihn auf dem geteilten Branch mit
git revert rückgängig und tragen Sie die Arbeit auf einem Feature-Branch nach.
Üben Sie den lokalen Fall hier im Terminal, bis der Reflex „branchen, dann zurücksetzen" automatisch sitzt; es ist der, zu dem Sie am häufigsten greifen.