Wer ein .NET-Projekt mit Visual Studio entwickelt und zusätzlich Codex für Änderungen am Quellcode verwendet, arbeitet schnell mit mehreren Werkzeugen gleichzeitig. Dabei stellen sich einige praktische Fragen:
- Muss Visual Studio nach Änderungen durch Codex neu gestartet werden?
- Erkennt Codex Änderungen, die in Visual Studio vorgenommen wurden?
- Was bedeuten Fetch, Pull, Push und Sync in der Git-Verwaltung?
- Wie verhindert man, dass sich Visual Studio und Codex gegenseitig Änderungen überschreiben?
Die gute Nachricht: Visual Studio, Git und Codex lassen sich problemlos parallel verwenden. Man sollte lediglich einige grundlegende Regeln beachten.
Git in Visual Studio: Fetch, Pull, Push und Sync
Visual Studio besitzt eine integrierte Git-Unterstützung. Im Fenster Git-Änderungen befinden sich unter anderem die Funktionen Fetch, Pull, Push und Sync.
Auch wenn häufig GitHub als Remote-Repository verwendet wird, handelt es sich dabei grundsätzlich um normale Git-Funktionen.
Fetch: Änderungen vom Server prüfen
Mit Fetch fragt Visual Studio das Remote-Repository nach neuen Commits und Branches ab.
Dabei werden zwar Informationen und Commits heruntergeladen, der aktuelle lokale Branch wird jedoch noch nicht verändert.
Der entsprechende Git-Befehl lautet:
git fetch
Fetch eignet sich deshalb sehr gut, wenn man zunächst überprüfen möchte, ob sich auf GitHub etwas geändert hat.
Vereinfacht gesagt:
Fetch schaut nach neuen Änderungen, übernimmt sie aber noch nicht in den eigenen Arbeitsstand.
Pull: Änderungen herunterladen und übernehmen
Pull geht einen Schritt weiter.
Die Änderungen vom Remote-Repository werden nicht nur heruntergeladen, sondern anschließend auch in den aktuell verwendeten lokalen Branch integriert.
Vereinfacht besteht Pull aus:
Fetch
+
Merge oder Rebase
Wenn beispielsweise ein anderer Entwickler Änderungen nach GitHub gepusht hat, können diese mit Pull in das lokale Projekt übernommen werden.
Dabei können allerdings Merge-Konflikte entstehen, wenn dieselben Bereiche einer Datei lokal und remote verändert wurden.
Push: Eigene Änderungen hochladen
Mit Push werden lokale Commits auf das Remote-Repository übertragen.
Der entsprechende Befehl lautet:
git push
Wichtig ist dabei:
Git überträgt nicht einfach alle geänderten Dateien. Änderungen müssen zunächst in einem Commit gespeichert werden.
Der typische Ablauf sieht beispielsweise so aus:
Dateien ändern
↓
Commit erstellen
↓
Push
Falls auf GitHub bereits neuere Commits vorhanden sind, die lokal noch fehlen, kann Git einen Push ablehnen. In diesem Fall sollte normalerweise zuerst ein Pull durchgeführt werden.
Sync: Pull und Push kombinieren
Visual Studio bietet zusätzlich die Funktion Sync an.
Dabei wird der lokale Branch mit dem Remote-Repository synchronisiert.
Vereinfacht:
Pull
↓
Push
Zunächst werden also Änderungen vom Server übernommen und anschließend eigene Commits hochgeladen.
Ein typischer Git-Workflow
Für kleinere Projekte oder Einzelentwickler ist folgender Ablauf meistens ausreichend:
Pull
↓
Code bearbeiten
↓
Projekt testen
↓
Commit erstellen
↓
Push
Optional kann vorher mit Fetch geprüft werden, ob neue Änderungen vorhanden sind.
Gerade wenn mehrere Entwickler am selben Repository arbeiten, sollte man regelmäßig Pull oder Fetch verwenden.
Codex und Visual Studio gleichzeitig verwenden
Codex kann ein .NET-Projekt direkt im Projektverzeichnis bearbeiten.
Wenn Visual Studio gleichzeitig dieselbe Solution geöffnet hat, ist normalerweise kein Neustart von Visual Studio erforderlich.
Ändert Codex beispielsweise eine Datei wie:
Program.cs
ProjectService.cs
MainPage.xaml
appsettings.json
erkennt Visual Studio die externe Dateiänderung in der Regel automatisch.
Das bedeutet:
Codex ändert Datei
↓
Datei wird auf Festplatte gespeichert
↓
Visual Studio erkennt Änderung
Visual Studio kann also geöffnet bleiben, während Codex am Projekt arbeitet.
Muss das Projekt nach Änderungen neu geladen werden?
Bei normalen Quellcodedateien ist das in der Regel nicht notwendig.
Bei Änderungen an Projekt- oder Solution-Dateien wie:
.csproj
.sln
kann Visual Studio gegebenenfalls verlangen, das Projekt neu zu laden.
Ein kompletter Neustart von Visual Studio ist aber auch dann normalerweise nicht erforderlich.
Was passiert mit einer bereits laufenden Anwendung?
Hier muss zwischen dem Editor und der tatsächlich laufenden Anwendung unterschieden werden.
Visual Studio kann eine geänderte Datei sofort erkennen. Eine bereits laufende Anwendung verwendet den neuen Code aber nicht zwangsläufig sofort.
Je nach Änderung kann Hot Reload den neuen Code übernehmen.
Falls das nicht möglich ist, reicht normalerweise:
Anwendung stoppen
↓
Projekt neu kompilieren
↓
Anwendung erneut starten
Visual Studio selbst muss dafür nicht beendet werden.
Erkennt Codex Änderungen aus Visual Studio?
Ja.
Wenn Codex und Visual Studio auf demselben Projektordner arbeiten, greift Codex auf die dort gespeicherten Dateien zu.
Wird beispielsweise in Visual Studio eine Datei geändert und gespeichert:
Visual Studio
↓
Datei speichern
↓
Datei auf Festplatte
↓
Codex liest aktuelle Version
kann Codex diese Änderung bei seiner nächsten Bearbeitung berücksichtigen.
Ungespeicherte Änderungen sind ein Problem
Eine wichtige Einschränkung gibt es allerdings.
Änderungen, die in Visual Studio noch nicht gespeichert wurden, befinden sich zunächst nur im Editor.
Für Codex liegt auf der Festplatte weiterhin die alte Version der Datei.
Beispiel:
Visual Studio:
neuer Code
↓
noch nicht gespeichert
Festplatte:
alter Code
Codex:
sieht alten Code
Deshalb sollte man Änderungen in Visual Studio immer speichern, bevor Codex mit der Bearbeitung beginnt.
Vorsicht beim gleichzeitigen Bearbeiten derselben Datei
Die größte Fehlerquelle entsteht, wenn Visual Studio und Codex gleichzeitig dieselbe Datei bearbeiten.
Ein Beispiel:
Visual Studio Codex
│ │
ändert MainPage.xaml ändert MainPage.xaml
│ │
noch nicht gespeichert speichert Änderung
Visual Studio erkennt anschließend, dass sich die Datei auf der Festplatte geändert hat.
Problematisch wird es insbesondere dann, wenn anschließend die noch ungespeicherte Version aus Visual Studio gespeichert wird. Dadurch könnten die Änderungen von Codex wieder überschrieben werden.
Eine einfache Regel
Visual Studio und Codex können gleichzeitig am selben Projekt arbeiten, sollten aber möglichst nicht gleichzeitig dieselbe Datei verändern.
Mein empfohlener Workflow
Ein übersichtlicher Workflow für die gemeinsame Verwendung von Visual Studio, Codex und Git sieht beispielsweise so aus:
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 überprüfen
↓
6. Projekt kompilieren
↓
7. Anwendung testen
↓
8. Git-Diff kontrollieren
↓
9. Commit erstellen
↓
10. Push durchführen
Durch Git hat man zusätzlich jederzeit die Möglichkeit zu kontrollieren, welche Dateien Codex verändert hat.
Gerade bei größeren Codex-Aufträgen lohnt es sich deshalb, vor Beginn einen Commit zu erstellen.
Damit erhält man einen klar definierten Ausgangspunkt:
funktionierender Stand
↓
Commit
↓
Codex führt Änderungen durch
↓
Git-Diff prüfen
Falls das Ergebnis nicht den Erwartungen entspricht, lassen sich die Änderungen dadurch wesentlich leichter nachvollziehen oder zurücksetzen.
Fazit
Visual Studio und Codex ergänzen sich bei der .NET-Entwicklung sehr gut.
Visual Studio muss nach Codex-Änderungen normalerweise nicht neu gestartet werden, da externe Dateiänderungen automatisch erkannt werden.
Umgekehrt kann Codex auch Änderungen berücksichtigen, die zuvor in Visual Studio vorgenommen wurden – vorausgesetzt, sie wurden gespeichert.
Zusammen mit Git ergibt sich damit ein effizienter Workflow:
Visual Studio
↕
Projektdateien
↕
Codex
+
Git / GitHub
Die wichtigsten Regeln sind dabei:
- Änderungen in Visual Studio vor der Arbeit mit Codex speichern.
- Dieselbe Datei möglichst nicht gleichzeitig in Codex und Visual Studio bearbeiten.
- Änderungen von Codex anschließend über Git-Diff kontrollieren.
- Vor größeren automatisierten Änderungen einen Commit erstellen.
- Visual Studio muss normalerweise nicht neu gestartet werden.
Damit kann Codex problemlos als zusätzlicher Entwicklungsassistent innerhalb eines bestehenden Visual-Studio- und Git-Workflows eingesetzt werden.