Versionskontrolle mit Git in Visual Studio Code

Weil das Versionskontrollsystem Git Stand heute (2019) das meist verwendete Versionskontrollsystem der Welt ist, sehen wir uns an, wie wir unsere Projekte damit verwalten können. Allerdings ist das hier keine allgemeine Git-Einführung, sondern ein Blick auf den Umgang mit Git in Visual Studio Code. Das funktioniert nämlich erstaunlich gut.

Voraussetzung

VS Code verwendet die auf dem Computer installierte Git-Version. Ob eine installiert und welche das im Zweifel ist, lässt sich mithilfe des Kommandos

git --version

Im Terminal herausfinden. Wenn Git nicht vorhanden sein sollte, lässt es sich recht einfach über einen Download von der offiziellen Download-Seite laden.

Initialisieren eines Git-Repositorys aus Visual Studio Code heraus.

Initialisierung

Wir öffnen unser fizzbuzz-Projekt, mit dem wir bereits die testgetriebene Entwicklung ausprobiert und auch die virtuelle Umgebung eingerichtet haben. Darin finden wir neben unseren selbstprogrammierten Dateien „FizzBuzz.py“ und „TestFizzBuzz.py“ sowie unserer „requirements.txt“ mit den Abhängigkeiten auch die Verzeichnisse „fizzbuzz_venv“ und „__pycache__“ sowie das versteckte Verzeichnis „.vscode“ und die versteckte Datei „.coverage“.

Zunächst aktivieren wir unsere virtuelle Umgebung. Öffnen wir in VS Code ein neues Terminal, führt die IDE den Befehl für uns aus und aktiviert praktischerweise die virtuelle Umgebung von sich aus.

Das sollte immer unsere erste Tat sein. Wollte man das Aktivieren per Terminal ausführen, lautete der Befehl:

source fizzbuzz_venv/bin/activate

Auf der linken Seite finden wir unter dem Knopf für den „Explorer“ und dem Knopf für die Suche den Knopf für „Source Control“, die Versionskontrolle. Drückt man diesen erhält man den Hinweis „No source control providers registered.“; es ist keine Versionsverwaltung eingerichtet. Darüber ist ein Plus-Symbol zu sehen. Klickst du darauf, erscheint von oben ein Feld mit dem Eintrag: „Pick workspace folder to initialize git repo in“. Nun hat man die Möglichkeit, in dem bereits ausgewählten Verzeichnis „fizzbuzz“ ein Git-Repository einzurichten oder ein anderes Verzeichnis („Choose Folder …“) auszusuchen. Wir bestätigen die Wahl des „fizzbuzz“-Verzeichnisses.

Kurze Zeit später erscheint eine scheinbar unendliche Liste von Dateinamen hinter denen ein grünes „U“ für „Untracked“ zu sehen ist. Dies bedeutet, dass sich diese Dateien innerhalb des von Git überwachten Verzeichnisses befinden, aber bisher nicht von Git überwacht werden. Nun ist es Zeit, sich Gedanken darüber zu machen, welche Dateien Teil des Repositorys sein sollen.

Was soll Teil des Repositorys sein?

In meinem Fall weist mich Git darauf hin, dass es insgesamt 2717 Dateien sind, die Git nicht überwacht. Darunter sind Dateien und Verzeichnisse, die du nicht ins Repository einbinden solltest. Beispielsweise ist die versteckte Datei „.coverage“ eine automatisch erstellte, die für den Zeitpunkt der Erstellung gültig war. Jemand, der das fizzbuzz-Repository in Zukunft lädt, kann mithilfe des coverage-Moduls die Testabdeckung selbst erstellen.

Das versteckte Verzeichnis „.vscode“ enthält unsere VS-Code-Einstellungen, diese sind für andere Programmiererinnen und Programmierer wahrscheinlich nicht passend, denn die haben eigene Präferenzen.

