Softwareentwicklung im Team erfordert ein System zur Versionskontrolle. git gilt heute als Standard. Mit github stellt Microsoft Server zur Verfügung. Eine Alternative, die auch in der Schule eingesetzt werden kann, ist z. B. gitea, das als Server auf eigenen Rechnern installiert werden kann.
In git wird ein Verzeichnis mit allen darin enthaltenen Unterverzeichnissen und Dateien unter Versionskontrolle gestellt. Ein solches Verzeichnis nennt man repository, es stellt eine zusammenhängende Einheit dar und sollte alle zum Projekt gehörenden Dateien enthalten.
Den Kern stellen die Quellcode-Dateien des Software-Projektes dar. Der Zweck von git und github (bzw. gitea) beschränkt sich im Wesentlichen auf das Entwickeln von Quellcode, der mithilfe von Texteditoren erstellt wird. Die Repositories sind weniger geeignet zum Speichern und Teilen großer Datenmengen, umfangreichen Medien-Inhalte, Office-Dokumente und Anwendungsprogramme sollte man über andere Cloud-Systeme verwalten.
Nach der Installation von git sollte man als allererstes seinen Namen und seine E-Mail-Adresse in Git konfigurieren. Das ist insofern wichtig, da jeder Git-Commit diese Informationen verwendet. Damit ist später im Team nachvollziehbar, wer welche Änderungen im Repository vorgenommen hat.
git config --global user.name "<Name>"
git config --global user.email <Mail>
Beispiel:
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
Die git Konfiguration kann man anzeigen lassen mit dem Befehl
git config --list
Ein Verzeichnis erstellen und unter Versionskontrolle stellen:
git init <repo>
Beispiel:
git init test
erzeugt ein Unterverzeichnis test und stellt dieses unter Versionskontrolle.
Eine lokale Kopie eines entfernten Repositories erstellen:
git clone <repo>
Das entfernte Repository wird über eine URL adressiert.
Beispiel:
git clone https://github.com/kwollw/wbinf2024.git
erzeugt eine lokale Kopie des Repositories.
Textdateien, die mit einem Texteditor erstellt oder verändert wurden, durchlaufen mehrere Stadien der Versionskontrolle.
Dateien werden mit einem Texteditor erstellt oder bearbeitet und gespeichert. git registriert in der Datenbank des repositories, welche Dateien geändert oder hinzugefügt wurden.
Aus der Liste der geänderten Dateien wird eine Auswahl für einen sogenannten Commit vorgemerkt. Dieser Zustand heißt staged.
git add <file>
merkt eine Datei in dem aktuellen Verzeichnis für den nächsten Commit vor.
Beispiel:
git add myfile.html
fügt die Datei myfile.html zu der Liste der vorgemerkten Dateien hinzu.
Dateien auf der Stage werden commited. Damit wird ein Versionsstand (snapshot) festgehalten, auf den man zu einem beliebigen späteren Zeitpunkt zurückgreifen kann. Alle commits werden mit einem Kommentar versehen, sodass man aus der Liste der commits ggf. zielgerichtet einen früheren Zustand auswählen kann. Mit der Liste der Commits hat man einen Überblick über den Entwicklungsprozess und es ist ersichtlich, welche Mitglieder des Teams welche commits erstellt haben.
Ein commit erstellen:
git commit -m "comment"
Beispiel:
git commit -m "typos removed"
erstellt einen commit mit dem Kommentar typos removed
Dateien mit der Endung .md sind sogenannte Markdown-Dateien. Markdown ist eine vereinfachte Auszeichnungssprache, die eine formatierte Ausgabe mithilfe weniger Auszeichnungszeichen erlaubt.
Im Team zusammenarbeiten heißt, Zustandsänderungen des gemeinsamen Repositories so zu verwalten, dass Inhalte über ein Cloud-Repository ausgetauscht werden. Dabei ist es erforderlich, dass Änderungen an denselben Dateien so behandelt werden, dass Bearbeitungs-Konflikte vermieden bzw. zielgerichtet gelöst werden.
Das gemeinsame Repository (origin) befindet sich auf einem zentralen Server, z.B. bei github oder auf dem gitea-Server.
Kopien (local) werden als Clone auf dem lokalen Rechner erstellt. Änderungen nimmt man in der Regel auf dem lokalen Repository vor.
Zur Synchronisierung der Änderungen ist zu bedenken, dass Mitglieder des Teams unabhängig voneinander Änderungen an ihren lokalen Kopien vornehmen.
Nach einem Commit muss dieser auf das gemeinsame Repository (origin) übertragen werden. Zuvor sollte man aber Änderungen von origin in das lokale Repository übernehmen. Mit einem pull werden Änderungen von origin bezogen (fetch) und in das lokale Repository eingefügt (merge).
git pull
Der merge-Prozess fügt nicht nur neue Dateien ein oder löscht diese. Partielle Änderungen von Dateien werden so zusammengefügt, dass local changes und remote changes innerhalb der Datei zusammengefügt werden.
Voraussetzung für einen konfliktfreien Pull ist, dass alle lokalen Änderungen commited sind.
Mit einem push werden lokale Änderungen auf das gemeinsame Repository (origin) übertragen und eingefügt (merge).
git push
Auf dem Server werden mit dem push die commits auf die gleiche Weise mit einem merge eingefügt, wie bei einem pull auf dem lokalen repository.
Branches stellen unabhängige Entwicklungspfade dar. Für eine spezielle Aufgabe kann man einen branch erstellen, der die ursprüngliche Version (main oder master) nicht verändert. Zu einem späteren Zeitpunkt kann man die commits aus einem Branch in den main-Branch übertragen (merge) oder auch wieder verwerfen.
Lassen sich commits nicht automatisch mergen, muss ein merge-Konflikt bearbeitet und gelöst werden.
Visual Studio Code hat eine Integration von git, mit der die git-Befehle direkt aus VSCode ausgeführt werden können.
GitHowTo is a guided tour that walks through the fundamentals of Git.