Anleitung zur Quellcode-Vorschau · 0.1.0

Die zu pushende Historie schützen

Genehmige und aktiviere Schutz für einen Klon, prüfe seine ausgehende Commit-Historie und verstehe den genauen Blockierungsgrund.

Die API-Referenz ist auf Englisch.

Wende Schutz auf den vorgesehenen Klon an

Push-Schutz nutzt einen ausdrücklich installierten lokalen Git-Hook. Ein fehlgeschlagener Scan oder konfiguriertes Projekt-Gate installiert ihn nicht. Beginne mit verbundenem Editorprofil, genauem autorisiertem Quellrepository und vorbereiteten Scannern.

1. Führe CodeSecurity: Protect Pushes… in VS Code aus. Die Befehlspalette fragt nach einem Repository; ein Source-Control-Repositorymenü verwendet den ausgewählten Klon.
2. Prüfe die Repository-Identität. Kläre eine veraltete oder mehrdeutige Auswahl vor dem Fortfahren.
3. Fordere Repository-Zugriff an und genehmige genau diese Editorgeneration im gekoppelten Eigentümerbrowser. Gewöhnliche IDE-Mitgliedschaft erteilt diese Erlaubnis nicht.
4. Wähle den angeforderten Zustand On und ausdrücklich Apply in VS Code.
5. Lies den gemeldeten Hostzustand und behebe Hookkonflikte, bevor du dich auf den Schutz verlässt.

Die Webeinstellung speichert den angeforderten Zustand. Change pending · Apply in VS Code bedeutet, dass der Host ihn noch nicht angewandt hat. Das gilt auch für Off: Ein bereits angewandter On-Hook kann bis zur Anwendung der Änderung weiter blockieren. On · last verified und Off · last applied beschreiben die letzte Beobachtung.

Der lokale Hook ruft einen separat gebündelten Helfer auf und kann daher bei geschlossenem Editor arbeiten, solange das benötigte Backend verfügbar ist. Die Installation erhält fremde Hooks und lokale Hookpfadkonfiguration; nicht sicher kombinierbare Konflikte werden abgelehnt. Globale Git-Einstellungen und Remotes bleiben unverändert.

Prüfe ausgehende Commits vor dem Push

Führe CodeSecurity: Check Outgoing Commits… über Befehlspalette oder Source-Control-Menü des vorgesehenen Repositorys aus. Wähle konfiguriertes Ziel, lokalen Branch oder Tag und ausdrückliche Remote-Referenz. Prüfe den Umfang vor dem Einreichen von Momentaufnahmen und Scans. Dieser Befehl prüft, führt aber keinen Push aus.

Die Prüfung bindet kanonisches Repository, ausgehende Ref-/Objektpaare, unveränderliche Quellbäume, autorisierte Abdeckung, aktuelle Richtlinie und Scannernachweise. Ein Arbeitsbereichs-, Datei- oder Ordnerscan oder der zuletzt ausgewählte Webscan ersetzt diese Commit-Historie nicht.

Ein Geheimnis, das etwa in einem ausgehenden Commit hinzugefügt und im nächsten entfernt wurde, reist im früheren Commit weiterhin mit. Ein sauberer Tip löscht es nicht. Prüfe den gescheiterten historischen Baum, statt nur die neuesten Arbeitsdateien erneut zu scannen.

Jedes Repository hat ein eigenes Ergebnis. Unveränderte unveränderliche Inhalte können anwendbare Nachweise wiederverwenden; geänderte Refs, Richtlinien, Befundbewertungen oder Scanner-/Datenidentitäten können Freigaben jedoch ungültig machen. Allein die Prüfung des kuratierten Katalogs installiert keine neuen Scannerdaten. Aktuelle Bereitschaft entscheidet weiterhin über die Nutzbarkeit von Nachweisen.

Lies das Ergebnis für den genauen Plan

Ein Push mit Quellen verlangt abgeschlossene, anwendbare und bestandene Nachweise. Fehlende, fehlgeschlagene, veraltete, teilweise, abgebrochene oder nicht verfügbare Verifikation blockiert ihn. Deaktivieren des Gates erzeugt kein Bestehen; geänderte Bewertungen schließen keine Abdeckungslücken.

Ein reiner Lösch- oder No-op-Plan hat keinen ausgehenden Quellbaum zu scannen. Er kann ohne Scannerlauf abschließen, während Repository-Freigabe und aktuelle Richtlinie weiter gelten. Lies den tatsächlichen Plan, statt aus einer leeren Befundliste auf Baumfreiheit zu schließen.

Abbruch einer Prüfung stoppt ihren aktuellen abbrechbaren Job und erhält frühere Ergebnisse. Eine erhaltene abgebrochene Prüfung kann Start new check mit Umfang und früheren Job- und Scanidentitäten anbieten. Annahme prüft den aktuellen Zustand erneut und kann anwendbare abgeschlossene Nachweise nutzen. Sie benennt die abgebrochene Prüfung nicht in bestanden um.

