blog · git · desktop · images · contact
2018-06-23
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.
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.
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.
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.
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.