Читать книгу GitHub – Eine praktische Einführung - Anke Lederer - Страница 6

Vorwort

Liebe Leserin, lieber Leser,

schön, dass du hier bist! Warum ist dieses Buch entstanden? Als ich anfing, mich mit GitHub zu beschäftigen, war ich zunächst erschlagen von der Plattform. Ich fragte mich, wo und wie ich einsteigen sollte und was überhaupt wichtig sei. Ich habe daraufhin versucht, die unzähligen Quellen, die einen leichten Einstieg versprochen haben, zu durchforsten, um eben diesen Einstieg zu bekommen. Ich habe brillante Tutorials und grottenschlechte Videos gefunden und viel Zeit damit verbracht, die Infos zu filtern und nach Nützlichkeit zu sortieren.

Gewünscht hätte ich mir einen kompakten Einstieg, der an einer Stelle alles für eine Anfängerin Relevante zusammenfasst und erklärt – ohne einen neuen, unbekannten Fachbegriff in unverständlichem Fachchinesisch. Am liebsten wäre mir ein Buch gewesen, das mich an die Hand nimmt und mir schrittweise zeigt, was wichtig ist, wo ich was finde und wie das alles eigentlich geht. Das gab es aber in dieser Form nicht. Also habe ich versucht, eine möglichst praktische und hoffentlich verständliche Einführung zu schreiben, und du hast sie gerade vor deiner Nase.¹

Ist dieses Buch das richtige für mich?

Du bist hier richtig, wenn du dich bei der einen oder anderen nachfolgenden Beschreibung wiederfinden kannst:

 Du programmierst in deiner Freizeit gern Apps und suchst einen Weg, um sie zu veröffentlichen. Vielleicht möchtest du sogar zusammen mit deinen Freunden gemeinschaftlich an einer App arbeiten.

 Du warst schon immer fasziniert von Open Source und hast dich stets gefragt, wie und wo man solche Projekte eigentlich unterstützen kann. Zudem fragst du dich, ob man dafür zwingend programmieren können muss.2

 Du benutzt schon lange eine App und möchtest die Entwicklerinnen und Entwickler über einen Fehler, der dich nervt, informieren. Beim Klicken auf Fehler melden bist du auf einer GitHub-Seite gelandet und bist erst einmal nicht weitergekommen. Das wurmt dich, und du möchtest es ändern.

 Du hast schon einmal versucht, dich mit GitHub auseinanderzusetzen, aber das war dir dann doch alles zu kompliziert. Du möchtest jetzt gern einen neuen Versuch starten und erhoffst dir, endlich wirklich zu verstehen, wie das alles läuft und warum Pull-Requests nicht Push-Requests heißen.3

 Du möchtest eigentlich nur wissen, wo und wie du den Quellcode zu einer bestimmten Software herunterladen kannst.4

 Du benutzt GitHub schon eine Weile, aber bis auf ein wenig Geklicke auf der Weboberfläche hast du dich noch nicht viel damit beschäftigt. Jetzt möchtest du intensiver einsteigen und vor allem auch dieses ominöse Git ausprobieren.

 Du benutzt Git schon eine Weile und möchtest jetzt die Funktionen von GitHub kennenlernen.

Ich habe dieses Buch primär für Anfängerinnen und Anfänger geschrieben, die sich entweder noch gar nicht oder erst ein bisschen mit GitHub beschäftigt haben. Profis hingegen werden inhaltlich vermutlich nicht viel Neues finden.

Ich setze voraus, dass du auf deinem Computer mit dem Betriebssystem deiner Wahl (beispielsweise Windows, macOS, Linux etc.) auf Anwendungsniveau zurechtkommst. Du kannst z.B. einen Browser öffnen und eine Webseite aufrufen, Software installieren, ein Verzeichnis anlegen sowie Dateien erstellen und kopieren.

Für wen ist dieses Buch nicht geeignet?

