Guía de la versión preliminar · 0.1.0
Proteger el historial que vas a enviar
Aprueba y aplica protección a un clon, inspecciona su historial confirmado saliente y entiende la razón exacta de un bloqueo.
La referencia de la API está en inglés.
Aplica protección al clon previsto
La protección de push usa un hook Git local instalado explícitamente. Un análisis fallido o un control configurado no lo instala. Empieza con el perfil conectado, el repositorio exacto autorizado y los analizadores preparados.
- Ejecuta CodeSecurity: Protect Pushes… en VS Code. La paleta pide elegir repositorio; el menú de repositorio de Source Control usa el clon seleccionado.
- Comprueba su identidad. Resuelve selecciones obsoletas o ambiguas antes de continuar.
- Solicita acceso al repositorio y aprueba esa generación exacta del editor en el navegador del propietario asociado. La pertenencia IDE ordinaria no concede este permiso.
- Elige el ajuste solicitado On y pulsa explícitamente Apply en VS Code.
- Lee el estado del host y resuelve conflictos de hooks antes de confiar en la protección.
La protección pertenece a este clon. Comprueba el estado observado después de aplicar la política solicitada.
Abrir la imagen completaEl ajuste web registra el estado solicitado. Change pending · Apply in VS Code significa que el host no lo ha aplicado. También ocurre al pedir Off: un hook On ya aplicado puede seguir bloqueando hasta aplicar el cambio. On · last verified y Off · last applied describen la última observación.
El hook invoca un auxiliar empaquetado por separado; puede funcionar con el editor cerrado si el backend necesario está disponible. La instalación conserva otros hooks y la configuración local de su ruta; rechaza conflictos que no puedan combinarse con seguridad. No cambia ajustes globales de Git ni remotos.
Revisa los commits salientes antes del push
Ejecuta CodeSecurity: Check Outgoing Commits… desde la paleta o el menú Source Control del repositorio previsto. Selecciona destino configurado, rama o etiqueta local y referencia remota explícita. Revisa el alcance antes de enviar instantáneas y análisis. Este comando comprueba; no hace push.
- Aprueba y aplica el clon exacto
Aprobación y aplicación en host son distintas del acceso IDE ordinario o del análisis del espacio.
- Resuelve el plan saliente
Vincula destino, refs, commits y árboles inmutables previstos. El historial anterior también viaja al remoto.
- Comprueba evidencia aplicable al árbol
Si se envían árboles, exige identidad actual del analizador, cobertura completa y análisis terminado para el plan.
- Evalúa política y permisos actuales
Vuelve a comprobar política, decisiones y permiso de repositorio contra el plan exacto.
- Lee la decisión
Un rechazo explica qué reconciliar. Refs o evidencia cambiadas exigen otra comprobación aplicable.
La comprobación vincula repositorio canónico, pares de refs y objetos salientes, árboles inmutables, cobertura autorizada, política actual y evidencia. Un análisis de espacio de trabajo, archivo, carpeta o el último seleccionado en la web no sustituye ese historial confirmado.
Por ejemplo, un secreto añadido en un commit saliente y eliminado en el siguiente sigue viajando en el anterior. Una punta limpia no lo borra. Revisa el árbol histórico fallido en vez de volver a analizar solo los archivos actuales.
Cada repositorio tiene resultado independiente. Contenido inmutable sin cambios puede reutilizar evidencia aplicable, pero cambiar refs, política, decisiones o identidad del analizador o datos puede invalidar una aprobación. Consultar el catálogo no instala datos nuevos. La preparación actual sigue determinando si la evidencia es utilizable.
Lee el resultado del plan exacto
Un push con código necesita evidencia completa, aplicable y aprobada. Verificación ausente, fallida, obsoleta, parcial, cancelada o no disponible lo bloquea. Desactivar el control no produce aprobación; cambiar decisiones no rellena huecos de cobertura.
Un plan solo de eliminación o sin efectos no tiene árbol saliente que analizar. Puede terminar sin ejecutar analizadores, pero siguen aplicándose aprobación y política actual. Lee el plan real; una lista vacía no prueba que carezca de árboles.
Cancelar detiene el trabajo actual cancelable y conserva resultados anteriores. Una comprobación cancelada conservada puede ofrecer Start new check, mostrando alcance e identidades previas de trabajo y análisis. Aceptarlo vuelve a comprobar el estado y puede reutilizar evidencia completa aplicable. No reclasifica la cancelada como aprobada.
Diagnostica un push bloqueado
Las notificaciones normales de Git o GitLens pueden recomendar genéricamente hacer pull. Abre Show Command Output en VS Code u Open Output Channel en GitLens y lee el resultado real. Si dice Lomo blocked this push, vuelve a protección y a la comprobación saliente de ese clon.
Usa Review blocking findings tras un análisis saliente terminado con fallo. Abre el análisis exacto del árbol confirmado; elige el previsto si fallaron varios árboles. La evidencia histórica no abre el archivo actual como si fuera el árbol comprobado. Open protection settings abre el registro del repositorio sin modificar control ni permiso.
Una rama no publicada, un remoto sin configurar o Nothing to push pueden detener el cliente antes del hook. No establecen una autorización de CodeSecurity. Confirma rama y destino de Git además del resultado de seguridad.
Reconoce los límites de cobertura
La cobertura abarca archivos regulares en árboles de commits nuevos salientes. Mensajes de commits, etiquetas y otros metadatos no son entradas de archivo del analizador. Se rechazan enlaces simbólicos no admitidos, submódulos, repositorios superficiales, almacenes alternativos de objetos y cobertura no verificable.
| Límite | Valor actual |
|---|---|
| Un push | 64 refs, 256 commits distintos comprobados y 32 KiB de entrada del hook. |
| Un árbol inmutable | 5.000 archivos regulares, 8 MiB transferidos por archivo y 64 MiB de contenido total. |
| Análisis de código apto | 1 MiB por archivo; uno mayor deja incompleta la cobertura. |
| Rutas | 64 componentes y 4.096 unidades UTF-16; se rechazan rutas inseguras. |
| Un comando acotado de metadatos Git | 4 MiB de salida. |
Una ref remota existente requiere su commit antiguo disponible localmente. Una rama nueva no tiene base antigua: todo historial alcanzable desde la punta cuenta para el límite aunque otra rama remota contenga parte. La comprobación no descarga objetos ausentes ni trunca el historial silenciosamente.
Un rechazo por límite no aprueba ningún push. Reduce refs cuando resuelva ese límite, o acuerda una vía de revisión y aplicación aprobada por separado para historial o árboles no admitidos. Un análisis menor del espacio de trabajo no aporta la evidencia ausente.
Desactiva o elimina la protección
Poner Off exige su advertencia y aplicación explícita en el host. Cancelar deja el ajuste intacto. Tras aplicar Off, el auxiliar no lee código, no requiere API en línea ni impone límites de código y refs exclusivos de On. Registro y configuración del hook se conservan para reactivación explícita.
Eliminar es otra acción. En el perfil propietario exacto, elige Protect Pushes… > Remove push protection from this clone… y confirma el repositorio. Solo elimina el hook Lomo sin cambios, su registro y concesiones y vínculos específicos. Conserva proyectos, análisis, hallazgos, instantáneas, asociación general, remotos y hooks ajenos.
Un proyecto aún usado por protección o su fuente de instantáneas Git no puede borrarse, incluso con Off. Elimina primero el registro si quieres borrar después el proyecto.
Si la eliminación local funciona pero la limpieza del servidor no está disponible, reintenta desde el mismo perfil cuando vuelva el servicio. Los hooks cambiados o desconocidos se conservan. Tras revocar y reinscribir un editor, solicita aprobación para la nueva generación y aplica de nuevo; no hereda la concesión antigua.
Prueba sin publicar código
Para una comprobación manual deliberada, usa un repositorio desechable y un remoto bare local exacto. Usa hallazgos sintéticos y verifica refs antes y después de pushes Git ordinarios. Un bloqueo debe dejarlas intactas; una aprobación solo debe cambiar las previstas. Incluye historial anterior problemático seguido de una punta limpia para que comprobar solo la punta no parezca suficiente.
El propietario puede eludir el hook o usar otro clon. Mantén controles remotos adecuados donde la aplicación deba ser inevitable. Una prueba manual correcta cubre los casos ejercitados, no todas las plataformas, refs o recuperaciones.
Consulta decisiones del control, revisión de hallazgos y API de protección Git para controles relacionados.