GitHub-Issues effizient finden: So vermeidest du doppelte PRs

Jeder Entwickler kennt das frustrierende Szenario: Man entdeckt ein vermeintlich freies Problem in einem Open-Source-Projekt, investiert Stunden in die Einrichtung und beginnt mit der Arbeit – nur um später zu sehen, dass jemand anderes bereits heimlich einen Pull Request erstellt hat. Zwei Stunden Arbeit sind plötzlich umsonst.

Doch warum passiert das immer wieder? Die gängigen Plattformen wie goodfirstissue.dev oder up-for-grabs.net zeigen zwar offene Aufgaben an, verpassen aber den entscheidenden Punkt: Sie geben keine Auskunft darüber, ob jemand bereits – still und ohne Kommentar – an der Lösung arbeitet. Genau hier setzt GitTrek an, ein neues Tool, das diese Lücke schließt.

Stille Übernahmen: Das ungelöste Problem der Open-Source-Community

Die meisten Entwickler beginnen mit der Arbeit an einem Issue, ohne dies öffentlich zu kommunizieren. Statt einen Kommentar zu hinterlassen oder sich zuweisen zu lassen, starten sie einfach – und hinterlassen dabei oft digitale Spuren. GitTrek nutzt zwei solche Indikatoren, die direkt in GitHubs GraphQL-API abrufbar sind:

• Verweise in PRs oder Commits: Wenn jemand die Issue-Nummer in einer Pull-Request-Beschreibung oder einer Commit-Nachricht erwähnt (z. B. Fixes #847).

• Verknüpfte Branches: Wenn ein Entwickler in GitHubs Benutzeroberfläche einen Branch für ein Issue erstellt und später einen PR daraus öffnet.

Beide Aktionen lösen Ereignisse aus, die von herkömmlichen Tools ignoriert werden – doch sie sind der Schlüssel, um stille Übernahmen frühzeitig zu erkennen.

Zwei entscheidende GraphQL-Ereignisse und ihre Fallstricke

GitHubs timelineItems-Feld in den Issue-Daten gibt Auskunft über alle Ereignisse in der Historie eines Problems. Zwei spezifische Ereignistypen sind dabei besonders relevant:

• `CROSS_REFERENCED_EVENT`: Wird ausgelöst, wenn jemand die Issue-Nummer in einem PR oder Commit referenziert. Der PR fungiert hier als `source` des Ereignisses.

• `CONNECTED_EVENT`: Wird aktiviert, sobald ein mit dem Issue verknüpfter Branch zu einem Pull Request wird. In diesem Fall ist der PR das `subject` des Ereignisses.

Wichtig: Diese Unterscheidung zwischen source und subject ist ein häufiger Stolperstein. Wird sie übersehen, liefern die Abfragen zwar keine Fehler, aber auch keine Ergebnisse – was zu Frustration führt.

Die optimierte GraphQL-Abfrage

Um diese Ereignisse abzufragen, verwendet GitTrek folgende Struktur:

issue(number: $issueNumber) {
  timelineItems(
    first: 25,
    itemTypes: [CROSS_REFERENCED_EVENT, CONNECTED_EVENT]
  ) {
    nodes {
      ... on CrossReferencedEvent {
        source {
          ... on PullRequest {
            number
            state
            # Mögliche Zustände: OPEN | CLOSED | MERGED
            isDraft
          }
        }
      }
      ... on ConnectedEvent {
        subject {
          ... on PullRequest {
            number
            state
            isDraft
          }
        }
      }
    }
  }
  linkedBranches(first: 3) {
    totalCount
  }
}

Diese Abfrage sammelt alle relevanten Informationen in einem einzigen Durchgang und ermöglicht es GitTrek, die aktuelle Bearbeitungsstatus eines Issues sofort zu bewerten.

Echtzeit-Bewertung: So erkennt GitTrek stille PRs

Basierend auf den gesammelten Daten ordnet GitTrek Issues in vier Kategorien ein, die direkt in der Oberfläche angezeigt werden:

• 🔴 Aktiver PR: Es existiert ein offener, nicht im Entwurfsmodus befindlicher PR – das Issue ist stark umkämpft.

• 🟡 PR im Entwurfsmodus: Ein Entwickler hat einen PR erstellt, der sich noch in der Entwurfsphase befindet – hier ist Vorsicht geboten.

• 🟡 Branch existiert: Es gibt verknüpfte Branches, aber noch keinen PR – ein frühes Signal für bevorstehende Arbeit.

• ✅ Sicher zu übernehmen: Keine verknüpften PRs oder Branches gefunden – das Issue kann bedenkenlos bearbeitet werden.

Diese farblichen Markierungen ermöglichen es Nutzern, auf einen Blick zu erkennen, ob ein Issue bereits bearbeitet wird – ohne stundenlange Recherche.

Parallelisierte API-Abfragen für maximale Performance

Stell dir vor, du prüfst 20 Issues auf mögliche stille PRs. Ohne Optimierung müsstest du 21 API-Aufrufe hintereinander ausführen: einen für die initiale Suche und 20 weitere für die Statuschecks. Das würde die Benutzeroberfläche stark verlangsamen.

GitTrek löst dieses Problem durch parallele Abfragen im Hintergrund. Die Issues werden zunächst ohne die Wettbewerbsanalyse angezeigt, während die Status-Badges nachträglich „hydratisiert“ werden. Ein Codebeispiel verdeutlicht die Technik:

// Hintergrundabfragen für Badges werden parallel ausgeführt
const badges = await Promise.allSettled([
  fetch(`/api/github/badges/pull-shark?username=${user}`).then(r => r.json()),
  fetch(`/api/github/badges/starstruck?username=${user}`).then(r => r.json()),
  // Weitere Badges werden hier abgefragt
]);

// Extrahiere die Ergebnisse – selbst bei teilweisen Fehlern
const [pullShark, starstruck] = badges.map(result => 
  result.status === "fulfilled" ? result.value : null
);

// Verwende Fallback-Werte für fehlgeschlagene Abfragen
const psData = pullShark || { count: 0 };

Der entscheidende Vorteil: Selbst wenn eine einzelne Abfrage fehlschlägt (z. B. wegen Berechtigungsproblemen oder Ratenbegrenzungen), bleibt die gesamte Oberfläche funktionsfähig. GitTrek setzt hier auf Promise.allSettled statt Promise.all, um die Datenintegrität zu gewährleisten.

Mehr als nur stille PRs: Ein Rundum-Tool für Open-Source-Entwickler

GitTrek bietet weit mehr als nur die Erkennung stiller Pull Requests. Das Tool integriert zusätzliche Funktionen, die die Open-Source-Arbeit effizienter gestalten:

• Qualitätsfilter für Repositories: Nutzer können nach Sternen, Forks und der Existenz einer CONTRIBUTING.md-Datei filtern, um nur gut dokumentierte Projekte zu sehen.

• Live-Tracking von GitHub-Awards: Das Tool verfolgt den Fortschritt bei Badges wie Pull Shark, Galaxy Brain oder YOLO in Echtzeit – berechnet direkt über GitHubs GraphQL-API.

• Personalisierte Missionsvorschläge: Wenn ein Nutzer nur noch zwei PRs von einem Gold-Badge entfernt ist, schlägt GitTrek gezielte Suchanfragen vor, um genau die passenden Issues zu finden.

Einfacher Einstieg – ohne technische Hürden

GitTrek ist als Open-Source-Projekt kostenlos nutzbar und erfordert keine lokale Installation. Für die grundlegende Nutzung reicht ein Browser: Nutzer können Issues nach versteckten PRs durchsuchen, ohne sich anzumelden. Erst für personalisierte Funktionen wie das Badge-Tracking ist eine Verbindung mit dem GitHub-Konto erforderlich.

Die Live-Version des Tools ist unter gittrek.vercel.app erreichbar, während der Quellcode auf GitHub offen einsehbar ist.

Die Open-Source-Community verdient bessere Tools – und stille Übernahmen gehören endlich der Vergangenheit an. Probier GitTrek aus und vermeide unnötige Doppelarbeit! Welche Erfahrungen hast du mit diesem Problem gemacht? Teile deine Geschichte in den Kommentaren – wie oft bist du schon in diese Falle getappt?