GitHub – Eine praktische Einführung. Anke Lederer
andere Aktivitäten bilden.
Für das Anlegen eines eigenen Projekts gibt es mehrere Möglichkeiten. Wir wenden uns mit dem Plussymbol oben rechts in der Ecke im GitHub-Menü zunächst der offensichtlichsten zu (siehe auch Abbildung 3-6) und wählen New repository.
Abbildung 3-6: Ein neues Repository kann man unter anderem über das Plussymbol oben rechts erzeugen.
|
|
Tipp: Shortcut für neue Repositories Eine weitere Möglichkeit, Repositories anzulegen, bietet die Webadresse https://repo.new im Browser. Dann bist du direkt auf der GitHub-Seite für neue Repositories. Das funktioniert natürlich nur, wenn du bereits eingeloggt bist, ansonsten landest du erst mal auf der Log-in-Seite. |
Nun werden wir aufgefordert, eine Reihe von Angaben zu machen (siehe Abbildung 3-7). Gib deinem Projekt einen sprechenden Namen – das kann auch so etwas Originelles wie »testprojekt« sein – und, wenn du magst, eine entsprechende Beschreibung. Alles lässt sich später noch ändern.
Abbildung 3-7: Ein neues Projekt/Repository ist mit wenigen Klicks erstellt.
Beim Erstellungsprozess wirst du auch gefragt, ob du ein öffentliches (Public) oder ein privates (Private) Repository anlegen möchtest. Öffentliche Repositories können später von jedem beliebigen Besucher angesehen, aber nur mit Erlaubnis verändert werden. Auf private Repositories hast dagegen ausschließlich du Zugriff. Wenn du für ein Repository einen Collaborator festlegst, kann dieser Veränderungen vornehmen und natürlich auch alles sehen, selbst wenn das Repo als privat eingestellt ist. Wir sind hier mal mutig und wählen Public aus.
|
|
Tipp: Test-Repositories anlegen Wenn du dich erst einmal nur mit GitHub und dessen Funktionen vertraut machen möchtest, empfiehlt es sich, ein oder mehrere Repositories zum Testen und Rumspielen anzulegen. Diese kannst du nach deinen Experimenten wieder löschen (siehe Abschnitt »Ein bestehendes Repository löschen« auf Seite 39 weiter unten in diesem Kapitel). |
Zudem wirst du gefragt, ob GitHub für dich eine README.md anlegen soll (wir erinnern uns an Kapitel 2, Abschnitt »Informationen finden (interessierte Anwenderin)« auf Seite 13). Da das generell eine gute Idee ist, machen wir das natürlich. Alles andere kannst du erst einmal so lassen, wie es ist. Sobald du auf Create Repository geklickt hast, erstellt GitHub automatisch ein Repository mit einer noch recht leeren README.md und allen Möglichkeiten, die GitHub so bietet – beispielsweise dem Anlegen von Issues.
Wichtig zu wissen: Wir werden im Verlauf des Buchs ausschließlich auf public Repositories arbeiten. Sollte irgendeine Funktion, die ich dir vorstelle, nicht funktionieren, könnte es eventuell daran liegen, dass dein Repository privat ist. GitHub stellt viele Features für öffentliche Repos kostenlos zur Verfügung. Will man die gleichen Features in privaten Repos nutzen, funktioniert das nur nach Einwurf kleiner Münzen.
Eine inhaltliche Änderung am Projekt vornehmen
Als Erstes befüllen wir die README.md. Gehe dazu auf <> Code, falls du nicht schon dort bist. Auf der rechten Seite des Screenshots siehst du ein Stiftsymbol (siehe Abbildung 3-8). Das Symbol zeigt generell an, dass Dateien editiert werden können. Über das Stiftsymbol gelangst du in einen Texteditor, in dem du die README.md mit Inhalt füllen kannst.
Wie du in Abbildung 3-9 sehen kannst, bietet der Texteditor zwei Optionen an: Edit file (Datei editieren) und Preview changes (die Vorschau der Änderungen). Standardmäßig bist du im Modus Edit file, in dem du deine Änderungen machen kannst. Der Modus Preview changes bietet dir eine Vorschau der aktuellen Änderungen an, ohne dass du sie abspeichern musst. Dann lass uns die Datei mal mit Leben füllen. Wie bereits erwähnt, kannst du für die Formatierung der Datei das sogenannte Markdown verwenden. Du könntest zum Beispiel Folgendes eintippen:11
# Mein wunderbares Projekt
Dies hier ist mein **erstes Projekt**, um *GitHub* auszuprobieren.
## Meine To-dos:
- [x] README.md befüllen
- [ ] Andere Dinge ...
Abbildung 3-8: Durch Anwählen des Stiftsymbols kann man die Datei in einem Editor bearbeiten.
Abbildung 3-9: GitHub bietet einen Texteditor mit den Modi »Bearbeiten« und »Vorschau« an.
Spiel ruhig ein bisschen damit herum, Anregungen findest du in der Erklärbärbox »README.md« in Kapitel 2.
Über die Vorschaufunktion kannst du jederzeit überprüfen, ob das Ganze so aussieht, wie du es dir vorgestellt hast. Wenn du zufrieden bist mit deinem Werk, möchtest du es natürlich abspeichern. Die Möglichkeit dazu findest du, wenn du nach unten scrollst (siehe Abbildung 3-10). Aber hoppla, da steht ja gar nicht speichern, da steht irgendwas von »Commit« und »Branch«. Wir merken uns erst einmal: Commit ist so etwas wie speichern und fügt die Änderungen zum Projekt hinzu. Später, wenn wir mit Git arbeiten werden (siehe Kapitel 7), werden wir sehen, dass das nicht ganz korrekt ist. Für den Augenblick reicht es aber, die beiden Begriffe gleichzusetzen.
Abbildung 3-10: Abspeichern von Änderungen nennt man bei GitHub »Commit«.
Was den Branch anbelangt, lassen wir zunächst die Standardeinstellung stehen (Commit directly to the master branch., zu Deutsch etwa »direkt auf dem Hauptzweig speichern«). Wir werden später sehen, was es damit auf sich hat (siehe Kapitel 4). Was du noch befüllen solltest, ist die Commit-Nachricht (die Textfelder). Netterweise macht uns GitHub bereits einen Vorschlag für den Titel der Commit-Nachricht, den du erst einmal so übernehmen kannst.