Für wen ist dieses Buch vermutlich nichts?

 Du möchtest dich intensiv mit Git beschäftigen und in die tiefsten Tiefen abtauchen, GitHub interessiert dich - wenn überhaupt - nur am Rande. Git werden wir jedoch nur relativ oberflächlich behandeln. Leseempfehlungen für einen tieferen Einstieg gebe ich in Kapitel 7, Abschnitt »Sich weiter schlaumachen über Git« auf Seite 160.

 Deine erste Aktivität nach dem Frühstück ist es, alle eingegangenen Pull-Requests zu überprüfen und ein paar Merges durchzuführen, bevor du dir nach dem Mittag alle neuen Issues anschaust und zur Kaffeezeit überlegst, ob nicht mal ein neuer Branch fällig wäre.

 Du bist für dein Unternehmen auf der Suche nach einem Werkzeug, das das gemeinschaftliche Arbeiten unterstützen soll. Dafür interessieren dich die businessrelevanten Informationen, z.B. welche Business-Features GitHub anbietet, wie man es selbst hosten könnte und ob sich der Business Case rechnet.

 Du liebst knallharte IT-Fakten und findest es albern, wenn man versucht, IT anhand von Beispielen, Bildern oder Vergleichen zu erklären.5

 Du findest Fußnoten nervig.6

Da GitHub eine lebende Plattform ist, kann es sein, dass sich nach Druck des Buchs schon wieder einiges geändert hat. Buttons könnten an einer anderen Stelle sein, vorgestellte GitHub-Projekte (auch Repositories oder kurz Repos genannt, übersetzt »Aufbewahrungsort«) nicht mehr existieren oder verwaist sein oder neue Features zur Verfügung stehen. Das sollte allerdings kein Problem sein, da dieses Buch die grundlegenden Prozesse beschreibt, sodass du dich mit diesem Wissen auch auf einer veränderten Benutzungsoberfläche zurechtfinden solltest. Ich werde im Verlauf dieses Buchs die Begriffe Projekt und Repository synonym verwenden.

Der Leser oder die Leserin?

Ich persönlich bin ein großer Fan davon, alle Menschen gleichermaßen mit einzubeziehen, weswegen ich das generische Maskulinum⁷ für nicht mehr zeitgemäß halte. Um Konstruktionen wie »Mein_e Leser_in, der_die mein Buch liest« oder »Mein*e Leser*in, der*die mein Buch liest« zu vermeiden, werde ich je nach Kontext entweder eine Beidnennung vornehmen (»Leserinnen und Leser«), das Gendersternchen (»Leser*innen«), das generische Maskulinum (»der Leser«) oder das generische Femininum (»die Leserin«) verwenden, gemeint sind damit immer alle Geschlechter.

Wie ist dieses Buch zu lesen?

Manche Menschen lesen ein Fachbuch von vorne bis hinten durch, andere springen in die Kapitel, die für sie attraktiv klingen. Ich habe dieses Buch so konzipiert, dass ein blutiger Anfänger es von vorne nach hinten durchlesen sollte. Sofern du bereits etwas Erfahrung hast, kann ein »Kapitel-Hopping« eventuell sinnvoll sein, beispielsweise wenn du schon weißt, wie man mit einem eigenen Projekt auf GitHub umgeht, und nur wissen willst, wie du Open-Source-Projekte, die du unterstützen möchtest, finden kannst. Dann ist es eventuell durchaus sinnvoll, in das entsprechende Kapitel zu springen. Ich persönlich empfehle aber ein vollständiges, lineares Lesen, und das nicht nur, weil ich mir so viel Mühe gemacht habe:).

Dieses Buch enthält viele Links auf andere GitHub-Repositories und Websites. Da einige davon aufwändig abzutippen sind, findest du sie, um dir die Recherche zu erleichtern, auch in diesem Repository auf GitHub: https://github.com/githubbuch/githubbuch.github.io (siehe auch Abbildung 1).

Abbildung 1: Alle Links in diesem Buch sind in dem Repository https://github.com/githubbuch/githubbuch.github.io zu finden.

Konventionen in diesem Buch

Ich weiß nicht, wie es dir geht, aber immer wenn ich in einem Buch die Abschnittsüberschrift »Konventionen« lese, überspringe ich das Kapitel am liebsten, weil meist nichts Spannendes drinsteht. Insofern halte ich es kurz.

Wir werden teilweise auf der Konsole arbeiten (unter Windows häufig auch Eingabeaufforderung genannt, siehe Abbildung 1). Das werde ich folgendermaßen darstellen:

$ ls

datei.txt

Wenn ich exemplarisch Eingaben auf der Konsole zeigen möchte, also etwas, was du so nicht eins zu eins eintippen solltest, wähle ich Großbuchstaben:

$ vi DATEINAME

Abbildung 1: Die Konsole ist im Gegensatz zu einer grafischen Schnittstelle eine textbasierte Schnittstelle zum Betriebssystem und ermöglicht einen direkten Zugriff auf Betriebssystemressourcen und Programme.

Hier soll der Texteditor vi mit einer Datei deiner Wahl gestartet werden, DATEINAME dient als Platzhalter. Wer mit der Konsole und deren Ausgaben noch nicht gearbeitet hat, für den habe ich extra einen Abschnitt geschrieben (siehe Kapitel 7, Abschnitt »Exkurs: Umgang mit der Konsole« auf Seite 139).

Konsolenbefehle oder Ausschnitte aus Code-Beispielen im Fließtext, werden in Listingschrift dargestellt. URLs, E-Mail-Adressen, Dateinamen oder Dateierweiterungen sind in Kursivschrift formatiert.

Tipps, Anmerkungen und alles, was ich für hervorhebenswert halte, kommen in folgende schnuckelige Kästen:

Tippkasten In einem solchen Kasten werde ich wichtige Hinweise, Tipps, Tricks und Best Practices kurz hervorheben, die meiner Meinung nach hilfreich und/oder interessant sein könnten.

Stolperfallen und alles, was das Leben schwerer machen könnte, wenn man es nicht kennt und beachtet, werde ich in solche Kästen schreiben:

Stolperfallenkasten In einem solchen Kasten werde ich Stolperfallen kenntlich machen.

Für längere Erklärungen gibt es die »Erklärbärbox«:

Erklärbärbox

In diese Boxen kommen längere Erläuterungen zu einem bestimmten Thema, die den Lesefluss im »normalen« Text stören würden. Falls dich das Thema nicht interessiert oder du darüber schon gut Bescheid weißt, kannst du diese Boxen einfach überspringen.

Alles, was meiner Ansicht nach den Lesefluss stören würde, werde ich in Fußnoten packen: beispielsweise Webadressen, Details, die für das weitere Verständnis nicht unbedingt wichtig sind, und auch persönliche Kommentare.

Danksagung

Danksagung sind für Leser*innen häufig öde, daher mache ich es kurz und schmerzlos:

 Als Erstes möchte ich meinem Mann Rüdiger danken, der mich während des Schreibens oft genug aus meinem Schreibtunnel hervorlocken oder aber meine Begeisterung für irgendwelche fachlichen Details ertragen musste.

 Weiterer Dank gebührt meinen ganzen Querleser*innen, die das Buch in Teilen gelesen und mir Feedback gegeben haben: Henry Hillje, Alina Robbers, Halil Ege, Jan Schnedler und (wieder) Rüdiger.

 Dann gab es noch ein paar Verrückte, die das Buch als Ganzes gelesen und mir ebenfalls sehr hilfreiches Feedback gegeben haben: Julia Barthel, Florian Diedrich, Sven Riedel, Nina Siessegger und Ayleen Weiß. Dank eurer Unterstützung sind noch einige Praxistipps eingeflossen, konnte ich einige Unklarheiten ausräumen und habe zudem meinen wortreichen Schreibfluss etwas im Zaum gehalten ;-).

 Danke auch an meine Lektorin Ariane Hesse, die (hoffentlich) alle Stolpersteine gefunden und dadurch dieses Buch zu einem besseren gemacht hat.

 Nicht vergessen möchte ich Christina Czeschik und Matthias Lindhorst, beide Autor*innen des Buchs Weniger schlecht über IT schreiben, die mich durch ihr Buch überhaupt erst dazu inspiriert und motiviert haben, selber ein Buch zu schreiben. Danke dafür!

 Danken möchte ich auch der Open-Source-Community. Ohne die unermüdliche Unterstützung dieser Menschen wäre die (Software-)Welt eine ärmere. Ich werde daher ein Teil des Bucherlöses an einige Open-Source-Projekte spenden.

Git als Unterstützungstool für dieses Buch Dieses Buch ist mithilfe von Git erstellt worden. Dafür habe ich 882 Commits auf dem master-Branch durchgeführt.