Versionsverwaltung in der Softwareentwicklung
Versionskontrolle mit git
Versionsverwaltungen werden speziell in der Softwareentwicklung eingesetzt. Mit deren Hilfe kann die Zusammenarbeit im Team gesteigert, Projekte verwaltet und Code überprüft und erweitert werden. Eine Versionsverwaltung ist vor allem dann sinnvoll, wenn meherere Personen auf die gleichen Dateien zugreifen und diese bearbeiten. Versionsverwaltungssysteme koordinieren den gemeinsamen Zugriff auf auf Dateien und protokollieren alle Änderungen im Laufe der Zeit. Die beiden bekanntesten Versionsverwaltungssysteme sind GitHub und Bitbucket. GitHub und Bitbucket sind somit Plattformen, die das Organisieren von Software-Projekten erleichtern. Diese beiden Plattformen benutzen eine spezielle Software Namens Git.
Es gibt viele verschiedene Wege Git zu benutzen. Sowohl GitHub als auch Bitbucket verfügen über mehrere Grafische Benutzeroberflächen. Allerdings ist es auch möglich den Code über spezielle Konsolen zu verwalten.
Heutzutage werden weitestgehend die Versionsverwaltungs-Programme Git und Apache Subversion (SVN) benutzt. Es gibt weitere Versionskontroll-Systeme wie Mercurial, Bitbucket oder Azure DevOps Server uvm. Wir beschäftigen uns in diesem Tutorial ausschließlich mit git.
Systeme zur Versionskontrolle erfassen Änderungen von mehreren Entwickler (parallele Entwicklung) in einem Projekt oder an einer Datei und protokollieren zudem wer, wann, was geändert hat. Änderungen werden also mit einem Zeitstempel, einer Benutzerkennung und einer Beschreibung verknüpft
Grundlagen - GUI oder CLI
Grafische Benutzeroberfläche oder Befehlszeile
Git kann entweder über grafische Benutzeroberflächen oder mit Hilfe spezieller Git-Konsolen, also über die Kommandozeile, benutzt werden.
Es gib eine Vielzahl grafischer Git-Benutzeroberflächen auf dem Markt. In den meisten Fällen unterscheiden sich GUIs (engl. Graphical User Interface) in Bezug auf Funktionalität und Anzahl der bereitgestellten Git-Befehle. Sie haben somit unterschiedliche Fähigkeiten.
Befehlszeilenschnittstellen (CLI, engl. Comman Line Interface). haben den Vorteil, dass alle verfügbaren Git-Befehle ausgeführt werden können. Deshalb benutzten wir Git über eine CLI.
Der Gebrauch einer Konsole kann praktisch sein um die Arbeit damit schneller zu erledigen. Der Nachteil dabei ist, dass du dich mit dem Thema auseinandersetzen musst, um die benötigten Befehle kennen zu lernen. Die wenigen Befehle, welche zum initialisieren, committen, branching usw. benötigt werden, sind jedoch schnell erlernt.
Grafische Benutzeroberflächen
Weiterführende Tutorials
Konfiguration - Git einrichten
Zunächst teilst du Git deine Benutzerdaten mit. Dies ist notwendig, damit commits mit deinem Benutzernamen versehen werden. Arbeitet man mit mehreren Personen an einem Projekt, ist es sinnvoll zu wissen wer welche Änderungen vorgenommen hat.
$ git config --global user.name "<Name>"
$ git config --global user.email "<E-Mail>"
Neues Git Repository anlegen
Um ein Git Repository auf einem lokalen Rechner anzulegen, musst du lediglich in das gewünschte Verzeichnis wechseln und dort den init Befehl ausführen, woraufhin ein Unterverzeichnis .git erstellt wird, welches ein Git Repository Grundgerüst enthält.
$ git init
Existierendes Repository klonen
Um ein existierendes Repository zu klonen, um zum Beispiel an einem bestehenden Projekt teilzunehmen, verwende den Befehl git clone. Durch diesen Befehl lädt Git alle Daten aus einem lokalen oder entfernten Repository auf einen Rechner herunter.
// Kopie eines lokalen Repositorys
$ git clone /pfad/zum/repository
// Kopie eines entfernten Repositorys
$ git clone [url]
Die URL kann aus der jeweiligen Repository kopiert werden. Nachdem du ein neues Repository angelegt, bzw. ein existierendes Repository geklont hast, kannst du Änderungen vornehmen.
Grundlegende Befehle
Änderungen einer speziellen Datei dem Index hinzufügen | git add <Dateiname> |
Änderungen aller Dateien dem Index hinzufügen | git add * |
Änderung bestätigen und kommentieren | git commit –m <"Kommentar"> |
Werden alle geänderten Dateien hinzugefügt, kann der git add Befehl übersprungen werden | git commit -a –m <"Kommentar"> |
Status abfragen | git status |
Kompakte Anzeige des Status | git status -s |
Zeigt alle Veränderungen in einzelnen Schritten an | git diff |
Nachdem ein git add ausgeführt wurde, können Dateien durch ein git reset für den anschließenden commit ausgeschlossen werden | git reset <file> |
Die Option --hard bewirkt, dass lokal geänderte Dateien überschrieben werden | git reset --hard origin/master |
Änderungen an Repository senden* | git push <Branch> |
Aktualisiert das lokale Repository mit den neuesten Änderungen (kein merge!) | git fetch |
Zusammenführen von Branches ** | git merge <Branch> |
Aktualisiert das lokale Repository mit den neuesten Änderungen *** | git pull |
* Hast du noch keine neuen Branches angelegt, befindest du dich standartmäßig im master Branch.
** Beim Zusammenführen von Branches kann es zu Konflikten kommen. Das geschieht häufig, wenn mehrere Personen Änderungen an der gleichen Datei vorgenommen haben. Git versucht diese Konflikte selbst zu lösen. Falls es fehlschlägt werden die entsprechenden Stellen markiert und man muss diese manuell korrigieren. Anschließend muss erneut ein git pull ausgeführt werden.
*** Der Befehl git pull führt zunächst ein git fetch und anschließend ein git merge aus.
Branches
Branches kann man sich als unabhängige Entwicklungslinien vorstellen. Änderungen an einem Projekt können in einem neuen Branch durchgeführt und anschließend durch ein merge wieder zusammengefügt werden. Im Laufe der Zeit haben sich folgende Branch-Namen in Git durchgesetzt:
master, develop, release
Vorhandene Branches anzeigen lassen | git branch |
Neuer Branch erstellen | git branch <Name> |
Branch löschen | git branch -d <Branch> |
Wechselt in den angegebenen Branch | git checkout <Branch> |
Erstellen eines neuen Branches, auf dem lokalen Rechner | git checkout -b <Branch> |
Staching
Stashes werden verwendet um Änderungen auf dem Stack zu verstauen. Häufig wird der Befehl git stash (eng.: to stash = unterbringen) verwendet, um Änderungen abzulegen bzw. zu speichern, die allerdings noch nicht bereit für einen commit sind. Es können mehrere Stashs angelegt, unabhängig darauf zugegriffen und somit die Arbeit fortgesetzt werden.
verstaut Änderungen auf dem Stack, um später weiter daran arbeiten zu können | git stash |
legt einen stash an und verpasst diesem ein Nachricht | git stash save <"message"> |
um an zuvor verstauten Änderungen weiter arbeiten zu können. Der Stash bleibt allerdings auf dem Stack vorhanden | git stash apply |
gleiche Funktion wie git stash apply mit dem Unterschied, dass der Stash vom Stack gelöscht wird | git stash pop <id> |
Entfernt einen bestimmten Stash vom Stack | git stash drop <id> |
Löscht alle Stashs | git stash clear |
Sonstige Befehle
Schließt eine Datei für folgende commits aus. Sie wird nicht mehr versioniert | git update-index --assume-unchanged <path/file> |
Zeigt Informationen über alle angelegten Branches an | git remote show <Branch> |
.gitignore-File
In der .gitignore Datei sind alle Dateien und Verzeichnisse aufgeführt, die nicht versioniert werden sollen. Bei der Arbeit im Team und der Benutzung einer Versionsverwaltung muss bzw. soll nicht das gesamte Projekt im Repository abgelegt werden. Seien es Dateien mit unverschlüsselten Passwörtern, temporäre Dateien oder ganze build-Verzeichnisse, all diese haben hier nichts verloren. Alleine der Größe wegen, sollte man beim commiten und pushen achtgeben. Einen Build kann schließlich jeder auf seinem lokalen Rechner erstellen.
Ignoriert Dateien mit dem Dateinamen file.exe | file.exe |
Ignoriert alle Dateien mit der Dateiendung .exe | *.exe |
Ignoriert das gesamte Verzeichnis | /build/ |
Ausnahme: Die Datei file.txt wird nicht ignoriert | !file.txt |