Nützliche Erweiterungen für Visual Studio Code, Teil 2 Git und GitHub-Support in VS Code

Das Bemerkenswerte an VS Code ist das Ökosystem um die IDE herum, das auf die Open-Source-Strategie von Microsoft von der Powershell Core bis GitHub zurückzuführen ist. In diesem zweiten Teil unserer Serie schauen wir uns die Funktionen rund um Git und GitHub an.

Um mit der Git-Integration in VS Code zu beginnen, kann man zunächst einmal in den Extensions nach „git“ oder „github“ suchen und werden dort auch eine große Zahl an Erweiterungen finden. Hierzu zählt wie im Aufmacherbild zu sehen beispielsweise „Git Graph“ zur visuellen Anzeige von Remote-Branches und lokalen Branches.

Für die meisten Aufgaben und Workflows rund um git und GitHub benötigen wir aber zunächst überhaupt keine Erweiterungen. Und wie üblich lässt sich die sehr gute Integration von VS Code in/mit Git aus verschiedenen Perspektiven ausprobieren z. B. über die Quellcodeverwaltung in der View-Bar (Ctrl.+Shift+G), aus dem Terminal (Ctrl.+Shift+ö) oder der Command-Palette ((Ctrl.+Shift+P, bzw. F1).

Man muss auch nicht zwingend über ein GitHub-Konto verfügen oder bei diesem angemeldet sind, um mit öffentlichen git- oder GitHub-Repositorien zu arbeiten. Wer aber bereits über einen GitHub-Account verfügt, der sollte sich aber unten links unter „Konten“ bei diesem anmelden, um mehr Funktionen nutzen zu können.

Wollen wir nun z. B. ein Git-Repository auf dem lokalen Rechner anlegen, gibt es hierfür bekanntlich zwei Möglichkeiten. Entweder konvertieren wir ein lokales Verzeichnis, das sich derzeit nicht unter Versionskontrolle befindet, in ein Git-Repository – oder wir klonen ein bestehendes Git-Repository von einem anderen Ort in das aktuelle Verzeichnis.

Im aktuellen Verzeichnis entsteht dann ein verstecktes Unterverzeichnis „.git“, welche quasi die git-Datenbank repräsentiert. Aus VS Code heraus gibt es anschließend mehrere Möglichkeiten, beide Varianten auszuprobieren.

Arbeiten mit GitHub-Repositories

Beginnen wir mit dem Klonen eines bestehenden Repositories. Eine Variante besteht darin, in der View-Bar links die Quellcodeverwaltung auszuwählen und dann auf „Repository klonen“ zu klicken. Das eröffnet wiederrum zwei Möglichkeiten.

• Entweder ist die Repository-URL bekannt, dann lässt sich diese bei „Geben Sie die Repository-URL an oder wählen sie eine Repositoryquelle aus“ eingeben, …

• oder man klickt auf „Aus ‚GitHub‘ klonen“ bei „Remotequellen“ und fügt den Repository-Namen in der Suchzeile ein. Nach der Wahl des Repositories öffnet sich z. B. unter Windows der Datei-Selektor des Windows-Explorers. Hier gilt es, das lokale Verzeichnis anzugeben, das zum lokalem Repository werden soll.

In beiden Fällen erhalten wir ein einsatzbereites Git-Repository auf dem lokalen Rechner. Dabei fragt ein Popup, ob das geklonte Repository gleich geöffnet werden soll. Fehlt nur noch die Bestätigung, dass wir den Autoren der Dateien in diesem Ordner trauen. Dabei wird der Name des Repositories (hier „dev-insider“ zu einem „git-überwachten“ Ordner mit dem oben erwähnten Unterordner, der das Verzeichnis zu einem git-Repository macht.

Im Explorer wird dann auch bereits ein Arbeitsbereich mit dem Verzeichnis „dev-insider“ angezeigt – samt der ggf. initial darin enthaltenen Dateien, hier „license“ und „readme.md“, weil wir das Repo zuvor initial auf GitHub auf Wunsch mit Readme-Datei und Lizenzbestimmungen haben erzeugen lassen. Dass das Verzeichnis unter Kontrolle von git steht, lässt sich wiederrum auf mehreren Wegen prüfen.

Mit der Tastenkombination [Strg]+[ö] lässt sich beispielsweise ein Terminal öffnen, in das man …

… tippt, wobei VS Code bereits hier erwartungsgemäß Autovervollständigung bietet.

Mit dem Befehl …

… (oder via „ls -h“) sehen wir nur das versteckte git-Verzeichnis.

Sinnvoller ist es ab diesem Zeitpunkt, in VS Code auf der linken Seite in die Quellcodeverwaltung zu wechseln. Allerdings müssen wir hier mit einem Klick auf „Repository öffnen“ zunächst das gewünschte Repo öffnen, sofern VS Code im übergeordneten Ordner des Arbeitsbereiches oder der geöffneten Dateien ein solches findet. Der Pfad wird dann bei „Zu öffnendes Repository auswählen“ angeboten. Es ließe sich aber durchaus auch ein anderes Repository auf dem Rechner manuell angeben.

Arbeiten mit der Quellcodeverwaltung

Die Quellcodeverwaltung bietet zunächst die beiden Abschnitte „Repositorys der Quellcodeverwaltung“ und „Quellcodeverwaltung“: Da wir noch keinerlei Änderungen an irgendwelchen Dateien vorgenommen haben, ist die einzige möglich Handlungsoption zu diesem Zeitpunkt ein „Commit“. Der Commit-Button bleibt aber so lange ausgegraut, bis Sie im gleichnamigen Feld eine Commit-Nachricht verfasst haben.

Da das Committen einer unveränderten Datei wenig Sinn ergibt, fügen wir jetzt eine neue Zeile in der Readme-Datei ein, übrigens eine Datei im Markdown-Format (md). Der Sprachmodus lässt sich übrigens in VS Code in der Palette über „change language mode“ ändern.

Die Datei wird samt Änderung nun in VS Code gespeichert, damit ein „Commit“ überhaupt möglich ist. In der Quellcodeverwaltung sehen Sie die Änderung im Abschnitt „Änderungen“. Klicken Sie die Datei unter „Änderungen“ an, sehen Sie die Änderungen im Editor im „Vorher-/Nachher“-Modus.

Entwickler würden aber nicht jede kleine Änderung in das lokale Repo „commiten“, sondern Änderungen zunächst „stagen“ und Tagesende gebündelt commiten. Der Lifecycle einer Änderung reicht bei git vom lokalen Arbeitsverzeichnis über die Staging-Area (in git auch „Index“ genannt) und das lokale Repo bis zu einem gehosteten GitHub-Repo.

Wir wollen die Änderung ebenfalls „stagen“, sprich bereitstellen: Statt das im Terminal mit …

… für alle geänderten Dateien zu tun, machen wir uns den Komfort von VS Code zunutze und klicken mit rechts auf die Readme-Datei im Abschnitt „Änderungen“. Bei einem deutsch lokalisierten VS Code stehen Ihnen hier die Kommandos „Änderungen verwerfen“, „Änderungen bereitstellen“ (staging) und „zu .gitignore hinzufügen“ zur Verfügung. In letzterem Fall wird die betreffende Datei explizit vom beschriebenen Lifecycle ausgeschlossen. Alternativ wäre auch ein Klick auf das +-Zeichen möglich gewesen.

Die bereitgestellten Änderungen erscheinen im Abschnitt „Gestagte Änderungen“. Im Editor ist nun zudem ein weiterer Tab „Readme.md (Index)“ zu sehen. Alternativ hätten wir das Stagen auch über die Command-Palette erledigen können. Dies funktioniert über „Git: Änderungen bereitstellen“. Schreiben Sie die Änderung mit „Commit“ in das lokale Repo (Commit Message nicht vergessen), verschwinden die Abschnitte „Gestagte Änderungen“ und „Änderungen“ aus der Quellcodeverwaltung.

Die Vorher-/Nachher-Ansicht zeigt nun links wie rechts den gleichen Inhalt und es erscheint ein neuer Button „Änderungen synchronisieren“ um das lokale Repo mit dem entfernten git-Repo oder GitHub zu synchronisieren („git push“). Außerdem ist die Datei „Readme.md“ im Editor jetzt schreibgeschützt. Führen wir jetzt die Synchronisation durch, weist VS Code darauf hin, dass durch diese Aktion Commits von und an den Branch „origin/main“ gepusht und auch gepullt werden. Dabei fragt VS Code auch nach, ob er in regelmäßigen Abständen „git fetch“ ausführen soll.

Nun ergänzen wir die Datei um eine weitere Zeile, um eine neue Änderung zu erhalten und führen diesmal direkt einen Commit aus, allerdings jetzt mit Hilfe der Command-Palette über „Git: Commit“. Auch den nun anstehenden Push können Sie alternativ über die Palette durchführen mit „Git: Push“. Selbstverständlich hätten Sie auch weiterhin im Terminal arbeiten können. Das bringt eben nur keinen direkten Komfortgewinn, abgesehen von der Autovervollständigung.

Zurück zur eingangs erwähnen Extension “Git Graph“. Ist Diese installiert, erscheint im Abschnitt „Repositorys der Quellcodeverwaltung“ bei den Icons rechts neben dem Repo das passende Git-Graph-Symbol. Beim Klick darauf ergänzt VS Code im Editor links eine Graph-Spalte. Da wir uns in den bisherigen Demos nur linear durch den Lifecycle bewegt haben, sieht das im Moment nicht sonderlich spektakulär aus. Das ändert sich aber bei der Arbeit mit mehreren Branches und Stages.

Lokales Verzeichnis unter git-Kontrolle

Abschließend noch ein paar Worte zum zweiten oben erwähnten Szenario. Hier wollen wir nicht ein bestehendes GitHub- oder -git-Repo klonen, sondern ein vorhandenes Verzeichnis unter die Kontrolle von git bringen. Der Befehl dazu lautet bekanntlich:

Mit dem Befehl …

… lässt sich erneut der Status prüfen. Hier legen wir nun eine Datei mit leerem Inhalt an:

Beim Wechsel in die Quellcodeverwaltung zeigt diese noch die alte Ansicht; denn aus der Demo oben steht noch ein Commit aus. Den führen wir jetzt noch ausm und synchronisieren noch einmal mit GitHub (git push).

Übrigens zeigt VS Code auch alle git-relevanten Befehle, wenn wir beim jeweiligen Repository auf das Menü mit den drei Pünktchen klicken. Möchten wir nun den neuen Pfad im Explorer haben, klicken wir im Datei-Menü auf „Ordner zum Arbeitsbereich hinzufügen“, um den Ordner zum aktuelle Workspace hinzuzufügen. Es ließe sich aber auch einen neuer Workspace erstellen.

Übrigens meldet VS Code ggf.: „Ein Git-Repository wurde in den übergeordneten Ordnern des Arbeitsbereichs oder in den geöffneten Dateien gefunden. Möchten Sie das Repository öffnen?“. Alternativ lässt sich auch der direkte Pfad zum neuen git-Repository eingeben, das in diesem Fall ja nicht mit GitHub verbunden ist. Wahlweise kann man auch in der Command Palette den Befehl „Git:Repository öffnen“ ausführen und im Windows-Dateiselektor zum gewünschten lokalen Verzeichnis, das durch „git init“ zum git-Repo wurde, navigieren.

Wir sehen nun zwei Git-Repos in der Quellcodeverwaltung, aber nur eines davon ist ein GitHub-Repository. In unserem Fall ist „dev-insider“ aus dem ersten Teil dieses Beitrags ein GitHub-Repo. Dies ist an den verfügbaren Icons zu erkennen, außerdem heißt der initiale Branch hier „main“ (statt „master“) und es gibt kein Extra-Icon zum „Veröffentlichen in GitHub“.

Das neue Repo „gitrepo“ ist ein reines git-Repo (was am versteckten Ordner .git zu erkennen ist), das außerdem den Unterordner „dev.insider2“ enthält.

Fazit

Wir haben Ihnen hiermit die elementaren Grundlagen der Integration von Git und GitHub mit VS Code gezeigt. Der Schwerpunkt lag in der Integration, nicht in einem Git-Deepdive, denn wir haben uns weder mit Branching noch Pulls, Fetches oder Pull-Requests befasst. Vertiefende Beiträge zu Git findet Sie in große Anzahl auf Dev-Insider, ebenso zu GitHub.

Bemerkenswert ist, dass Sie dazu in VS Code initial keine Erweiterungen benötigen. Trotzdem gibt es eine große Anzahl von Git-Extensions, welche die Arbeit von Git in VS Code noch komfortabler machen. Im nächsten Teil befassen wir uns mit Extensions für Docker, Kubernetes und Azure AKS.

(ID:49199930)