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 Maskulinum7 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