Git & Version Control
Eine Repository- oder Datei-URL untersuchen und vor dem Kopieren die Grenze zwischen Ref und Pfad prüfen.
Die URL wird in diesem Browser verarbeitet. Keine Anfrage an GitHub.
Den bereits in der URL enthaltenen Branch, Tag oder Commit decodiert eingeben. Das legt die Grenze fest und wechselt keinen Branch. Bei Repository-URLs leer lassen.
Eine URL bis 8192 UTF-16-Einheiten, Ref bis 1024. Nur HTTPS, ohne Zugangsdaten oder expliziten Port.
Wird umgewandelt…
Wer eine GitHub URL umwandeln möchte, hat häufig einen Link aus einem Review, während ein Skript den reinen Dateiinhalt erwartet. Die getrennten Felder zeigen, welcher Teil die Version bestimmt und welcher die Datei bezeichnet. So lässt sich die Adresse prüfen, bevor sie in einer Konfiguration landet.
Hier können Sie eine GitHub URL umwandeln und beide Dateiadressen vergleichen. Aus einem GitHub Raw Link wird wieder eine Dateiseite, aus einer Blob-Seite eine Raw-Adresse. Die Repository-Wurzel bleibt eine Wurzel; main und README werden nicht hinzuerfunden.
Bei feature/docs/guide.md ist die Ref-Grenze unklar. Zunächst wird feature angenommen. Mit der ausdrücklichen Angabe feature/docs bleibt guide.md als Dateipfad übrig. Eine nicht passende Angabe führt zum Fehler und ändert nicht heimlich den Branch.
Blob-Seiten und Raw-Adressen werden unterstützt. Ein tree-Link bezeichnet dagegen einen Ordner. Bei einer Repository-Wurzel wird lediglich die Repository-Adresse erzeugt.
Die Ref muss am Anfang des URL-Rests stehen und vollständige Segmente verbrauchen. Bei refs/heads oder refs/tags geben Sie nur den nachfolgenden Namen an.
Jede Eingabeänderung sperrt Kopieren und Download bis zur nächsten Umwandlung. Ohne Automatik starten die Schaltfläche oder Ctrl/Cmd + Enter den Vorgang.
Eigentümer, Repository, Ref und Dateipfad erscheinen einzeln. Auch die Grundlage der Aufteilung ist sichtbar. Eine vollständige Commit-ID mit 40 Zeichen wird syntaktisch erkannt; ein kurzer Hash bleibt eine ungeprüfte Referenz.
github.com/raw und raw.githubusercontent.com werden zur passenden Blob-Ansicht ergänzt. Ein vorhandener Namensraum heads oder tags bleibt erhalten. Ein Branch-Name und ein Tag gleichen Namens werden dadurch nicht absichtlich gleichgesetzt.
Leerzeichen werden als %20 und echte Prozentzeichen als %25 ausgegeben. Ein codiertes Fragezeichen bleibt Teil des Dateinamens. Jedes Segment wird einmal decodiert; bereits vorhandene Escape-Sequenzen werden nicht blind erneut maskiert.
Öffnen Sie die Datei auf GitHub und wählen Sie Raw. Alternativ erzeugt die Blob-URL hier die Adresse des Raw-Hosts. Die Repository-Wurzel allein enthält weder Ref noch Dateinamen; dafür wird keine Datei erfunden.
Branches und Tags können auf andere Commits verschoben werden. Verwenden Sie für eine feste Version eine URL mit vollständiger Commit-ID. Auf der GitHub-Dateiseite schaltet Y zum Permalink um; dieses Werkzeug kann die ID nicht nachschlagen.
Eine Umwandlung erteilt keine Leserechte für private Repositories. Raw-Links können temporäre Autorisierung voraussetzen. Query-Token werden hier entfernt und Zugangsdaten im Hostteil abgelehnt. Der ausgegebene Link ist deshalb kein autorisierter Freigabelink.
Ob der Browser eine Datei herunterladen oder anzeigen wird, hängt von den Antwortheadern und seinem Verhalten ab. Eine neue URL kann MIME-Typ und Content-Disposition nicht erzwingen. Der Download hier speichert nur den lokalen JSON-Bericht.
Git erlaubt Schrägstriche in Referenznamen. Die URL liefert somit nicht immer eine eindeutige Trennstelle. Prüfen Sie die erste angenommene Ref und geben Sie bei bekanntem Namen die vollständige Referenz an. Sie muss mit der bestehenden Adresse übereinstimmen.
Noch eine Frage zu einem GitHub-Link?
Jetzt die nächste GitHub URL umwandeln, die decodierten Felder prüfen und die passende Dateiadresse kopieren. Der JSON-Bericht hält die gewählte Aufteilung für eine spätere Prüfung fest.