GitHub – Eine praktische Einführung. Anke Lederer
rel="nofollow" href="#fb3_img_img_3e43ac26-f62d-5814-8da5-a51a5234c3b2.png" alt="image"/>
Abbildung 3-21: Die Identifikationsnummer (ID) eines Issues ist in der Issue-Übersicht zu finden.
Sobald du die richtige ID angegeben hast, speicherst du wie vorher auch. Jetzt ist aber noch etwas Bemerkenswertes passiert. Wenn du in die Issue-Übersicht wechselst, siehst du, dass der Issue weg ist?! Ja und nein, der Issue ist nicht weg, sondern wurde automatisch geschlossen. Der Standardfilter sorgt dafür, dass nur offene Issues angezeigt werden, daher kannst du ihn nicht mehr sehen (erinnere dich an Kapitel 2, Abschnitt »Informationen finden (interessierte Anwenderin)« auf Seite 13, hier hatte ich die beiden Standardfilter is:issue is:open bereits erklärt). Wenn du den Filter veränderst, um dir die geschlossenen Issues anzeigen zu lassen, siehst du den bearbeiteten Issue wieder. Klickst du nun den entsprechenden Issue noch mal an, bekommst du ein paar weitere Informationen, beispielsweise dürfte dort so etwas Ähnliches stehen wie:
DeinUsername closed this in 7a0eeb2 2 minutes ago
Dabei ist die komische kryptische Zeichenkette (in meinem Fall 7a0eeb2) mit einem Link versehen. Diese Zeichenkette ist die sogenannte Commit-ID. Jeder Commit, den du machst (oder andere machen), hat eine eigene ID, um die einzelnen Commits voneinander unterscheiden zu können. Später im Kapitel zu Git (siehe Kapitel 7) werden wir der ID erneut begegnen.
Commit-ID
Die Commit-ID bei Git/GitHub besteht aus einem sogenannten SHA-1-Hash. Es handelt sich dabei um einen Algorithmus, der aus einer Eingabemenge eine 40 Zeichen lange Ausgabemenge produziert. Das heißt, hinten kommen immer 40 Zeichen raus – egal wie groß die Eingabemenge ist.
Das entscheidende Feature dabei ist, dass die exakt gleiche Eingabe auch immer die exakt gleichen 40 Zeichen erzeugt. Das hat den Vorteil, dass man dadurch relativ schnell sehen kann, ob zwei Commits identisch sind oder nicht. Git/GitHub bildet einfach mit zwei Commit-Eingabemengen (Inhalt, Datum etc.) den Hash-Wert, und wenn dieser gleich ist, sind beide Commits identisch.
Da 40 Zeichen ziemlich lang sind, um sie ständig anzuzeigen oder auch noch ständig irgendwo einzutippen, verwendet man in der Regel nur die ersten sieben bis zwölf Zeichen. Diese sind meist eindeutig genug.
Du kannst Issues auch manuell schließen, indem du in dem Issue ganz nach unten scrollst und den Button Close issue (deutsch »Issue schließen«) anwählst (siehe Abbildung 3-22). Das ist natürlich nicht ganz so toll wie das automatische Schließen, aber manchmal gibt es Issues, die einfach nicht gelöst werden – beispielsweise weil irgendeine Besucherin ein völlig abgefahrenes Feature über einen Issue bei dir eingekippt hat, das du nicht in dein Projekt aufnehmen möchtest. Sollte so etwas der Fall sein, schreibe in den Kommentar, warum du den Issue nicht umsetzen wirst, und zwar nicht nur, weil es höflicher ist, es erhöht auch die Chance, dass die Menschen weiterhin Issues anlegen (so du das denn möchtest). Nichts ist frustrierender, als ohne Begründung »abserviert« zu werden.
Abbildung 3-22: Issues kann man auch manuell schließen.
|
|
Gelöste Issues schließen Es ist gute Praxis, gelöste Issues zu schließen. Du behältst dadurch die Übersicht, und potenzielle Contributoren versuchen sich nicht an einer Lösung und verbraten Zeit. |
Issues mithilfe von Schlüsselwörtern automatisch schließen
GitHub bietet die Möglichkeit, Issues über Schlüsselwörter zu schließen. Die Schlüsselwörter sehen dabei wie folgt aus:
close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved
Sobald in einem Commit eines dieser Schlüsselwörter mit einer Referenz auf den Issue eingegeben wird (#ISSUE_NR), wird dieser Issue geschlossen. Man kann auch mehrere gleichzeitig schließen, dafür muss aber vor jeder Referenz eines der Schlüsselwörter stehen, also etwa fixes #1, fixes #2.22
Man kann auch Issues in anderen Repositories schließen, vorausgesetzt, man hat die entsprechenden Berechtigungen. Das geht mit einem der Schlüsselwörter und als Referenz USERNAME/REPONAME#ISSUE_NR.
Du weißt nun, wie man Issues anlegt, sie labelt und jemandem zuweist. Als cooles neues Zusatzwissen kannst du jetzt auch Issues automatisch schließen lassen, wenn du mit bestimmten Schlüsselwörtern bei einem Commit arbeitest.
Eventuell hast du bereits ein oder mehrere Repositories zum Testen und Rumspielen angelegt. Um deinen Account wieder etwas aufzuräumen, zeige ich dir im nächsten Abschnitt, wie du ein Repository löschen kannst.
Ein bestehendes Repository löschen
Das Löschen eines bestehenden Repositorys ist relativ einfach, aber auf den ersten Blick etwas furchteinflößend, wir müssen nämlich dafür in die Danger Zone (also in den »Gefahrenbereich«), siehe Abbildung 3-23. Gehe auf dein zu löschendes Repository und wähle Settings aus. Um in die Danger Zone zu kommen, musst du ganz nach unten scrollen. Achte darauf, dass im linken Menü Options ausgewählt ist (sollte beim Anklicken von Settings standardmäßig der Fall sein).
Abbildung 3-23: In der Danger Zone werden alle gefährlichen Aktionen eines Repositorys gebündelt.
In der Danger Zone wähle den Button Delete this repository (deutsch »Lösche dieses Repository«) aus. Es erscheint eine Warnmeldung, die dich dazu auffordert, den Namen deines Repositorys nach dem Muster USERNAME/REPONAME einzutippen, bevor du die Löschung mit Klick auf den Button I understand the consequences, delete this repository (deutsch etwa »Ich verstehe die Konsequenzen, lösche dieses Repository«) bestätigen kannst (siehe Abbildung 3-24). Das ist ein Sicherheitsmechanismus, damit du dein Repository mit all seinem Inhalt (Dateien, Issues, Kommentare, Wiki etc.) nicht aus Versehen löscht.
Abbildung 3-24: Als Sicherheitsmechanismus ist zur Löschung der Name des Repositorys vorher einzugeben.
Jetzt weißt du, wie du überflüssige und eventuell auch verbastelte Repositories löschen kannst. Als Nächstes (und Letztes