---
title: Protegiendo repositorios de Git con Latch y Latch-cmd (Parte 1)
description: n este caso vamos a ver cómo utilizar esta sencilla aplicación para proteger repositorios de Git frente a pushes no deseados, haciendo uso de hooks.
---

[Descubre los contenidos más relevantes sobre tecnología ](https://conasa.grupocibernos.com/blog)

# [Protegiendo repositorios de Git con Latch y Latch-cmd (Parte 1)](https://conasa.grupocibernos.com/blog/protegiendo-repositorios-git-latch-latch-cmd-parte-1)

 Escrito por [Conasa](https://conasa.grupocibernos.com/blog/author/conasa) | 28-jul-2016 14:08:10

En mi [anterior entrada](https://www.conasa.es/blog/potenciando-latch-traves-los-plugins-golatch-latch-cmd/) os hablé acerca del proyecto *latch-cmd* y el [concurso de plugins de Latch 2015](http://blog.elevenpaths.com/2016/04/ya-tenemos-los-ganadores-de-nuestros.html). El pasado día 26 de mayo estuve en Madrid presentando este proyecto en el [Security Day 2016](https://securityday.elevenpaths.com/eventcontent/sd2016) , junto con el resto de premiados en los concursos de *Latch* y *Sinfonier*. El evento estuvo genial (¡enhorabuena a todo el equipo de Eleven Paths!) y lo podéis ver completo en esta [lista de Youtube](https://www.youtube.com/watch?v=dd9UfIUyz7o&list=PLwRVFywsfVOAzx-FDT1kvZgeWnHLwT7bz), donde también están las [presentaciones de los plugins ganadores de ambos concursos](https://www.youtube.com/watch?v=9efO10zZz64&list=PLwRVFywsfVOAzx-FDT1kvZgeWnHLwT7bz&index=10).

Como también os adelanté, en esta entrada veremos cómo aplicar *Latch-cmd* a un caso práctico. En este caso vamos a ver cómo utilizar esta sencilla aplicación para proteger repositorios de *Git* frente a *pushes* (subidas de código) no deseados, haciendo uso de hooks.

## Qué vamos a hacer

Supongamos que tenemos un servidor propio o *self-hosted* (no servicios como *Github* o *Bitbucket*) en el que alojamos repositorios de *Git* (y que utilizamos seguramente como repositorio maestro o punto de encuentro entre varios desarrolladores) y queremos tener la posibilidad de bloquear los *pushes* o subidas de código a determinados repositorios o ramas de los mismos, de manera que podamos gestionar desde la aplicación móvil de *Latch* estos bloqueos.

Así por ejemplo, si *latcheamos* (bloqueamos) una rama de un repositorio y algún usuario trata de hacer un *push* a la misma con nuevos *commits*, recibirá un error indicándole que la rama está bloqueda y debe esperar a que sea desbloqueada o consultar con el administrador del repositorio. Esto puede ser muy útil para congelar el estado de un repositorio o rama concreta, por ejemplo mientras se prepara una nueva *release*, se realiza una *review* de código o se llevan a cabo tareas de mantenimiento.

Para ello utilizaremos *Latch-cmd* y un sencillo *hook* que se ejecutará siempre que se haga un *push* a un repositorio y comprobará que la rama no esté bloqueada (protegida con *Latch* y con el pestillo activado) antes de permitir realizar las actualizaciones.

## Qué necesitamos

Para llevar a cabo esta integración es necesario tener una máquina (preferiblemente GNU/Linux) con [Git](https://git-scm.com/) y [Latch-cmd](https://github.com/millenc/latch-cmd) instalados, donde alojaremos nuestros repositorios protegidos con *Latch*. Para que sea más sencillo *trastear* con este ejemplo, he preparado una pequeña configuración con *Vagrant* que puedes encontrar [aquí](https://github.com/millenc/git-latch) y basta con clonar en un directorio cualquiera y hacer *vagrant up* para arrancar una máquina virtual con todo lo necesario instalado.

Como es lógico, también necesitamos tener una cuenta de desarrollador de *Latch* (podéis registraros [aquí](https://latch.elevenpaths.com/www/)), ya que tendremos que crear una aplicación para gestionar los pestillos de nuestros repositorios.

## Paso 1: Crear la aplicación de Latch y parear una cuenta

El primer paso es crear una aplicación en *Latch*. Para ello basta con iniciar sesión en el [área de desarrolladores](https://latch.elevenpaths.com/www/login) y en la sección *Mis aplicaciones* pulsar en *Añadir una nueva aplicación*. En mi caso voy a llamarla *Git Latch*, pero se le puede poner el nombre que se prefiera (no es importante). Esta será la aplicación que utilizaremos para gestionar todos nuestros repositorios de *Git* protegidos con *Latch*.

Una vez creada la aplicación, el siguiente paso es crear **operaciones** que se asociarán con cada una de los repositorios y ramas de los mismos. La aplicación *Git Latch* actuará como un pestillo maestro, de manera que si está activo no se permitirán *pushes* a ninguno de los repositorios protegidos con este sistema.

Lo que vamos a hacer es crear una operación por cada repositorio que queramos proteger con *Latch* y por cada rama de dicho repositorio una suboperación. Por ejemplo, supongamos que tenemos un repositorio alojado en el directorio /srv/git/my_repo que tiene dos ramas; master y dev. Para este repositorio deberemos crear la siguiente estructura de operaciones:

[responsive]<https://static.hsstatic.net/BlogImporterAssetsUI/ex/missing-image.png>[/responsive]

Una vez creada la aplicación y las operaciones correspondientes a nuestros repositorios y sus respectivas ramas deberemos parear una cuenta con esta aplicación, para lo que podemos utilizar *Latch-cmd*. Desde la aplicación móvil de *Latch* basta con pulsar en *Añadir nuevo servicio* y después en *Generar nuevo código* para obtener el token. Una vez que aparezca el token en la pantalla podemos utilizar el siguiente comando de *Latch-cmd* para parearlo con nuestra aplicación:

```
$ latch-cmd app pair --app=YUWWMMA8wLwQmKPXeb6F --secret=MuRC6y68Xh3KQXMW2tmYxKjfw89BJxguyrLXNXE4 --token=MiToken
```

**NOTA: Sustituye los parámetros –app y –secret por los correspondientes a tu aplicación y el parámetro –token por el código que aparece en la aplicación móvil.*

Si los datos son correctos, *Latch-cmd* pareará la cuenta y nos devolverá el **ID de cuenta,** que es MUY importante que guardemos, ya que lo necesitaremos más adelante. Además, en la aplicación móvil de *Latch* nos aparecerá el nuevo servicio *Git Latch* con la estructura de repositorios y ramas que hayamos definido:

[responsive]<https://static.hsstatic.net/BlogImporterAssetsUI/ex/missing-image.png>[/responsive]

[responsive]<https://static.hsstatic.net/BlogImporterAssetsUI/ex/missing-image.png>[/responsive]

[responsive]<https://static.hsstatic.net/BlogImporterAssetsUI/ex/missing-image.png>[/responsive]

Como se puede ver, podemos bloquear repositorios a nivel de rama o suboperación (solo los *pushes* a esa rama serán bloqueados), repositorio u operación (todas las ramas protegidas por *Latch* del repositorio son bloqueadas) y aplicación (todas las ramas de todos los repositorios), por lo que tenemos bastante libertad a la hora de gestionar el acceso a nuestros repositorios.

## Conclusiones

Con esto ya tenemos creada nuestra aplicación en *Latch* y definidos el repositorio y ramas que queremos proteger. Además, hemos pareado esta aplicación con nuestro móvil, que utilizaremos para controlar el acceso a los repositorios. En la siguiente entrada veremos cómo proteger los repositorios de *Git* creando un sencillo *hook* y utilizando *Latch-cmd*.

 

[Ver post completo](https://conasa.grupocibernos.com/blog/protegiendo-repositorios-git-latch-latch-cmd-parte-1)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Conasa"
  },
  "dateModified" : "2023-05-25T09:16:37.041Z",
  "datePublished" : "2016-07-28T14:08:10Z",
  "headline" : "Protegiendo repositorios de Git con Latch y Latch-cmd (Parte 1)",
  "image" : {
    "@type" : "ImageObject",
    "height" : 60,
    "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
    "width" : 60
  },
  "mainEntityOfPage" : "https://conasa.grupocibernos.com/blog/protegiendo-repositorios-git-latch-latch-cmd-parte-1",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60.0,
      "url" : "https://www.cibernos.com/hubfs/logo-conasa%20(1).png",
      "width" : 142.85715
    },
    "name" : "Conasa Blog"
  }
}
```