Die Verzeichnisse „fizzbuzz_venv“ und „__pycache__“ sind ähnliche Fälle, denn in der virtuellen Umgebung sind rechnerspezifische Pfade erfasst, die für andere Rechner mit womöglich anderen Betriebssystemen unpassend sind. Der zweite Ordner beherbergt Dateien, die Python zwischengespeichert hat, auch dieser hat auf Systemen anderer Anwenderinnen und Anwender nichts verloren.

Dagegen sind unsere selbstprogrammierten Dateien „FizzBuzz.py“ und „TestFizzBuzz.py“ unbedingt Teil des Repositorys. Auch unsere „requirements.txt“ gehört ins Repository, damit andere Programmiererinnen und Programmierer anhand der darin erfassten Abhängigkeiten unsere Umgebung nachstellen können – siehe virtuelle Umgebung einrichten.

Wie können wir nun sagen, welche Verzeichnisse und Dateien Git überwachen soll? Hierfür erstellen wir eine Datei namens „.gitignore“ und schreiben darin, was Git ignorieren soll.

Wir klicken auf das Explorer-Symbol und klicken auf das Symbol für „New File“, das sich einblendet, wenn du die Maus über das „fizzbuzz“-Verzeichnis bewegst. Das Icon ist ein Blatt Papier mit einem Plus oben links. Nach einem Klick auf dieses Symbol erstellt VS Code eine neue Datei und erwartet von uns, dass wir diese Datei benennen. Wir nennen sie „.gitignore“.

Hierin schreiben wir untereinander:

fizzbuzz_venv

__pycache__

.vscode

.coverage

Es empfiehlt sich auch betriebssystemspezifische Dateien in „.gitignore“ aufzunehmen, wie beispielsweise .DS\_Store für macOS und Thumbs.db für Windows.

Sichern wir nun unsere gefüllte „.gitignore“-Datei, so steht neben dem Source-Control-Symbol nun nur noch die Zahl „4“. All die anderen Dateien ignoriert Git von nun an und das ist auch sinnvoll.

Die Dateien sind in Staged und wir geben unsere Commit-Message ein, bevor wir den Commit bestätigen.

Unser erster Commit

Wir wollen nun den Stand unseres Projektes einmal sichern, wir wollen also einen Commit schreiben. Teil unseres Commits sind die bisher nicht von Git überwachten Dateien „.gitignore“, „FizzBuzz.py“, „TestFizzBuzz.py“ und „requirements.txt“.

Fährt man in der Source-Control-Ansicht mit der Maus über eine dieser Dateinamen, so blendet VS Code unter anderem ein Plus-Symbol ein. Mit einem Klick darauf machen wir die jeweilige Datei zu einem Teil des folgenden Commits. Nach dem Klick wechselt die Datei aus dem Status Changes in Staged Changes. Wir könnten eine Datei daraus auch entfernen, indem wir auf das nun verfügbare Minus-Symbol neben dem Dateinamen klicken, das sich einblendet, wenn sich unser Mauszeiger über dem Dateinamen befindet.

Über der Bezeichnung Staged Changes ist ein Textfeld mit der Bezeichnung „Message“ zu sehen. Darin schreiben wir unsere „Commit Message“, die über die mit diesem Commit stattfindenden Änderungen informieren sollte. Da das unser allererster Commit ist, können wir das auch so schreiben.

In das Textfeld geben wir „Erster Commit.“ ein und klicken auf das Häkchen-Symbol, was über dem Textfeld zu sehen ist. Das war nun unser erster Commit. Die vier Dateien stehen von nun an unter der Versionskontrolle von Git.

Wir ändern unser Projekt

Während unsere Testklasse auch tatsächlich eine Klasse ist, schweben die Funktionen in „FizzBuzz.py“ mehr oder weniger frei durch den Raum. Lass uns auch aus „FizzBuzz.py“ eine Klasse machen:

So schreiben wir oben in der Datei „FizzBuzz.py“

class fizzbuzz:

Nun rücken wir alle vorhandenen Methoden ein und ergänzen self als ersten Parameter in den Methoden. Außerdem ändern wir den Zugriff auf die anderen Methoden von checkNumber aus, indem wir auf sie als Instanzmethoden zugreifen. Zum Beispiel wird aus

