DrWindows
Redaktion
5 Tipps für den GitHub Frühlingsputz
von Tobias Scholze
Es ist Frühling! Für viele bedeutet es neben Heuschnupfen auch Frühjahrsputz, das Sommerauto wird poliert oder der Garten hergerichtet. Für Nerds könnte es aber auch der richtige Zeitpunkt sein, mal wieder über das eigene GitHub Profil zu gehen und dort auch einen Putz in den Frühling stattfinden zu lassen.
Auch wenn viele der folgenden Tipps eher auf öffentliche Repositories ausgelegt sind, schadet ein gewisses Reinemachen auch in unternehmensinternen Projekten wohl niemanden.
Seit wenigen Jahren erlaubt es GitHub, seine Profilseite mit einer Art Markdown Readme-Datei auszustatten, um mehr über sich selbst zu erzählen. Dieser Schritt ist völlig optional und macht keinen Unterschied, ob nun ein GitHub Profil gut oder schlecht ist, es ist schlichtweg eine Möglichkeit, den Besucher etwas über sich selbst, seiner Einstellung zur Entwicklung als auch über die eigene Motivation näher zu bringen.
Achtung: Mittlerweile existieren viele externe Dienste, welchen einem mit eingebetteten Bannern und Grafiken quasi Real-Time Statistiken zu den Repositories, deren Tickets, Releases und Co. In das Profil einbauen lassen. Leider sind solche Dienste oft nicht von langer Lebensdauer geprägt und sorgen dann bei nicht gewarteten Profilseiten oft für hässliche Platzhalterbilder. Deswegen bleibe ich bei reinem Text und maximal noch lokal auf GitHub liegenden Bildern.
Das Anpinnen von Repositories kann mehrere positive Effekte haben. Einerseits findet man selbst die für einen wichtigsten beziehungsweise am meisten benutzten Repositories gleich wieder, andererseits können diese angehefteten Projekte auch eine Art von Showcase über das eigene Können sein, welche beispielsweise bei Bewerbungen einen wohlwollenden Effekt auslösen kann. Nicht zu vergessen ist auch der Aspekt, dass wenn man bekannt ist für Projekt A und Projekt B, man es diesen Besuchern des Profils so einfach wie möglich auffindbar gestaltet.
Es ist immer das Beste, Bescheid zu wissen. Im Falle von Open Source Software und deren GitHub Repositories noch viel wichtiger, da je nach Lizenz manches erlaubt, verboten oder erzwungen wird. Auch sorgt es immer für ein angenehmes Gefühl, Readme Dateien zu lesen, wo der aktuelle Projektstand aber auch beispielsweise das, wie man den beinhalteten Quelltext bauen und ausführen kann, verständlich dargelegt wird – ohne langes Rätselraten und dann, wie leider oft, aufgeben, da irgendwas nicht will und man es ohne externe Hilfe lösen kann. Hierzu zählen Guidelines zum Project Setup, zu den eventuell benötigten API Keys oder spezielle Versionen von Visual Studio, Xcode oder Android Studio und deren Mitbringsel. Bei Repositories, welche keine fertigen Programme sind, sondern Bibliotheken für andere, sind kleine Code-Beispiele, die den Anfang erleichtern, auch sehr hilfreich. GitHub bietet hierfür extra für sehr viele Programmiersprachen entsprechende Highlighter an.
Auch ist es immer schön zu sehen, wie eine Software aussieht – falls sie denn eine Benutzeroberfläche hat. Bildschirmfotos sind zumindest für mich essentiell und werden oft noch viel zu wenig in einer entsprechenden Tiefe angesetzt.
Jedoch hilft all dies nichts, wenn der Quelltextstand die Readme oder noch schlimmer die Lizenz überholt ist. Dies sorgt nicht nur bei einem etwaigen Besucher für Ärger, sondern auch einer selbst erinnert sich eventuell ein Jahr später nicht mehr genau an all das, was man brauchte, um bei dem Projekt wieder weiter daran zu arbeiten.
Wir alle wissen, dass Zeit begrenzt ist – vor allem wenn man an manchen Projekten in der eigenen Freizeit arbeitet. Auch kann es sein, dass eine Software einfach fertig ist und man mit Absicht damit abgeschlossen hat.
Hier helfen auf GitHub Labels am Repository selbst, um dies auch nachhausen hin klipp und klar darzustellen. So zeigen die Labels “Private” und “Public” an, wer das Repository überhaupt sehen kann. Für öffentliche, also Public, Projekte wichtiger in meinen Augen ist das “Archive”-Label. Denn dies zeigt genau an, dass das Projekt fertig ist und weder Fragen noch Fehler oder sonstiges in Zukunft mehr beantwortet oder behoben werden. GitHub sagt hierzu, dass das Repository nur noch im lesbaren Zugriff zur Verfügung steht.
Diese klaren Bezeichnungen helfen dabei auf einen Blick zu erkennen, ob man beispielsweise eine gewisse Abhängigkeit, welche man gerade auf GitHub gefunden hat in sein aktuelles Projekt einbeziehen soll. Wenn es eine archivierte Seite ist, dann sollte man sich dies beispielsweise doppelt überlegen.
Vergesse niemals, dass wenn Besucher oder schlichtweg auch du ein Issue – also ein Ticket – erstellen, dass sie hierfür wertvolle Zeit und Mühe für dich aufgewendet haben. Du musst nicht mit dem Inhalt übereinstimmen, dennoch gebe Feedback, erwähne, wieso du etwas nicht so umsetzen wirst wie gewünscht oder wieso ein Fehler eines Benutzers in Wahrheit keiner ist. Schließe obsolete oder invalide Issues, so dass du auch immer eine Übersicht hast, welche Tickets denn noch relevant sind.
… zu jedem, der euch bei der Realisierung des Projektes geholfen hat. Niemand von uns ist perfekt und weiß über alles Bescheid ab dem ersten Moment. Vor allem, wenn das Repository ein Spielplatz für neue Technologien war, welche man erlernen möchte, sollte man den Menschen danken, welche uns dabei geholfen haben, in der Technologie Fuß zu fassen.
… aller nicht benötigten Features. Mittlerweile hat GitHub so viel Funktionsumfang, dass man vor allem in seiner Freizeit nur die wenigsten davon benötigt. Dies hilft nicht nur einem selbst, weniger unbenutzte und deswegen störende Schaltflächen zu haben, sondern zeigt auch anderen, welche eventuell einen Bug erstellen wollen oder nach Hilfe suchen, dass es kein Wiki gibt oder das Zeitlinien Feature in der Projects-Ansicht unbenutzt ist und eventuell falsche Hoffnung auf zukünftige Releases gibt.
… denn auch viele davon, die auf GitHub kostenfrei ablaufen, zählen diese auf gewisse Quotas wie Traffic oder der zur Verfügung stehende Datenplatz. Außerdem: Wenn du sie nicht brauchst, sollten sie auch nicht unnötig Ressourcen verbrauchen im Rechenzentrum. In meinen Augen ist es immer wie mit dem Licht in einem unbenutzten Zimmer ausschalten. Eine Glühbirne weniger macht nicht viel aus, wenn es jedoch jeden Menschen machen würde …
Nicht zu vergessen ist auch hier der Fakt, dass du immer wissen solltest, was in deinem GitHub Account passiert. Hierzu zählen nicht alle bereits erwähnten Punkte wie die Aktualität von Dateien, sondern eben auch, wo und welche Actions denn unter deinem Benutzer ausgeführt werden.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen
von Tobias Scholze
Es ist Frühling! Für viele bedeutet es neben Heuschnupfen auch Frühjahrsputz, das Sommerauto wird poliert oder der Garten hergerichtet. Für Nerds könnte es aber auch der richtige Zeitpunkt sein, mal wieder über das eigene GitHub Profil zu gehen und dort auch einen Putz in den Frühling stattfinden zu lassen.
Auch wenn viele der folgenden Tipps eher auf öffentliche Repositories ausgelegt sind, schadet ein gewisses Reinemachen auch in unternehmensinternen Projekten wohl niemanden.
Tipp #1: Erzähle etwas über dich und deine Motivation zur Entwicklung
Seit wenigen Jahren erlaubt es GitHub, seine Profilseite mit einer Art Markdown Readme-Datei auszustatten, um mehr über sich selbst zu erzählen. Dieser Schritt ist völlig optional und macht keinen Unterschied, ob nun ein GitHub Profil gut oder schlecht ist, es ist schlichtweg eine Möglichkeit, den Besucher etwas über sich selbst, seiner Einstellung zur Entwicklung als auch über die eigene Motivation näher zu bringen.
Achtung: Mittlerweile existieren viele externe Dienste, welchen einem mit eingebetteten Bannern und Grafiken quasi Real-Time Statistiken zu den Repositories, deren Tickets, Releases und Co. In das Profil einbauen lassen. Leider sind solche Dienste oft nicht von langer Lebensdauer geprägt und sorgen dann bei nicht gewarteten Profilseiten oft für hässliche Platzhalterbilder. Deswegen bleibe ich bei reinem Text und maximal noch lokal auf GitHub liegenden Bildern.
Tipp #2: Pinne für dich aussagekräftige Repositories an
Das Anpinnen von Repositories kann mehrere positive Effekte haben. Einerseits findet man selbst die für einen wichtigsten beziehungsweise am meisten benutzten Repositories gleich wieder, andererseits können diese angehefteten Projekte auch eine Art von Showcase über das eigene Können sein, welche beispielsweise bei Bewerbungen einen wohlwollenden Effekt auslösen kann. Nicht zu vergessen ist auch der Aspekt, dass wenn man bekannt ist für Projekt A und Projekt B, man es diesen Besuchern des Profils so einfach wie möglich auffindbar gestaltet.
Tipp #3: Readme und Lizenzen aktuell halten
Es ist immer das Beste, Bescheid zu wissen. Im Falle von Open Source Software und deren GitHub Repositories noch viel wichtiger, da je nach Lizenz manches erlaubt, verboten oder erzwungen wird. Auch sorgt es immer für ein angenehmes Gefühl, Readme Dateien zu lesen, wo der aktuelle Projektstand aber auch beispielsweise das, wie man den beinhalteten Quelltext bauen und ausführen kann, verständlich dargelegt wird – ohne langes Rätselraten und dann, wie leider oft, aufgeben, da irgendwas nicht will und man es ohne externe Hilfe lösen kann. Hierzu zählen Guidelines zum Project Setup, zu den eventuell benötigten API Keys oder spezielle Versionen von Visual Studio, Xcode oder Android Studio und deren Mitbringsel. Bei Repositories, welche keine fertigen Programme sind, sondern Bibliotheken für andere, sind kleine Code-Beispiele, die den Anfang erleichtern, auch sehr hilfreich. GitHub bietet hierfür extra für sehr viele Programmiersprachen entsprechende Highlighter an.
Auch ist es immer schön zu sehen, wie eine Software aussieht – falls sie denn eine Benutzeroberfläche hat. Bildschirmfotos sind zumindest für mich essentiell und werden oft noch viel zu wenig in einer entsprechenden Tiefe angesetzt.
Jedoch hilft all dies nichts, wenn der Quelltextstand die Readme oder noch schlimmer die Lizenz überholt ist. Dies sorgt nicht nur bei einem etwaigen Besucher für Ärger, sondern auch einer selbst erinnert sich eventuell ein Jahr später nicht mehr genau an all das, was man brauchte, um bei dem Projekt wieder weiter daran zu arbeiten.
Tipp #4: Liste an Repositorien mit Labels versehen
Wir alle wissen, dass Zeit begrenzt ist – vor allem wenn man an manchen Projekten in der eigenen Freizeit arbeitet. Auch kann es sein, dass eine Software einfach fertig ist und man mit Absicht damit abgeschlossen hat.
Hier helfen auf GitHub Labels am Repository selbst, um dies auch nachhausen hin klipp und klar darzustellen. So zeigen die Labels “Private” und “Public” an, wer das Repository überhaupt sehen kann. Für öffentliche, also Public, Projekte wichtiger in meinen Augen ist das “Archive”-Label. Denn dies zeigt genau an, dass das Projekt fertig ist und weder Fragen noch Fehler oder sonstiges in Zukunft mehr beantwortet oder behoben werden. GitHub sagt hierzu, dass das Repository nur noch im lesbaren Zugriff zur Verfügung steht.
Diese klaren Bezeichnungen helfen dabei auf einen Blick zu erkennen, ob man beispielsweise eine gewisse Abhängigkeit, welche man gerade auf GitHub gefunden hat in sein aktuelles Projekt einbeziehen soll. Wenn es eine archivierte Seite ist, dann sollte man sich dies beispielsweise doppelt überlegen.
Tipp #5: Lasse keine Issue versanden
Vergesse niemals, dass wenn Besucher oder schlichtweg auch du ein Issue – also ein Ticket – erstellen, dass sie hierfür wertvolle Zeit und Mühe für dich aufgewendet haben. Du musst nicht mit dem Inhalt übereinstimmen, dennoch gebe Feedback, erwähne, wieso du etwas nicht so umsetzen wirst wie gewünscht oder wieso ein Fehler eines Benutzers in Wahrheit keiner ist. Schließe obsolete oder invalide Issues, so dass du auch immer eine Übersicht hast, welche Tickets denn noch relevant sind.
Keine Top Tipps, dennoch ratsam
Sagt Danke …
… zu jedem, der euch bei der Realisierung des Projektes geholfen hat. Niemand von uns ist perfekt und weiß über alles Bescheid ab dem ersten Moment. Vor allem, wenn das Repository ein Spielplatz für neue Technologien war, welche man erlernen möchte, sollte man den Menschen danken, welche uns dabei geholfen haben, in der Technologie Fuß zu fassen.
Einfach mal abschalten …
… aller nicht benötigten Features. Mittlerweile hat GitHub so viel Funktionsumfang, dass man vor allem in seiner Freizeit nur die wenigsten davon benötigt. Dies hilft nicht nur einem selbst, weniger unbenutzte und deswegen störende Schaltflächen zu haben, sondern zeigt auch anderen, welche eventuell einen Bug erstellen wollen oder nach Hilfe suchen, dass es kein Wiki gibt oder das Zeitlinien Feature in der Projects-Ansicht unbenutzt ist und eventuell falsche Hoffnung auf zukünftige Releases gibt.
Unnötige GitHub Actions deaktivieren …
… denn auch viele davon, die auf GitHub kostenfrei ablaufen, zählen diese auf gewisse Quotas wie Traffic oder der zur Verfügung stehende Datenplatz. Außerdem: Wenn du sie nicht brauchst, sollten sie auch nicht unnötig Ressourcen verbrauchen im Rechenzentrum. In meinen Augen ist es immer wie mit dem Licht in einem unbenutzten Zimmer ausschalten. Eine Glühbirne weniger macht nicht viel aus, wenn es jedoch jeden Menschen machen würde …
Nicht zu vergessen ist auch hier der Fakt, dass du immer wissen solltest, was in deinem GitHub Account passiert. Hierzu zählen nicht alle bereits erwähnten Punkte wie die Aktualität von Dateien, sondern eben auch, wo und welche Actions denn unter deinem Benutzer ausgeführt werden.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen