# Versionskontrolle-Integration (/de/docs/verdent-for-vscode/common-workflows/version-control)

> Arbeiten mit Git und anderen Versionskontrollsystemen



Verdent for VS Code lässt sich nahtlos mit Git und anderen Versionskontrollsystemen integrieren und ermöglicht Versionskontrolloperationen in natürlicher Sprache, automatisierte Commit-Nachrichten-Generierung und intelligentes Branch-Management. Dieser Leitfaden zeigt Ihnen, wie Sie die Git-Integration von Verdent für effiziente Versionskontroll-Workflows nutzen können.

***

## Aussagekräftige Commit-Nachrichten erstellen [#aussagekräftige-commit-nachrichten-erstellen]

Angenommen, Sie haben Änderungen vorgenommen und möchten, dass Verdent eine beschreibende Commit-Nachricht generiert.

<Steps>
  <Step title="Commit mit generierter Nachricht anfordern">
    ```
    Stage all changes and create a commit with an appropriate message
    ```

    Verdent analysiert Ihre Änderungen mithilfe von git diff.
  </Step>

  <Step title="Verdent analysiert die Änderungen">
    Verdent untersucht:

    * Geänderte Dateien und ihren Zweck
    * Art der Änderungen (neue Funktion, Fehlerbehebung, Refactoring)
    * Umfang der Auswirkungen
    * Zugehörige Funktionalität
  </Step>

  <Step title="Generiert eine beschreibende Commit-Nachricht">
    ```bash
    git commit -m "feat: add user profile image upload with S3 integration

    - Add file upload endpoint to user API
    - Integrate AWS S3 for image storage
    - Update user model with profileImage field
    - Add frontend image upload component with preview"
    ```

    Die Nachricht folgt dem Conventional-Commit-Format und beschreibt, was geändert wurde.
  </Step>

  <Step title="Der Commit wird erstellt">
    Die Änderungen werden mit der generierten Nachricht committet. Sie können den Commit überprüfen:

    ```bash
    git log -1
    ```
  </Step>
</Steps>

<Tip>
  **Tipps:**

  * Verdent folgt den Conventional-Commit-Formaten (feat, fix, refactor, docs usw.)
  * Commit-Nachrichten konzentrieren sich auf das „Was“ und „Warum“, nicht auf das „Wie“
  * Sie können das Format der Commit-Nachrichten in Benutzerregeln oder Projektregeln anpassen
  * Fordern Sie bestimmte Commit-Nachrichtenstile an: „Erstelle einen Commit mit einer detaillierten mehrzeiligen Nachricht“
</Tip>

***

## Anpassen der Formate für Commit-Nachrichten [#anpassen-der-formate-für-commit-nachrichten]

Angenommen, Sie möchten, dass Verdent den spezifischen Commit-Nachrichten-Konventionen Ihres Teams folgt.

<Tabs>
  <Tab title="Benutzerregeln (global)">
    Definieren Sie Ihre Präferenzen für Commit-Nachrichten in `VERDENT.md` für alle Projekte:

    ```markdown
    # VERDENT.md

    ## Git Commit Messages

    When generating commit messages:
    - Always include ticket number in format: [PROJ-123]
    - Use present tense verbs
    - Maximum 50 characters for first line
    - Include detailed explanation in body
    - Add "Co-authored-by" for pair programming sessions

    Example format:
    [PROJ-123] Add user authentication feature

    Detailed explanation of changes...

    Co-authored-by: Team Member <email@example.com>
    ```

    Verdent befolgt diese Regeln global.
  </Tab>

  <Tab title="Projektregeln">
    Definieren Sie projektspezifische Commit-Konventionen in `AGENTS.md`:

    ```markdown
    # AGENTS.md

    ## Git Commit Conventions

    For this project, use conventional commits with these scopes:
    - feat(api): API changes
    - feat(ui): Frontend changes
    - fix(auth): Authentication fixes
    - docs(readme): Documentation updates

    Always reference GitHub issue: "Fixes #123" or "Relates to #456"
    ```

    Die Regeln gelten nur für dieses Projekt.
  </Tab>

  <Tab title="Inline-Anweisungen">
    Geben Sie einmalige Anweisungen direkt an:

    ```
    Create a commit with message format: "[TICKET-NUMBER] description" including reference to issue #42
    ```

    Verdent generiert:

    ```bash
    git commit -m "[PROJ-42] Add search functionality

    Relates to #42"
    ```
  </Tab>
</Tabs>

<Tip>
  **Tipps:**

  * Benutzerregeln gelten global für alle Projekte
  * Projektregeln (AGENTS.md) überschreiben Benutzerregeln für bestimmte Projekte
  * Inline-Anweisungen überschreiben beide für einmalige Anforderungen
  * Das Conventional-Commits-Format wird für Konsistenz empfohlen
</Tip>

