Philip Withnall
philip.withnall@collabora.co.uk 2015
Quellcode-Versionsverwaltung mit Git
Mario Blättermann
mario.blaettermann@gmail.com 2016, 2018
Christian Kirbach
christian.kirbach@gmail.com 2016, 2020
Stefan Melmuk
stefan.melmuk@gmail.com 2018
Tim Sabsch
tim@sabsch.com 2021

# Versionsverwaltung

#

        Zusammenfassung

        Git ist das Versionskontrollsystem aller GNOME-Projekte. Auf dieser Seite nehmen wir an, dass Sie bereits gute praktische Erfahrungen mit git besitzen. Einführungsmaterialien finden Sie hier, ein Cheatsheet finden Sie außerdem hier.

          Erstellen Sie atomare, reversible Commits. ()
          Nehmen Sie alle Hintergründe in die Commit-Nachrichten auf, einschließlich Verweise auf Fehlerberichte und Spezifikationen. ()
          Stecken Sie große Änderungen wie Umbenennungen in separate Commits. ()
          Führen Sie Änderungen aus Feature-Branchen durch Rebasen zusammen. ()

# Verwendung von Git

Die meisten GNOME-Repositories folgen diesen Regeln:

Keine erzwungenen Pushes. Mit Ausnahme von Branches mit dem `wip/`-Präfix (»Work in Progress«) darf der Commit-Verlauf nicht geändert werden, da sich Mitwirkende darauf verlassen.

Rebasen Sie Commits eher als Mergen, um die History linear zu halten (welcher einfacher zu folgen ist)

Arbeiten Sie im GNOME-git mit Feature-Branches (`wip/`-Präfix), rebasen Sie anschließend auf dem master-Branch und führen Sie die Änderungen mit einem fast-forward-Merge zusammen. Es hat sich ebenfalls bewährt, dass Sie Ihren Nutzernamen in der Form `wip/nickname/feature` zum Branch hinzufügen.

Verstecken Sie Ihre Wurstherstellung, indem Sie Commits vor dem Merge zusammenlegen (»squash«).

# Richtlinien für Commits

Commits sollten so klein wie möglich sein, aber nicht kleiner. Jeder Commit sollte ein einzelnes Problem adressieren und nur dazu unmittelbar relevante Änderungen enthalten. Die Commit-Nachricht sollte das Problem beschreiben, die Ursache erklären sowie die Lösung aufzeigen, sofern diese nicht offensichtlich ist. Bezieht sich der Commit auf einen Fehlerbericht, sollte in der letzten Zeile der Commit-Nachricht die vollständige URI des Berichts stehen. Ebenso sollte die Commit-Kennung (zu erhalten mittels git log --oneline) in den Fehlerbericht kopiert werden, sobald der Commit hochgeladen wurde.

Die Änderungen in jedem Commit sollten einfach zu lesen sein. Zum Beispiel sollten keine unnötigen Änderungen an den Leerzeichen oder Einrückungen enthalten sein. Große, mechanische Änderungen wie das Umbenennen einer Datei oder Funktion sollten in einem eigenen Commit separat von inhaltlichen Änderungen am Code in der Datei oder Funktion stattfinden, damit letztere nicht verloren gehen.

Die folgenden Prinzipien erklären die soeben aufgezeigten Ratschläge:

Jeder Commit überträgt das Repository von einem funktionierenden Zustand in einen anderen. Anderenfalls ist Bisection unmöglich.

Jeder Commit sollte in sich reversibel sein. Sollte sich später herausstellen, dass der Commit keine gute Idee war, sollte ein git revert commit ID das Repository von einem funktionierenden Zustand in einen anderen übertragen.

Die Hintergründe jedes Commits und seine Beziehungen zu externen Ressourcen wie Spezifikationen und Fehlerberichten sollten klar sein. Ein Entwickler sollte noch ein Jahr später in der Lage sein zu verstehen, was ein anderer Entwickler gemacht hat, ohne sich durch alle Änderungen wühlen zu müssen.

Jeder Commit sollte einmalig geschrieben und dann vielfach gelesen werden können, von vielen Reviewern und künftigen Entwicklern.

# Merge-Prozess

Um einen Feature-Branch namens `my-branch` in den master-Branch zu mergen, verwenden Sie die folgenden Befehle:

git checkout master git pull

git checkout wip/my-branch git rebase --interactive master # Ensure the rebase is successful; test the changes

git checkout master git merge wip/my-branch git push

# wip/my-branch can now be deleted git push origin :wip/my-branch git branch -D wip/my-branch

# Externe Links

Git best practices

Git FAQ

Atlassian git tutorial

Offizielles Git-Tutorial

Interaktives Git-Tutorial

Tutorial zu git-tower