blog · git · desktop · images · contact & privacy · gopher


Git-Kollaboration für kleine Projekte, reloaded

Okay. Meine Projekte sind umgezogen. Ein paar Dinge funktionieren jetzt also anders. Aber wie? Wie erstellt man jetzt einen „Pull-Request“? Wie reicht man Bug-Reports ein? Wie prüft man auf bereits bekannte Bugs?

Bitte beachten, dass ich hier nur von sehr kleinen Projekten spreche. Größere Projekte müssen sich vielleicht etwas anderes überlegen. Und natürlich ist das nur meine subjektive Sicht der Dinge. Feedback ist willkommen, falls ich hier etwas übersehe oder falls sich manche Problemfelder auf ähnlich einfache Art und Weise besser lösen lassen.

Den Code und dessen Historie anschauen

Ich benutze derzeit stagit, um die Repositories im Browser anzeigtbar zu machen. Das ist ein kleines leichtgewichtiges Programm, aber dafür fehlen auch ein paar Features. Man kann sich zum Beispiel nicht die Historie einzelner Dateien anzeigen lassen. Man kann Dateien auch nicht „raw“ betrachten – da sind immer Zeilennummern und ein kleiner Header oben.

Die Antwort ist ganz einfach: Klone das Repository auf deine Maschine.

Kleine Projekte haben üblicherweise wenig Code. Die zu klonen, ist dann eine Sache von Sekunden. Wenn man das getan hat, kann man die Git-Tools der Wahl lokal auf seinem Rechner benutzen, ohne weiteren Netzwerkoverhead zu haben.

Genervt davon, dass das die Festplatte mit haufenweise Repos zumüllt? Dann wird’s vielleicht Zeit für einen Shell-Alias dieser Art:

mt()
{
    mkdir -p -- "$@" && cd -- "$@"
}

alias ttr='mt /tmp/r/$(date -Iseconds)'

Die ganzen „temporär geklonten Repos“ sind dann nach einem Reboot wieder weg.

Bug-Reports und bekannte Fehler

Es gibt jetzt keinen traditionellen „Bug-Tracker“ mehr, aber Bugs gibt es natürlich weiterhin im Code. Wenn welche bekannte sind, dann enthält das Projekt eine Datei namens BUGS. Dort stehen sie drin.

Wenn du einen neuen Bug melden willst, den du gefunden hast, dann schreibe mir einfach eine E-Mail. Entweder fixe ich den Bug dann oder füge ihn zu BUGS hinzu.

Um ehrlich zu sein, halte ich es auch für die bessere Lösung, Bugs in einer Datei im Repo zu tracken. Ich glaube, dass das für kleine und auch mittlere Projekte eine gute Idee ist. Das Repository ist dann eher autark. Solange man das Repo hat, hat man auch automatisch eine Historie aller Bugs.

Mit so einem üblichen Bug-Tracker ist man immer geneigt, Dinge wie „siehe Bug #3“ in die Commit-Messages zu schreiben. Den Fehler habe ich gemacht. Jetzt ist mein alter Bug-Tracker weg und diese ganzen Links wie „siehe #3“ sind tot. Das stinkt.

Natürlich gibt es einen zeitlichen Versatz zwischen deiner E-Mail mit dem Bug-Report und meinem Commit in die BUGS. Ich bin mir sicher, dass das bei meinen winzigen Projekten kein Problem ist. Bei größeren Projekten will man vielleicht doch eine Mailingliste haben.

Patches schicken

Okay, jetzt hast du das Repo geklont. Und jetzt?

Hat sich eigentlich nicht viel verändert. Du erstellst einen neuen Branch:

git checkout -b my-feature

Und machst dort dann deine Commits. Genau wie vorher.

vi foo.c
vi bar.c
git commit -av

Dann gibt es eine Reihe von Optionen. Die einfachst ist vermutlich, Patch-Files daraus zu erzeugen. Das geht mit einem Befehl:

$ git format-patch master
0001-remove-stuff.patch
0002-break-everything.patch

Dann schickst du mir diese Dateien, zum Beispiel per E-Mail, und wir können darüber reden.

Das sind aber eben keine reinen Patches. Da sind oben ein paar besondere Zeilen drin mit Metadaten, die dann automatisch von Git ausgewertet werden, wenn ich die Patches mit git am anwende. Allem voran steht dort deine Identität drin; du wirst also nach wie vor sauber als Autor deiner Änderungen in der finalen Git-Historie genannt.

Wenn du auf der anderen Seite einen eigenen Server hast, kannst du auch dein geklontes Repo dort hosten und mir einen Link dahin schicken. Git ist dezentral und ich kann Änderungen direkt von deinem Server laden.

Meh, ist das nicht einfacher, eine Git-Hosting-Plattform zu benutzen?

Ja und nein.

Ja, weil du es vermutlich so kennst. Du weißt schon, wie das alles auf $PlattformA und $PlattformB funktioniert. Dein Gehirn ist dann geneigt, zu vergessen, dass da doch irgendwie „Arbeit“ mit im Spiel ist.

Nein, weil es naiv ist, so zu denken. Für jedes Projekt da draußen musst du Zeit investieren. Du musst das Projekt kennenlernen. Es ist nie so, dass du einfach nur eine Datei editierst, ein paar Knöpfe in einem Webinterface drückst und dann einen Pull-Request einreichst. Nagut, das kannst du schon so machen, aber dann stehen deine Chancen gut, dass dein PR abgelehnt wird. Du musst immer erst den Code-Style im Projekt kennenlernen (auch wenn es da Bestrebungen gibt, zumindest dieses Problem zu lösen), du musst nach einem Contribution-Guide schauen, diesen dann lesen und verstehen, du musst die Lizenz des Codes verstehen, vielleicht sollst du für deine Änderungen ja auch gleich noch Tests schreiben und so weiter. Herauszufinden, wie man einen Patch einreicht, ist nur ein winziger Teil dieses ganzen Prozesses.