***

## Pull Requests erstellen [#pull-requests-erstellen]

Angenommen, Sie möchten, dass Verdent einen umfassenden Pull Request erstellt.

<Steps>
  <Step title="Sicherstellen, dass die Änderungen committet sind">
    ```
    Make sure all my changes are committed
    ```

    Verdent prüft den Git-Status und committet alle nicht committeten Änderungen.
  </Step>

  <Step title="Branch zum Remote-Repository pushen">
    ```
    Push this branch to origin
    ```

    Verdent pusht:

    ```bash
    git push origin feature/user-notifications
    ```
  </Step>

  <Step title="Erstellung des PR anfordern">
    ```
    Create a pull request for this feature
    ```

    Verdent verwendet die `gh`-CLI, um den PR zu erstellen.
  </Step>

  <Step title="Verdent generiert die PR-Beschreibung">
    Verdent analysiert Commits und Änderungen, um Folgendes zu generieren:

    **Titel:** Benachrichtigungssystem für Benutzer hinzufügen

    **Text:**

    ```markdown
    ## Summary
    - Implements real-time user notifications
    - Adds WebSocket support for instant delivery
    - Includes email fallback for offline users
    - Comprehensive test coverage

    ## Test Plan
    - [ ] Test real-time notifications in browser
    - [ ] Verify email fallback for offline users
    - [ ] Check notification persistence across sessions
    - [ ] Test with multiple concurrent users

    ## Changes
    - Added NotificationService with WebSocket integration
    - Created notification UI components
    - Integrated SendGrid for email notifications
    - Added notification preferences to user settings
    ```

    Der PR wird mit einer umfassenden Beschreibung erstellt.
  </Step>
</Steps>

<Tip>
  **Tipps:**

  * Verdent analysiert alle Commits im Branch, um die PR-Beschreibung zu generieren
  * Fordern Sie bestimmte PR-Formate an: „Erstelle einen PR mit detailliertem Testplan“
  * Fügen Sie Screenshots hinzu: „Füge diesen Screenshot der PR-Beschreibung hinzu“
  * Sie können die PR-Beschreibung vor der Erstellung verfeinern: „Aktualisiere den PR, um die Breaking Change zu erwähnen“
</Tip>

***

## Merge-Konflikte lösen [#merge-konflikte-lösen]

Angenommen, Sie stoßen auf Merge-Konflikte und benötigen die Hilfe von Verdent, um sie zu lösen.

<Steps>
  <Step title="Merge versuchen">
    ```
    Merge main into this feature branch
    ```

    Es tritt ein Merge-Konflikt auf:

    ```bash
    Auto-merging src/auth.ts
    CONFLICT (content): Merge conflict in src/auth.ts
    ```
  </Step>

  <Step title="Konfliktlösung anfordern">
    ```
    Help me resolve the merge conflict in src/auth.ts
    ```

    Verdent liest die Konfliktmarkierungen.
  </Step>

  <Step title="Verdent analysiert beide Versionen">
    Verdent untersucht:

    * Änderungen im aktuellen Branch (HEAD)
    * Eingehende Änderungen (main-Branch)
    * Kontext rund um die Konflikte
    * Absicht beider Änderungen
  </Step>

  <Step title="Verdent schlägt eine Lösung vor">
    ```
    The conflict is between your JWT implementation and the main branch's session-based auth. I'll merge both approaches to support both authentication methods.
    ```

    Verdent löst den Konflikt, indem beide Änderungen intelligent zusammengeführt werden.
  </Step>

  <Step title="Konflikt als gelöst markieren">
    ```bash
    git add src/auth.ts
    git commit -m "Merge main into feature/jwt-auth, resolved conflicts"
    ```

    Der Konflikt ist gelöst und der Merge ist abgeschlossen.
  </Step>
</Steps>

<Tip>
  **Tipps:**

  * Verdent versteht den Codekontext, um Konflikte intelligent zu lösen
  * Überprüfen Sie Konfliktlösungen stets, bevor Sie committen
  * Bitten Sie Verdent bei komplexen Konflikten, zunächst beide Versionen zu erläutern
  * Testen Sie nach der Konfliktlösung gründlich
</Tip>

<Tip>
  Verdent analysiert Merge-Konflikte, indem die Absicht beider Branches verstanden wird, und schlägt Lösungen vor, die die Funktionalität beider Seiten erhalten.
</Tip>

***

## Branches und Tags verwalten [#branches-und-tags-verwalten]

Angenommen, Sie müssen Branches verwalten und Release-Tags erstellen.

