Abschnittsübersicht


    • Das Vorgehen sieht dabei im Folgenden so aus:

      1. Zunächst wird ein „interaktiver“ Rebase auf den Main-Commit gemacht, von dem aus ursprünglich schon der Entwicklungs-Branch erstellt wurde. Dieser interaktive Schritt erlaubt es, alle lokalen Commits zu einem einzigen Commit zu „squashen“ und diesem Commit eine neue Commit-Message mitzugeben.
        1. In den Entwicklungsbranch gehen:
          git switch dev-branch
        2. Einen interaktiven Rebase machen und dabei die originale Base beibehalten:
          git rebase --keep-base -i main
        3. Im nun erscheinenden Editor wird das „pick“ in der ersten Zeile durch ein „r“ ersetzt, um den Commit umzubenennen. Alle anderen „pick“s werden durch ein „f“ für fixup ersetzt, um sie zu squashen:
          r e81a5f1 New commit message for the whole feature
          f 72c9e48 Some old commit message
          f 65cb164 Fix some issue
        4. Dann wird das Dokument gespeichert und GitHub sollte den Rebase+Squash durchführen.
      2. Als nächstes wird innerhalb des betroffenen Repository zum Main-Branch gewechselt und der aktuelle Stand gepullt.
        1. git switch main
          git pull
      3. Abschließend erfolgt wiederum der Wechsel in den betroffenen Entwicklungs-Branch und der Anstoß eines Rebase auf den aktuellen Commit des Main-Branches. Dabei kann es zu Merge-Konflikten kommen.
        1. In den Entwicklungs-Branch wechseln:
          git switch dev-branch
        2. Einen Rebase auf den aktuellen Main-Commit anstoßen:
          git rebase -i main
        3. Eventuelle Merge-Konflikte beheben.
        4. Den Rebase fortsetzen:
          git rebase --continue
      4. Weil der Hash des „gesquashten“ Commits älter ist, als der letzte Commit (der erste Commit wurde ja umbenannt), muss nun ein push erzwungen werden:
        1. git push --force