2010-09-16 5 views
8

Tuve que transferir el código (todo el historial del proyecto) a otra tienda de desarrollo hoy y me preguntaba si sería una buena idea cerrar el repositorio de git al descubierto que nuestro equipo utiliza para la colaboración y simplemente enviarlo palabra por palabra.¿Es seguro cerrar los repositorios `git` y dárselos a otras personas?

¿Es seguro hacerlo como tal?
¿Hay datos confidenciales almacenados en una carpeta .git?

Respuesta

11

Si hace esto en lugar de utilizar clone o bundle entonces también estará dando su directorio .git/hooks, .git/config archivo y algunos otros archivos personalizables. No es común que esos archivos contengan datos confidenciales (lo sabría porque lo habría puesto ahí manualmente) pero pueden contener configuraciones personalizadas. Por ejemplo, puede haber configurado los ajustes de configuración user.name y user.email en .git/config. Es posible que hayas escrito algún script de enganche (en .git/hooks/*) que podría contener contraseñas, pero, como dije, probablemente ya lo sabrías.

Pero, git no almacena ninguna de sus contraseñas ni ningún otro dato secreto/confidencial.

+2

¡Derecho! El archivo '.git/config' puede ser sensible. +1 – VonC

4

Una solución similar sería git bundle.

Ver Backup of github repo o Backup a Local Git Repository para más.

.git (incluido o comprimido o comprimido) no contendrá ningún dato confidencial, excepto todo el historial y los archivos que ponga en él.
Consulte git - remove file from the repository por ejemplo para eliminar datos confidenciales.

Como Pat Notz menciona en his answer, un comprimido .git contendrá su .git/config.
Me doy cuenta de que el mío contiene algunas direcciones de repo remotas en las que tuve que poner mi [email protected] para que funcionen. Por lo tanto, no debe incluir ningún metadato local (como .git/config) porque deben ser ... locales.

7

Eche un vistazo en su directorio .git. Puede haber muchos archivos pero caen en una cantidad bastante pequeña de grupos regulares (datos de la tienda de objetos, refs, reflogs, etc.). Puede separar los contenidos en dos categorías principales: datos que Git normalmente podría transportar a otros repositorios y datos que Git normalmente no transportaría a otros repositorios.

No normalmente transportados:

  • HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD
  • config
  • description
  • hooks/
  • index
  • info/ - diverso
  • logs/ - reflogs

Normalmente transportados (por ejemplo,a través de los clones, se captan, se empuja y paquetes):

  • objects/
  • packed-refs
  • refs/

Este último grupo representa el almacén de objetos y sus puntos de entrada publicados. Obviamente tendrá que revisar el contenido versionado para determinar si hay algo sensible en él.

Los HEAD, index (no están presentes en un repositorio vacío) y los reflogs (logs/) son todos puntos de entrada adicionales en el almacén de objetos. Si ha reescrito alguna historia (por ejemplo, borró recientemente algún archivo de configuración sensible del historial grabado) querrá prestar especial atención a los reflogs (probablemente no habilitados en la mayoría de los repositorios desnudos) y la parte refs/original/de los refs espacio de nombres

FETCH_HEAD y config pueden tener las direcciones de repositorios Git relacionados.

config podría tener otra información confidencial.

info/ tiene varios bits de información; algunos de ellos podrían ser sensibles (información/alternativas); es menos probable que algunos sean sensibles (suponiendo que el contenido en sí mismo es "limpio" -info/refs, info/packs); algunos pueden ser importantes para el funcionamiento del repositorio (información/injertos). Cualquier herramienta adicional que estuviese usando (scripts de enlace, interfaces web, etc.) podría estar almacenando datos aquí; algunos de ellos pueden ser sensibles (listas de control de acceso, etc.).

Si hay algo activo en hooks/, querrá evaluar si debe proporcionarse con la copia del repositorio (también verifique si almacena datos adicionales en cualquier parte del repositorio).

El archivo description es probablemente inocuo, pero también puede comprobarlo.


Si sólo va a dar el relevo el contenido, entonces debería probablemente sólo clonar a un repositorio desnudo fresco o utilizar un paquete (como git bundleVonC describes).

Si usted es responsable de distribuir el contenido y el proceso que utiliza para administrarlo, entonces deberá investigar cada bit del repositorio individualmente.


En general (o de una manera más “paranoico”), hay muchos lugares dentro de la jerarquía de un repositorio Git en la que alguien podría almacenar cualquier archivo aleatorio. Si quiere asegurarse de que solo está regalando datos que Git necesita, debe usar un clon o conjunto. Si necesita proporcionar algunos de sus datos "por repositorio" (por ejemplo, un enlace utilizado para administrar el repositorio), debe clonar en un repositorio nuevo (use una dirección URL file: para evitar copiar y enlazar archivos de almacenamiento de objetos existentes) y reinstalar solo los ganchos/datos que se necesitan para cumplir con sus obligaciones.

+0

Agradable - muchos buenos detalles. –

+0

Como dice el caballero, hay muchos detalles. +1 – VonC

Cuestiones relacionadas