Kursthemen

  • Starthilfe

    Alles einklappen Alles aufklappen
    Was erwartet mich in diesem Kurs?

    Dieser Kurs fokussiert in aller Kürze, wie vor der Erstellung eines Pull Requests in GitHub ein "Rebase" durchgeführt werden kann und warum dies sinnvoll ist.

    Der Kurs gliedert sich in folgende zwei Abschnitte:

  • Warum "Rebase"?


    Bei der Arbeit an einem Feature für ein Moodle-Plugin entstehen in der Regel mehrere Commits innerhalb des Entwicklungs-Branches, mindestens im lokalen Repository. Diese Entwicklungsschritte sind für das finale Einpflegen des Features in das Plugin oft nicht relevant. Zeitgleich ist der Main-Branch während der Entwicklung des Features auch oft schon weitergewachsen.

    Für einen anstehenden Pull-Request empfiehlt es sich daher, den Entwicklungs-Branch von dem ursprünglich Commit des Main-Branches weg und auf den aktuellen Commit zu „rebasen“ und dabei die einzelnen Entwicklungs-Commits zu einem einzigen Feature-Commit zusammenzustauchen („squash“).

  • How to...


    • 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