Untersuche einen blockierten Push

Normale Git- oder GitLens-Meldungen empfehlen möglicherweise allgemein einen Pull. Öffne Show Command Output in VS Code oder Open Output Channel in GitLens und lies das tatsächliche Ergebnis. Bei Lomo blocked this push kehre zu Schutz und ausgehender Prüfung dieses Klons zurück.

Nutze Review blocking findings nach einem abgeschlossenen gescheiterten ausgehenden Scan. Es öffnet den genauen Scan des festgehaltenen Baums; wähle den vorgesehenen Scan, wenn mehrere Bäume scheitern. Historische Nachweise können die aktuelle Arbeitsbereichsdatei nicht öffnen, als wäre sie der geprüfte Baum. Open protection settings öffnet den Repository-Datensatz ohne Änderung von Gate oder Berechtigung.

Ein unveröffentlichter Branch, fehlende Remote-Einrichtung oder Nothing to push kann den Client vor dem Hook stoppen. Solche Meldungen belegen keine CodeSecurity-Freigabe. Bestätige normalen Git-Branch und Ziel ebenso wie das Sicherheitsergebnis.

Erkenne Abdeckungsgrenzen

Die Abdeckung betrifft reguläre Dateiinhalte neu ausgehender Commit-Bäume. Commit- und Tagmeldungen sowie sonstige Git-Metadaten außerhalb von Dateien sind keine Scannereingaben. Nicht unterstützte Symlinks, Submodule, flache Repositories, alternative Objektspeicher oder nicht verifizierbare Abdeckung werden abgelehnt.

Bei einem bestehenden Remote-Ref muss der alte Commit lokal verfügbar sein. Ein neuer Branch hat keine alte Basis, daher zählt die gesamte vom Tip erreichbare Historie gegen das Commitlimit, auch wenn ein anderer Remote-Branch Teile enthält. Die Prüfung lädt fehlende Objekte nicht stillschweigend und kürzt die Historie nicht.

Eine Limitablehnung genehmigt keinen Push. Verkleinere die Refauswahl, wenn dies das Reflimit behebt, oder vereinbare einen separat genehmigten Prüf- und Durchsetzungsweg für nicht unterstützte Historien oder Bäume. Ein kleinerer Arbeitsbereichsscan liefert die fehlenden Nachweise nicht.

Schalte Schutz aus oder entferne ihn

Off verlangt die Warnung und ausdrückliche Anwendung auf dem Host. Abbrechen lässt die Einstellung unverändert. Nach angewandtem Off liest der Helfer keine Quellen, benötigt keine Online-API und erzwingt keine nur für On geltenden Quell- und Reflimits. Registrierung und Hookkonfiguration bleiben für ausdrückliches Reaktivieren erhalten.

Entfernen ist eine separate Aktion. Wähle im genauen Eigentümerprofil Protect Pushes… > Remove push protection from this clone… und bestätige das Repository. Entfernt werden nur der unveränderte Lomo-eigene Hook, die Schutzregistrierung und repositoryspezifische Freigaben und Bindungen. Projekte, Scans, Befunde, aufbewahrte Momentaufnahmen, allgemeine Kopplung, Remotes und fremde Hooks bleiben erhalten.

Ein noch vom Schutz oder seiner Git-Momentaufnahmequelle genutztes Projekt kann auch bei Off nicht gelöscht werden. Entferne zuerst die Registrierung, wenn du anschließend separat das Projekt löschen möchtest.

Gelingt lokales Entfernen bei nicht verfügbarer Serverbereinigung, wiederhole es im selben Profil, sobald der Dienst zurückkehrt. Geänderte oder unbekannte Hookdateien bleiben erhalten. Fordere nach Widerruf und Neueinschreibung eines Editors die Freigabe seiner neuen Generation an und wende Apply erneut ausdrücklich an; alte Repository-Freigaben werden nicht geerbt.

Teste ohne Quellen zu veröffentlichen

Nutze für eine bewusste manuelle Prüfung ein Wegwerf-Repository und ein genaues lokales Bare-Remote. Verwende synthetische Befunde und prüfe Remote-Refs vor und nach gewöhnlichen Git-Pushes. Eine Blockierung muss sie unverändert lassen; ein erlaubter Push darf nur vorgesehene Refs ändern. Nimm problematische frühere Historie mit anschließend sauberem Tip auf, damit eine reine Tip-Prüfung nicht ausreichend erscheint.

Ein Eigentümer kann einen lokalen Hook umgehen oder einen anderen Klon nutzen. Erhalte passende Remotekontrollen, wenn Durchsetzung unumgehbar sein muss. Eine erfolgreiche manuelle Prüfung deckt ausgeführte Fälle ab, nicht jede Plattform, jeden Reftyp oder Wiederherstellungsweg.

Lies Gate-Entscheidungen, Befundprüfung und die Git-Schutz-API für zugehörige Funktionen.