Entwicklung mit Git, Visual Studio und Codex

Aus dev.kaibel.net
Zur Navigation springen Zur Suche springen

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.

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