Git-Repositories und Problemsynchronisierung
Verbinden Sie ein Git-Konto, verknüpfen Sie ein Projekt-Repository und richten Sie die Problemsynchronisierung mit dem Anbieter ein.
Ein persönliches Git-Konto zu verbinden, ein Projekt-Repository zu verknüpfen und Forge-Tickets zu synchronisieren sind getrennte Aktionen. Autorisieren Sie zuerst das Konto. Danach wählt der Projekteigentümer das Repository und kann die Synchronisierung mit den erforderlichen Anbieterrechten aktivieren.
Git verbinden und ein Repository verknüpfen
Verbinden Sie GitHub oder GitLab in den Git-Kontoeinstellungen und schließen Sie die Browserfreigabe ab. Gewähren Sie nur erforderlichen Repository-Zugriff. Kehren Sie bei Desktop danach zur App zurück. Die Kontoverbindung ist projektübergreifend nutzbar, verknüpft aber nicht automatisch alle Repositories.
Der Eigentümer wählt im Git-Bereich der Projekteinstellungen ein verfügbares Repository und bestätigt. Prüfen Sie Anbieter, vollständigen Repository-Namen und angezeigtes handelndes Konto. Mitglieder können diese Eigentümerverknüpfung nicht ersetzen. Sie ermöglicht Repository-Kontext, die Verfolgung von Pull Requests und Repository-Skills; Ticketsynchronisierung wird separat aktiviert.
Fehlende Repositories oder abgelaufener Zugriff
Bei leerer Auswahl prüfen Sie Anbieterrechte und Freigabe der Organisation oder des Repositories. Verbinden Sie abgelaufene Konten erneut, statt Token in Tickets einzutragen. Das Entfernen der Verknüpfung verlangt Eigentümerrechte; lesen Sie die Bestätigung.
Self-Hosting kann ein konfiguriertes verwaltetes Relay oder betreibereigene Anbieter-Apps nutzen. Relay-Zugriff startet ausdrücklich und macht die Forge nicht lokal. Verfügbarkeit hängt von der Instanzkonfiguration ab. Prüfen Sie Betreiberregeln vor der Freigabe.
Forge-Tickets synchronisieren
Öffnen Sie als Eigentümer nach der Repository-Verknüpfung den Git-Bereich. Aktivieren Sie die Synchronisierung mit erforderlichen Schreibrechten. Importierte Tickets landen in der Triage. Prüfen Sie den gemeldeten Nachimport sowie Titel, Beschreibung und Status eines bekannten Remote-Tickets.
Offen und geschlossen werden in beide Richtungen gespiegelt. Bei GitHub werden Titel und Inhalt zu Titel und Beschreibung; Labels liefern Kategorien sowie erkannte Priorität und Aufwand; der erste verknüpfte Bearbeiter wird verwendet, die Milestone-Frist als Fälligkeit. Kommentare behalten Remote-Autor, Identität, URL und Zeitpunkte. Blockierbeziehungen verlangen beide Tickets im selben importierten Projekt. Anhangs-URLs bleiben erhalten; Dateibytes und GitHub-Projektfelder besitzen keine native Entsprechung.
Rechte, Konflikte und Abschalten
Die GitHub App braucht Issues-Lese-/Schreibrechte und Abonnements für Issues, Issue comments und Issue dependencies. Bestehende Installationen müssen neue Rechte akzeptieren. Diese Zuordnung garantiert nicht sämtliche GitLab-Felder.
Ältere GitHub-Ereignisse mit Zeitstempel überschreiben keine neueren lokalen Änderungen. Eindeutige Liefer- und Kommentaridentitäten verhindern Duplikateffekte. Vergleichen Sie Zeitstempel sowie Anbieterereignisse und Betreiberlogs bei fehlendem Nachimport. Deaktivieren Sie im selben Eigentümerbereich; prüfen Sie bereits importierte Arbeit separat.