if fizzbuzz(numberToCheck) == "FizzBuzz":

jetzt

if self.fizzbuzz(numberToCheck) == "FizzBuzz":

Sind die Änderungen erledigt, sehen wir, dass beim Source-Control-Icon nun die Zahl 1 aufgetaucht ist. Klickst du auf das Symbol und wählst „FizzBuzz.py“, dann stellt VS Code die Änderungen nebeneinander dar. Links siehst du die alte Version der Datei und rechts die aktuelle. Mit Rot- und Grünfärbung hilft VS Code.

Die Änderungen werden in VS Code hervorgehoben

Etwas mehr müssen wir in unserer Datei „TestFizzBuzz.py“ tun. Hier ersetzen wir die Zeile

from FizzBuzz import fizz, buzz, fizzbuzz, checkNumber

mit der Zeile

import FizzBuzz

In der setUp-Methode fügen wir die Zeile

self.fizzbuzz = FizzBuzz.fizzbuzz()

ein. Damit instantiieren wir ein Objekt der Klasse „FizzBuzz“. Auch in den anderen Methoden müssen wir die Aufrufe der Methoden „fizz“, „buzz“, „fizzbuzz“ und „checkNumber“ modifizieren und ein self.fizzbuzz. vorsetzen.

Schließlich führen wir die Testklasse mit einem beherzten Druck des Tastenkürzels [control]+[alt]+[n] aus und stellen hoffentlich fest, dass es weder Fehler bei der Ausführung des Codes noch bei den Tests gibt. Falls es Fehler geben sollte, korrigieren wir diese, bevor wir fortfahren.

Unser zweiter Commit

Wer richtig hinguckt, sieht, dass VS Code unsere Änderungen farbig markiert. Zeilen, die sich geändert haben, sind mit einem dünnen blauen Balken gekennzeichnet. Gehst du mit dem Mauszeiger darüber, wird der Balken breiter. Klickst du auf den breiteren Balken, blendet VS Code die Unterschiede innerhalb der Zeile ein, die du seit dem letzten Commit vorgenommen hast. Durch einen weiteren Klick auf den blauen Balken, blendest du den Hinweis wieder aus.

Auf gelöschte Dateien weist ein kleines rotes Dreieck hin; auf hinzugefügte Zeilen ein grüner Balken. Der Umgang mit diesen beiden Hinweisen funktioniert analog zum Umgang mit dem oben beschriebenen blauen Balken.

Hinter den Dateien, in denen Änderungen stattgefunden haben, sieht man ein „M“ für „Modified“.

Rufen wir durch einen Klick auf das Source-Control-Symbol die Versionsverwaltung auf, sehen wir unter Changes die beiden Dateien „FizzBuzz.py“ und „TestFizzBuzz.py“. Fährst du mit dem Mauszeiger über die Überschrift Changes, dann blendet VS Code die beiden Symbole „Discard All Changes“ (Alle Änderungen verwerfen) und „Stage All Changes“ (Übernimm alle Änderungen). Wir klicken auf das Plus-Icon und übernehmen somit alle Änderungen. Nun befinden sich die beiden Dateien unter Staged Changes.

Mit der Commit-Message „FizzBuzz ist eine Klasse. Tests sind angepasst.“ und einem anschließenden Klick auf das Häkchen darüber schließen wir unser zweites Commit ab.

Wie geht es weiter?

Zwar haben wir nun zwei Stände unseres Projekts unter die Verwaltung der Versionskontrolle gestellt, aber bisher befindet sich das Repository auf unserem Computer. Wir müssen es anderen für die Mitarbeit zur Verfügung stellen können. Dies können wir beispielsweise über spezielle Git-Hoster wie GitHub, GitLab, BitBucket erreichen. Wie wir das machen, sehen wir uns in einem weiteren Post an.

Ressourcen zum Vertiefen

Wer noch ein wenig tiefer in die Materie der Versionskontrolle eintauchen möchte, findet hier Ressourcen: