VS Code-Arbeitsbereiche für die Bereitstellung mehrerer Repos

Viele Teams verwenden kein Monorepo. Das Frontend befindet sich in einem Repository, das Backend in einem anderen, und jede Funktion erstreckt sich über beide hinweg. Die Multi-Root-Workspaces von VS Code bieten Ihnen eine schlanke Möglichkeit, über diese Grenze hinweg zu arbeiten: ein Fenster, eine Suchoberfläche, ein Debug-Einstiegspunkt und ein Ort zur Koordination der KI-Unterstützung. In dieser Ausgabe wird erklärt, was ein Workspace eigentlich ist, wie man einen für zwei Repositorys einrichtet und warum dies GitHub Copilot für die durchgängige Arbeit verbessert.

Was ein VS Code-Arbeitsbereich eigentlich ist

In VS Code ist mit dem Begriff „Arbeitsbereich“ meist ein Arbeitsbereich mit mehreren Stammverzeichnissen gemeint: ein gespeicherter <name>.code-workspace Eine Datei, die mehrere Ordner in einem Fenster öffnet.

Das ist der entscheidende Vorteil von GitHub Copilot. Anstatt eine Chat- oder Agent-Sitzung im Frontend-Repo und eine weitere im Backend-Repo auszuführen, können Sie Copilot eine Arbeitsfläche zur Verfügung stellen, die beide Repos umfasst.

Ein einfaches Layout könnte so aussehen:

~/git-repositories/
  Kundenportal.Code-Arbeitsbereich
  Kundenportal-Web/
      .github/
      src/
  Kundenportal-API/
      .github/
      src/
  Abrechnungsdienst/
  Datenplattform/
  interne-tools/

Es geht nicht darum, „alles in der Nähe zu öffnen“. Es geht darum, „die Repos zu öffnen, die die Funktion gemeinsam enthalten“.

Die <name>.code-workspace Die Datei ist einfach JSON. Sie enthält mindestens ein Ordner Array. Es kann außerdem Arbeitsbereichseinstellungen, Startkonfigurationen, Aufgaben und Empfehlungen für Erweiterungen enthalten.

{
   "folders": [
       {
           "name": "frontend",
           "path": "customer-portal-web"
       },
       {
           "name": "backend",
           "path": "customer-portal-api"
       }
   ],
   "settings": {
       "workbench.editor.labelFormat": "medium",
       "files.autoSave": "afterDelay"
   }
}

Warum dies für Copilot von Bedeutung ist

Bei getrennten Frontend- und Backend-Repositorys wird der Arbeitsbereich zu dem Ort, an dem Copilot das gesamte Feature verfolgen kann, anstatt nur einen Teil davon.

• Die Suche erstreckt sich über beide Stammverzeichnisse, sodass Copilot ein Feld oder einen Endpunkt schneller über UI- und API-Grenzen hinweg aufspüren kann.
• „Source Control“ zeigt mehrere Repositorys in einer Sitzung an, wodurch sich der tatsächliche Umfang einer Änderung leichter überblicken lässt.
• Registerkarten und Ergebnisse bleiben nach Ordnern sortiert, sodass doppelte Dateinamen weniger Verwirrung stiften.

Sie können auch die Eingabeaufforderung selbst vereinfachen. Ohne einen gemeinsamen Arbeitsbereich führt dieselbe Funktion oft zu zwei separaten Eingabeaufforderungen, da Copilot jeweils nur ein Repo gleichzeitig sieht.

Vorher:

Frontend-Repo-Eingabeaufforderung:

Fügen Sie dem Formular zum Anlegen eines Kunden ein Feld „Kundennummer“ hinzu. In „CreateCustomerDto“ heißt das Feld „customerNumber“.

Backend-Repo-Eingabeaufforderung:

Fügen Sie „customerNumber“ zu „CreateCustomerDto“, dem Service und dem Persistenzmodell hinzu.

Bei einem Arbeitsbereich mit mehreren Stammverzeichnissen lässt sich dies auf eine einzige, einfachere Eingabeaufforderung reduzieren, da Copilot beide Seiten überprüfen, „CreateCustomerDto“ finden und denselben Feldnamen sowohl im Frontend als auch im Backend wiederverwenden kann.

Danach:

Arbeitsbereich-Eingabeaufforderung:

Fügen Sie dem Formular zum Anlegen eines Kunden durchgehend ein Feld für die Kundennummer hinzu.

Das ist nicht nur zeitsparender. Anstatt zwei separate Sitzungen zu starten und DTO-Namen sowie Vertragsdetails manuell zwischen diesen zu kopieren, liest Copilot den gemeinsamen Vertrag in einem Durchgang direkt aus der Codebasis aus. So vermeiden Sie doppelte Kontexteinrichtungen in zwei Chats und sparen sich die zusätzlichen Folge-Runden, die durch Unstimmigkeiten zwischen Frontend und Backend entstehen.

Das ist der praktische Vorteil: Man führt zwar getrennte Repositories, vermeidet aber dadurch einen Großteil des Kontextwechsels.

Erste Schritte

Wenn Sie noch nie mit Arbeitsbereichen gearbeitet haben, ist dies der einfachste Einstieg:

1. Erstellen Sie eine <name>.code-workspace Datei in einem übergeordneten Ordner in der Nähe beider Repositorys.
2. Fügen Sie die Ordner „frontend“ und „backend“ zur Ordner Array und speichern Sie die Datei.
3. Doppelklicken Sie auf die Arbeitsbereichsdatei oder verwenden Sie den Befehl code <name>.code-workspace um es in VS Code zu öffnen.

Wenn Ihnen der Ablauf in der Benutzeroberfläche besser gefällt, öffnen Sie ein Repo, fügen Sie den zweiten Ordner zum Arbeitsbereich hinzu und speichern Sie den unbenannten Arbeitsbereich anschließend als .code-workspace Datei wie beschrieben hier.

Die gleiche Datei kann außerdem Folgendes enthalten:

• Einstellungen für das Editorverhalten im gesamten Arbeitsbereich
• Start zum Debuggen und Starten von Abläufen
• Aufgaben für Shell-basierte Befehle zum Erstellen, Testen oder Starten
• Erweiterungen für empfohlene Erweiterungen

Weitere Informationen zum Dateiformat finden Sie in der VS Code-Dokumentation.

Sobald dies eingerichtet ist, fällt es GitHub Copilot wesentlich leichter, den gesamten Prozess durchzuführen, da die Editor-Sitzung bereits beide Teile der Funktion enthält.

Copilot-Anleitungen in einem Multi-Repo-Arbeitsbereich

In einem Arbeitsbereich mit mehreren Stammverzeichnissen behandelt VS Code den Ordner, in dem die <name>.code-workspace Datei als magischen Befehlsstammordner. Es durchsucht den Stammordner jedes Arbeitsbereichs nach Befehlsdateien. Mit anderen Worten: Wenn sich Ihr Arbeitsbereich öffnet, kundenportal-web/ und customer-portal-api/, Copilot kann Folgendes erkennen:

• customer-portal-web/.github/copilot-instructions.md
• customer-portal-api/.github/copilot-instructions.md
• passend *.Anleitung.md Dateien unter jedem Repo .github/Anleitungen/
• AGENTS.md Dateien innerhalb jedes Repos, wobei die nächstgelegene Datei in der Verzeichnisstruktur Vorrang hat

Das ist die wichtige Schlussfolgerung: Ja, einzelne Projektanweisungen gelten auch in einem Arbeitsbereich mit mehreren Stammverzeichnissen weiterhin. Sie werden anhand der Stammverzeichnisse ermittelt, die tatsächlich Teil des Arbeitsbereichs sind.

Das gilt auch umgekehrt: a .github/copilot-instructions.md neben den gespeicherten <name>.code-workspace Die Datei wird nicht automatisch erkannt, es sei denn, das übergeordnete Verzeichnis wird ebenfalls als Arbeitsbereichsstammverzeichnis hinzugefügt.

Profi-Tipps

• Gib den Wurzeln eindeutige Namen wie Frontend und Backend in der Workspace-Datei. Dadurch lassen sich Registerkarten, Suchergebnisse und Startkonfigurationen viel leichter überfliegen.
• Speichern Sie editorweite Einstellungen in den Arbeitsbereichseinstellungen und nicht in den Ordnereinstellungen. Im Multi-Root-Modus gelten Ordnereinstellungen nur für das ressourcenspezifische Verhalten.
• Halten Sie den Arbeitsbereich klein. Für diesen Anwendungsfall reichen Frontend und Backend aus. Fügen Sie weitere Repos erst hinzu, wenn diese direkt Teil desselben Bereitstellungsablaufs sind.
• Sie können zusammengesetzte Startkonfigurationen für das Frontend- und Backend-Paar verwenden, das Sie tatsächlich gemeinsam ausliefern. Dadurch erhalten Copilot und der Entwickler denselben Einstiegspunkt zur Laufzeit.
• Bewahre die Copilot-Anweisungen in dem Repo auf, auf das sie sich beziehen. Die Geretteten <name>.code-workspace Die Datei ist kein Ersatz für die Anweisungsdateien der einzelnen Repos.