Aufgaben abgeben können mit Git
Ziel
- Ich besitze allererste Kenntnisse über die Git-Versionsverwaltung
- Ich besitze die technischen Voraussetzungen dafür, bearbeitete Aufgaben bei der Tutor_in einreichen zu können
Hintergrund
Git? Was soll das?
Hier geht es um das Versionsverwaltungssystem Git (oft auch klein geschrieben: git). Ein Versionsverwaltungssystem (engl. Version Control System, VCS) verwaltet Dateien, an denen im Laufe der Zeit Änderungen gemacht werden, und speichert viele solche Versionen samt der Urheber und Zeitpunkte der Änderungen.
Das VCS ist das zentrale Werkzeug für die Softwareentwicklung im Team: Andere Teammitglieder können sich jederzeit die jüngsten Änderungen aller anderen aus dem VCS holen, sie eventuell prüfen, und dann übernehmen (das ist der Normalfall) oder auch nicht. Auf diese Weise können alle zusammenarbeiten, ohne sich dabei nennenswert gegenseitig unterbrechen zu müssen.
Ähnlich hier im ProPra: Sie müssen alle ihre Einreichungen in einem Git "repository" (so heißt die Versionsablage für ein Projekt; kurz meist "repo") speichern, wenn Sie sie einer Tutor_in vorlegen möchten. Die Tutor_in ruft Ihre Abgabe vom Git-Server ab, prüft sie und speichert dann das Prüfergebnis auch wieder in Ihrem Git-Repository.
Der Server dient dabei nur zum Übermitteln von einer Benutzer_in zur anderen, alles andere passiert lokal auf dem eigenen Rechner. Deshalb braucht jede_r, der mit einem Git-Repo arbeitet, eine Kopie des Repos auf dem eigenen Rechner.
Wie benutzt man Git?
Git ist ein Kommandozeilenprogramm. Es gibt auch GUIs (separat und in Entwicklungsumgebungen), die die Verwendung der wichtigsten Kommandos erleichtern, aber um Git richtig zu verstehen und um seine fortgeschrittenen Funktionen zu nutzen, braucht man die Kommandozeile.
Git ist extrem leistungsfähig, aber es kommt oft auf Details an. Bitte sorgfältig lesen und arbeiten, sonst kann es schnell frustrierend werden.
Für den Server nutzt man entweder einen öffentlichen Dienst wie GitHub, GitLab oder BitBucket, oder man betreibt selbst eine Serversoftware wie GitLab oder Gitea.
Wir werden einen GitLab-Server benutzen, den der Fachbereich Mathematik und Informatik betreibt: https://git.imp.fu-berlin.de.
Hier gibt es nur reines Bedienwissen für die Einreichung von Aufgabenergebnissen; das Verständnis dazu und alles Weitere lernen Sie später im Kapitel über Werkzeuge. Die Aufgabenblöcke (vor allem der erste) zu Git gehören zum Wertvollsten, was Sie aus dem ProPra mitnehmen können; lassen Sie sich diese Aufgaben bitte nicht entgehen!
Wir bearbeiten jetzt folgendes:
- Installieren und Konfigurieren von Git auf Ihrem System.
- Einrichten und Konfigurieren Ihres persönlichen ProPra-Git-Repositorys zum Einreichen Ihrer ProPra-Abgaben.
- Anlegen der lokalen Kopie des Repos
- Erlernen der nötigen Git-Befehle zum Einreichen der Abgaben:
add,commit,push,pull.
Eine ganze Menge Schritte also, aber keine Sorge: Diese Aufgabe führt Sie präzise hindurch.
Arbeitsschritte
Installieren von Git
Starten Sie Ihre Kommandozeile (Ihre "Shell").
Probieren Sie das Kommando git. Ist es vorhanden?
Dann ist die Installation schon erledigt und Sie brauchen nichts zu tun.
Andernfalls:
- Auf Windows/WSL und in Debian/Ubuntu Linux:
sudo apt-get install git.
Dabei bedeutetsudodie Ausführung eines Kommandos mit Administratorrechten. Deshalb müssen Sie dafür gelegentlich ihr Passwort eingeben.
apt-getist der Paketmanager, mitinstallinstalliert er ein Softwarepaket.
gitist der Name des gewünschten Pakets; es gibt davon Tausende. - Auf Mac: Eine der Möglichkeiten von https://git-scm.com/download/mac aussuchen und durchführen. Am einfachsten geht die installation über Xcode oder Homebrew
Hier wie überall im ProPra gilt: Wenn etwas nicht klappt und hier nicht erläutert ist, führt eine Web-Suche schnell zu den nötigen Informationen. Bitte fleißig nutzen – aber vorher stets gründlich die Aufgabenstellung lesen; oft stehen sehr wohl alle nötigen Informationen drin.
Konfigurieren von Git
Damit in den von Ihnen erzeugten Versionen brauchbare Autoreninformation steht, müssen Sie bei git hinterlegen, wer Sie sind. Setzen Sie in folgenden Kommandos Ihre eigenen Daten ein und führen Sie sie aus:
1 2 | |
Git legt diese Information in der Datei .gitconfig in Ihrem Homeverzeichnis ab.
Sollten Sie sich nicht sicher sein, wo das ist, können Sie sich das mittels echo $HOME anzeigen lassen.
Erstellen des eigenen ProPra-Projekt-git-Repositorys
Der Fachbereich betreibt einen eigenen GitLab-Server, auf dem Sie sich nun Ihr ProPra-Repository
anlegen.
Besuchen Sie https://git.imp.fu-berlin.de und melden Sie sich mit Ihren Zedat-Logindaten
an.
Betätigen Sie die Schaltfläche "New Project" und dann "Create blank project".
Nennen Sie Ihr Projekt möglichst "propra" (als project name und als project slug).
Lassen Sie die Voreinstellungen "Visibility Level: Private" und "Initialize repository with a README"
wie sie sind und lassen Sie den Eintrag für "group or namespace" leer.
Betätigen Sie "Create Project".
Glückwunsch: Ihr Git-Repository existiert nun auf dem GitLab-Server!
Nun werden Sie auf die Seite des Projektes weitergeleitet und können sehen,
dass GitLab für Sie eine Datei README.md angelegt hat.
Warum heißt das überhaupt Projekt und nicht einfach Repository? Weil GitLab noch viele weitere Funktionen rund um ein Repository anbietet, die eigene Datenbestände haben. Das ganze Bündel heißt Projekt.
Den Tutor_innen Zugriffsrechte geben
Momentan ist Ihr Repository einzig für Sie änderbar. Das reicht für die Zwecke des ProPra jedoch nicht aus: Wenn Sie bei der Tutor_in Aufgaben zur Überprüfung einreichen wollen, muss die Tutor_in das Repo auf den eigenen Rechner abrufen können und nach der Kontrolle eine Datei darin speichern können, die die erfolgreiche Abgabe bestätigt.
Dafür müssen wir nun auf dem Server dem Repository Lese- und Schreibrechte für
alle Tutor_innen dieses ProPras zufügen.
Deren Benutzernamen finden Sie in der Datei course.json
im Abschnitt instructors jeweils im Eintrag gitaccount.
Rufen Sie in GitLab auf Ihrer ProPra-Projektseite im linken Menü den Eintrag
"Settings" auf. Darin den Eintrag "General".
Nun rechts im Bereich "Visibility, project features, permissions"
die Schaltfläche "Expand" (denn die Einstellungen für Permissions
(Erlaubnisse), suchen wir ja).
Folgen Sie nun dem Link "project members" (und merken Sie sich diese
notorisch schwierig zu findende Stelle).
Nun geht es weiter mit der Schaltfläche "Invite members" oben rechts. Jetzt können wir (für jede Tutor_in einzeln) die oben als "gitaccount" gesehenen Benutzernamen angeben und als Rolle jeweils "Developer" auswählen, was eine Rolle mit (eingschränkten, aber für unseren Zweck ausreichenden) Schreibrechten ist. Auslaufdatum geben wir keines an.
Nun müssen wir noch den (einzigen) Zweig main des Repos
von geschützt auf normal umstellen.
Navigieren Sie wie folgt:
Settings / Repository / Protected Branches / main.
Dort betätigen Sie die Schaltfläche "unprotect" und bestätigen.
Nun können alle zuständigen Tutor_innen bei Bedarf die nötigen Bestätigungen in Ihr Repo einpflegen. Wieder ein Schritt geschafft!
git clone: Klonen des Projekts
Nun legen wir ein sogenanntes "Arbeitsverzeichnis" (work directory) für unser Repo auf dem lokalen Rechner an.
Dazu gehen wir auf die GitLab-Seite unseres Projekts, klicken oben rechts auf den Knopf "clone" und kopieren die Adresse unter "Clone with HTTPS".
Danach öffnen Sie eine Kommandozeile und navigieren in einen Ordner, in den Sie das Repo kopieren möchten.
Wir gehen in weiteren Aufgaben gelegentlich davon aus, dass dieser Ordner
~/ws/propra heißt.
Dabei steht ~ für Ihr Heimatverzeichnis,
ws für "workspaces" und
propra für den Namen, den Ihr Repo auf dem Server hat.
Legen Sie also jetzt ~/ws an (mkdir ~/ws) und gehen Sie dorthin (cd ~/ws).
Der letzte Teil des Pfads entsteht beim git clone-Befehl.
Führen Sie nun git clone aus in der Form
git clone https://mygitserver.mydomain/myusername/mypropra.git.
Das sieht beispielsweise so aus:
git clone https://git.imp.fu-berlin.de/prechelt/propra.git
Wenn Sie nicht "Clone with HTTPS" ausgewählt haben werden Sie mit großer Sicherheit einen Fehler über fehlende Berechtigungen erhalten, beim Versuch das Repo zu klonen. Sollten Sie sich mit git bereits etwas auskennen und in Gitlab schon ihren SSH-Schlüssel hinterlegt haben, können Sie natürlich auch die SSH Methode zum Klonen verwenden.
In diesem neuen Ordner befindet sich ein verborgener Unterordner mit dem namen .git.
Hier speichert Git das Repo und viele Zusatzinformationen über seine Benutzung.
Wenn man hierin manuell Änderungen macht oder gar Dateien löscht,
wird das Repo meist nicht mehr richtig funktionieren,
was selbst für Git-kundige Menschen sehr ärgerlich ausgehen kann.
Wechseln Sie nun in den durch clone entstandenen Projektordner (cd propra),
um die erste Änderung durchzuführen und danach zum Server hochzuladen.
git status: Einen Überblick bekommen
Git verfolgt, was sich im Arbeitsverzeichnis ändert.
Geben Sie git status ein, um sich das anzusehen.
Aktuell wird die Ausgabe sehr leer aussehen, aber Sie sollten den Status regelmäßig abfragen und die Ausgabe studieren.
git status benutzt man während der Arbeit häufig, um sich in Erinnerung zu rufen,
was schon alles an (Zwischen-)Ergebnissen aufgelaufen ist.
git add, git commit: Änderungen am Projekt speichern
Bearbeiten Sie die README.md folgendermaßen.
- Löschen Sie den kompletten existierenden Inhalt
- Fügen Sie eine Überschrift "Programmierpraktikum" hinzu
- Notieren Sie darunter Ihren Namen und das laufende Semester
Hinweise zum Formatieren von Markdown-Dateien finden Sie beispielsweise in der GitLab-Dokumentation.
Wenn Sie jetzt erneut git status aufrufen, werden Sie feststellen, dass sich etwas zu vorher verändert hat.
Sie sollten einen Hinweis darüber haben, dass die README.md verändert wurde und diese Änderungen "not staged for commit" sind.
Das bedeutet, dass die Änderungen in der Form noch nicht Teil des Repos sind. Das Eintragen von Änderungen jeder Form im Repo wird als "commit" (Festschreibung) bezeichnet.
Damit Git weiß, welche Dateien "committet" werden sollen, müssen wir diese zuvor
auf eine Art Schmierzettel (genannt der "Index") eintragen.
Das geht mittels git add.
In unserem Fall also: git add README.md (Nutzen Sie automatische Vervollständigung mithilfe der Tab-Taste).
Nachdem das getan wurde, sollte git status nun ausgeben, dass die Änderungen Teil des nächsten Commits sind. Es bietet sich an, vor Abschluss eines Commits immer zu prüfen, ob dieser alles beinhaltet, was Sie erwarten.
Es kann passieren, dass wir an einer Datei zwei Änderungen gemacht haben, davon aber eigentlich nur eine einchecken wollen. Das ist möglich; siehe spätere Aufgaben zu git.
Ganz wichtig bei einem Commit ist eine hilfreiche Commit-Nachricht, eine meistens einzeilige Notiz, die im Commit verankert ist und später hilft, nachzuvollziehen, was der Inhalt und der Zweck des Commits ist.
Hier im Programmierpraktikum gehört dazu beispielsweise stets der Name der Aufgabe,
zu der der Commit gehört, ganz egal, ob die Aufgabe damit schon abgeschlossen ist oder nicht.
Eine solche Nachricht kann man mit dem Parameter -m für message angeben.
Das könnte bei uns also etwa so aussehen:
1 | |
Ohne die Option würde ein Editor gestartet, über den man dann auch längere Commit-Nachrichten angeben könnte. Das behandeln wir später.
Nach Ausführen dieses Befehls sollte git status wieder so aussehen wie vor Ihren Änderungen.
Seien Sie vorsichtig mit git add!
Wenn Sie eine Datei committen, die gar nicht in die Versionshistorie gehört,
ist es sehr schwierig, die dort wieder vollständig loszuwerden.
git log: Commit-Historie ansehen
Die Commit-Nachrichten sind vor allem wertvoll, um sich schnell einen Überblick zu verschaffen,
was auf einem Repo alles passiert ist; bei Teamarbeit hat man das ja nicht alles selbst gemacht.
Dazu dient git log.
Rufen Sie das ohne weitere Parameter auf und studieren Sie sorgfältig die Ausgabe.
Man sieht für jeden Commit, wer ihn wann gemacht hat – und die Commit-Nachricht als
Beschreibung, worum es dabei ging.
Schlechte Commit-Nachrichten sind eine Plage; bitte machen Sie stets informative!
git push: Neue Commits zum Server hochladen
Zu guter Letzt müssen wir diese Änderungen noch zum Git-Server schicken.
Dazu nutzen wir ganz einfach den Befehl git push, ohne weitere Zusätze.
Git wird sie nun nach ihren Zugangsdaten fragen und dann alle neuen Commits (die es auf dem
Server noch nicht gibt) hochladen.
Studieren Sie auch hier wieder die Ausgabe von Git (vieles davon müssen Sie nicht verstehen).
Gehen Sie auf den Server und überzeugen Sie sich dort, dass Ihr neuer Commit dort angekommen ist.
git push und git pull (siehe unten) können einem auf die Dauer ganz schön auf die Nerven gehen,
wenn man keinen ssh-agent laufen hat. Den richten wir später ein, in TODO_2 PARTREF::SshAgent.
git pull: Neue Commits vom Server herunterladen
Manchmal ist es auch umgekehrt: Es gibt auf dem Server neue Commits, die lokal noch nicht vorhanden sind. Das passiert hier im ProPra in mehreren Fällen:
- Sie arbeiten abwechselnd auf mehreren Rechnern, die jeder eine lokale Kopie des Repos haben.
- Sie haben Aufgaben bei der Tutor_in eingereicht und diese_r hat einen Akzeptanz-Commit zugefügt und zum Server hochgeladen.
- Ihre ProPra-Partner_in hat etwas hochgeladen, das Sie nun zu sich abrufen, um es Ihrerseits zu einem eigenen Commit zuzufügen, beispielsweise ein Programm, das Sie beide identisch abgeben. (Hinweis: Bei allen Abgaben, die normalsprachlicher Text sind, sollen Sie stets eine eigenständige Fassung machen.)
Abgabe
Die Abgabe besteht aus der modifizierten README.md.