<Tabs>
  <Tab title="Branch-Operationen">
    **Branches erstellen und wechseln:**

    ```
    Create a new branch called feature/user-notifications
    ```

    Verdent führt aus:

    <CodeGroup>
      ```bash "Create New Branch"
      git checkout -b feature/user-notifications
      ```

      ```bash "Switch to Existing Branch"
      git checkout main
      ```

      ```bash "Create and Push Branch"
      git checkout -b feature/payment-integration
      git push -u origin feature/payment-integration
      ```
    </CodeGroup>
  </Tab>

  <Tab title="Zusammenführen">
    **Feature-Branches zusammenführen:**

    ```
    Merge the feature/user-notifications branch into main
    ```

    Verdent führt den Merge-Workflow aus:

    ```bash
    git checkout main
    git pull origin main
    git merge feature/user-notifications
    git push origin main
    ```

    Verdent stellt sicher, dass main vor dem Zusammenführen aktuell ist.
  </Tab>

  <Tab title="Releases mit Tags versehen">
    **Annotierte Tags erstellen:**

    ```
    Create an annotated tag for version 1.2.0 with release notes
    ```

    Verdent erstellt ein detailliertes Tag:

    ```bash
    git tag -a v1.2.0 -m "Release 1.2.0

    New Features:
    - User notification system
    - Email integration
    - Real-time WebSocket support

    Bug Fixes:
    - Fixed authentication timeout issue
    - Resolved cart calculation bug"
    ```

    **Tags pushen:**

    ```
    Push all tags to origin
    ```

    Verdent pusht:

    ```bash
    git push origin --tags
    ```
  </Tab>
</Tabs>

<Tip>
  **Tipps:**

  * Verwenden Sie aussagekräftige Branch-Namen: `feature/user-auth`, `fix/cart-bug`, `refactor/api-layer`
  * Ziehen Sie stets die neuesten Änderungen, bevor Sie zusammenführen
  * Verwenden Sie annotierte Tags für Releases (sie enthalten Metadaten)
  * Folgen Sie der semantischen Versionierung: v1.2.3 (Major.Minor.Patch)
</Tip>

<Tip>
  Konsistente Branch-Namenskonventionen helfen Verdent, Ihren Workflow zu verstehen. Definieren Sie Muster in AGENTS.md für automatische Einhaltung.
</Tip>

***

## Häufig gestellte Fragen [#häufig-gestellte-fragen]

<Accordion title="Committet Verdent meine Änderungen automatisch?">
  Nein. Verdent erstellt Commits nur, wenn Sie diese ausdrücklich anfordern. Sie behalten die volle Kontrolle darüber, wann Änderungen committet werden. Fragen Sie einfach „Stage alle Änderungen und erstelle einen Commit“, wenn Sie bereit sind.
</Accordion>

<Accordion title="Kann ich die Commit-Nachricht vor dem Committen bearbeiten?">
  Ja. Sie können Verdent bitten, die Commit-Nachricht vor der Erstellung zu überarbeiten. Sagen Sie „Aktualisiere die Commit-Nachricht, um die Breaking Change zu erwähnen“ oder „Mache diese Commit-Nachricht prägnanter.“ Verdent generiert die Nachricht basierend auf Ihrem Feedback neu.
</Accordion>

<Accordion title="Funktioniert Verdent mit GitHub, GitLab, Bitbucket und anderen Git-Plattformen?">
  Ja. Verdent verwendet Standard-Git-Befehle, sodass es mit jedem Git-Repository unabhängig von der Hosting-Plattform funktioniert. Für die Erstellung von Pull Requests verwendet Verdent die `gh`-CLI, die GitHub erfordert, aber alle anderen Git-Operationen funktionieren universell.
</Accordion>

<Accordion title="Pusht Verdent ohne Rückfrage zu Remote-Repositories?">
  Nein. Verdent pusht nur zu Remote-Repositories, wenn Sie dies ausdrücklich anfordern. Alle Git-Operationen (Commit, Push, Merge, Rebase) erfordern aus Sicherheitsgründen Ihre ausdrückliche Anweisung.
</Accordion>

<Accordion title="Kann Verdent alle Arten von Merge-Konflikten lösen?">
  Verdent kann die meisten textbasierten Merge-Konflikte lösen, indem der Codekontext und die Absicht verstanden werden. Binärdatei-Konflikte oder sehr komplexe Mehrwege-Konflikte erfordern möglicherweise manuelles Eingreifen. Überprüfen Sie stets die Konfliktlösung von Verdent, bevor Sie committen.
</Accordion>

***

## Siehe auch [#siehe-auch]

<CardGroup cols="2">
  <Card title="Beispiele für mehrstufige Aufgaben" icon="list-check" href="/docs/verdent-for-vscode/common-workflows/multi-step-tasks">
    Komplexe mehrstufige Workflows und Aufgabenverwaltung
  </Card>

  <Card title="Neuen Code schreiben" icon="code" href="/docs/verdent-for-vscode/task-based-guides/writing-code">
    Erstellen neuer Funktionen und Komponenten mit Verdent
  </Card>
</CardGroup>