Entwicklung mit Git, Visual Studio und Codex

Git, Visual Studio und Codex

Diese Seite beschreibt die wichtigsten Git-Funktionen in Visual Studio sowie den empfohlenen Workflow bei der parallelen Verwendung von Visual Studio und Codex für .NET-Projekte.

Git-Funktionen in Visual Studio

Im Fenster Git-Änderungen stellt Visual Studio verschiedene Funktionen zur Synchronisation mit einem Remote-Repository wie GitHub bereit.

Commit

Die Commit-Funktion in Visual Studio dient dazu, Änderungen an einem Projekt dauerhaft in der lokalen Git-Versionshistorie zu speichern. Ein Commit stellt dabei einen bestimmten Entwicklungsstand des Projekts dar, zu dem später zurückgekehrt werden kann.

Typischer Ablauf

1. Quellcode oder andere Projektdateien ändern.
2. Das Fenster Git-Änderungen öffnen.
3. Die vorgenommenen Änderungen kontrollieren.
4. Eine aussagekräftige Commit-Nachricht eingeben, z. B.:

   Fehler bei der seriellen Kommunikation behoben

5. Auf Alle committen klicken.
6. Bei Verwendung eines entfernten Repositorys, beispielsweise GitHub, anschließend die Commits mit Push übertragen.

Der grundlegende Ablauf lautet damit:

Dateien ändern
     ↓
Commit
     ↓
Lokales Git-Repository
     ↓
Push
     ↓
GitHub / Remote Repository

Commit und Push

Ein Commit speichert Änderungen zunächst nur im lokalen Git-Repository auf dem eigenen Computer. Die Änderungen befinden sich dadurch noch nicht automatisch auf GitHub.

Erst ein anschließender Push überträgt die lokalen Commits in das entfernte Repository.

Funktion	Bedeutung
Commit	Speichert einen Entwicklungsstand im lokalen Git-Repository.
Push	Überträgt lokale Commits zu einem entfernten Repository, beispielsweise GitHub.

Alle committen

Mit Alle committen werden alle aktuell vorhandenen Änderungen in einem neuen Commit gespeichert. Voraussetzung ist, dass Änderungen vorhanden sind und eine Commit-Nachricht eingegeben wurde.

Sind keine Änderungen vorhanden, ist die Schaltfläche entsprechend deaktiviert.

Staging

Git bietet zusätzlich einen sogenannten Staging-Bereich. Damit kann festgelegt werden, welche Änderungen in den nächsten Commit aufgenommen werden sollen.

Beispiel:

MainForm.cs
SerialPort.cs
README.md

Wurden alle drei Dateien geändert, sollen aber nur MainForm.cs und SerialPort.cs zusammen committen werden, können diese beiden Dateien zunächst gestaged und anschließend separat committet werden.

Commit korrigieren (Amend)

Die Option Korrigieren entspricht der Git-Funktion Amend. Damit wird kein zusätzlicher Commit erstellt, sondern der zuletzt erstellte Commit verändert.

Dies ist beispielsweise nützlich, wenn unmittelbar nach einem Commit festgestellt wird, dass eine Datei vergessen oder die Commit-Nachricht falsch formuliert wurde.

Vorher:
A → B → C

Nach Amend:
A → B → C'

Hinweis: Amend sollte möglichst nicht für Commits verwendet werden, die bereits zu GitHub gepusht und mit anderen Entwicklern geteilt wurden, da hierbei die Commit-Historie verändert wird.

Gute Commit-Nachrichten

Commit-Nachrichten sollten möglichst kurz beschreiben, was mit dem Commit geändert wurde.

Gute Beispiele:

Implementiere Modbus-TCP-Verbindung zum Terminal
Behebe Fehler beim Parsen der Gewichtsdaten
Füge Validierung der Benutzereingaben hinzu

Wenig aussagekräftig sind dagegen Nachrichten wie:

Update
Änderungen
Test
Neu

Merksatz: Ein Commit ist ein Speicherpunkt in der lokalen Git-Historie. Ein Push überträgt diese Speicherpunkte anschließend zu einem entfernten Repository wie GitHub.

Fetch

Fetch lädt Informationen über neue Commits und Branches vom Remote-Repository herunter, verändert den lokalen Arbeitsstand jedoch nicht.

git fetch

Fetch eignet sich, wenn zunächst geprüft werden soll, ob auf dem Remote-Repository neue Änderungen vorhanden sind.

Merksatz:

Fetch = Änderungen vom Server abrufen, aber noch nicht in den eigenen Branch übernehmen.

Pull

Pull lädt Änderungen vom Remote-Repository herunter und integriert sie in den aktuell ausgecheckten lokalen Branch.

Vereinfacht entspricht Pull:

Fetch
  +
Merge bzw. Rebase

Dabei können Merge-Konflikte entstehen, wenn lokale und entfernte Änderungen dieselben Bereiche einer Datei betreffen.

Merksatz:

Pull = Änderungen herunterladen und in den eigenen Arbeitsstand übernehmen.

Push

Push überträgt lokal erstellte Commits zum Remote-Repository.

git push

Es werden nur Änderungen übertragen, die zuvor als Commit gespeichert wurden.

Befinden sich auf dem Remote-Repository bereits neuere Commits, die lokal noch nicht vorhanden sind, kann Git den Push ablehnen. In diesem Fall sollte normalerweise zunächst ein Pull durchgeführt werden.

Merksatz:

Push = Eigene Commits zum Server hochladen.

Sync

Sync synchronisiert den lokalen und den entfernten Branch.

Vereinfacht führt Visual Studio dabei folgende Schritte aus:

Pull
 ↓
Push

Zuerst werden also Änderungen vom Remote-Repository übernommen. Anschließend werden die eigenen lokalen Commits hochgeladen.

Weitere Optionen

Über das Symbol

...

stehen zusätzliche Git-Funktionen und Synchronisationsoptionen zur Verfügung.

Typischer Git-Workflow

Ein normaler Arbeitsablauf kann beispielsweise folgendermaßen aussehen:

Pull
 ↓
Code bearbeiten
 ↓
Änderungen testen
 ↓
Commit erstellen
 ↓
Push

Optional kann vorher mit Fetch geprüft werden, ob neue Änderungen im Remote-Repository vorhanden sind.

Visual Studio und Codex gleichzeitig verwenden

Visual Studio und Codex können parallel mit demselben .NET-Projekt arbeiten.

Ein Neustart von Visual Studio nach Änderungen durch Codex ist normalerweise nicht erforderlich.

Codex verändert die Dateien direkt im Projektverzeichnis. Visual Studio erkennt externe Dateiänderungen in der Regel automatisch.

Typische Dateien sind beispielsweise:

• .cs
• .razor
• .xaml
• .json

Bei diesen Dateien ist normalerweise kein erneutes Laden des Projekts notwendig.

Änderungen an Projektdateien

Bei Änderungen an Dateien wie

• .csproj
• .sln

kann Visual Studio gegebenenfalls verlangen, das Projekt neu zu laden.

Ein kompletter Neustart von Visual Studio ist normalerweise trotzdem nicht notwendig.

Laufende Anwendung und Hot Reload

Dass Visual Studio eine geänderte Datei erkennt, bedeutet nicht automatisch, dass die Änderung sofort in einer bereits laufenden Anwendung aktiv wird.

Je nach Änderung kann Hot Reload die Änderung während der Laufzeit übernehmen.

Ist die Änderung nicht mit Hot Reload kompatibel, reicht normalerweise:

Anwendung stoppen
 ↓
Projekt neu kompilieren
 ↓
Anwendung erneut starten

Visual Studio selbst muss dafür nicht neu gestartet werden.

Erkennt Codex Änderungen aus Visual Studio?

Ja.

Wenn Visual Studio und Codex auf demselben Projektverzeichnis arbeiten, kann Codex Änderungen sehen, die zuvor in Visual Studio durchgeführt wurden.

Voraussetzung ist normalerweise, dass die Datei gespeichert wurde.

Visual Studio
     ↓
Datei speichern
     ↓
Datei auf der Festplatte
     ↓
Codex liest die aktuelle Version

Beispiel:

Eine Datei

ProjectService.cs

wird in Visual Studio geändert und gespeichert.

Wenn Codex anschließend diese Datei bearbeitet, verwendet Codex den aktuellen gespeicherten Stand.

Ungespeicherte Änderungen

Ungespeicherte Änderungen befinden sich nur im Editor von Visual Studio.

Beispiel:

Visual Studio:
neue Änderung
     ↓
nicht gespeichert

Festplatte:
alte Version

Codex:
sieht die alte Version

Deshalb sollten Änderungen in Visual Studio gespeichert werden, bevor Codex mit der Bearbeitung beginnt.

Gleichzeitiges Bearbeiten derselben Datei

Problematisch kann es werden, wenn Visual Studio und Codex gleichzeitig dieselbe Datei bearbeiten.

Beispiel:

Visual Studio                 Codex
     │                          │
ändert MainPage.xaml     ändert MainPage.xaml
     │                          │
nicht gespeichert         speichert Änderung
     │                          │
     └──── Konflikt möglich ────┘

Visual Studio kann anschließend melden, dass die Datei außerhalb der Entwicklungsumgebung geändert wurde.

Wird danach die noch ungespeicherte Version aus Visual Studio gespeichert, können die Änderungen von Codex überschrieben werden.

Empfohlener Workflow mit Codex

1. Änderungen in Visual Studio durchführen
2. Alle Dateien speichern
3. Codex einen Auftrag geben
4. Codex die Änderungen durchführen lassen
5. Änderungen in Visual Studio kontrollieren
6. Projekt kompilieren
7. Anwendung testen
8. Git-Diff überprüfen
9. Commit erstellen
10. Änderungen mit Push zum Remote-Repository übertragen

Empfehlung

Visual Studio und Codex können problemlos parallel auf demselben Projekt arbeiten.

Dabei sollte folgende Regel beachtet werden:

Visual Studio und Codex sollten möglichst nicht gleichzeitig dieselbe Datei bearbeiten.

Vor der Arbeit mit Codex sollten alle Änderungen in Visual Studio gespeichert werden.

Ein Neustart von Visual Studio oder Codex ist im normalen Entwicklungsworkflow nicht notwendig.

Kurzreferenz

Funktion	Bedeutung	Lokale Dateien werden verändert?
Fetch	Neue Informationen und Commits vom Remote-Repository abrufen	Nein
Pull	Remote-Änderungen herunterladen und übernehmen	Ja
Push	Eigene Commits zum Remote-Repository übertragen	Nein
Sync	Pull und anschließend Push durchführen	Ja