... ¿particularmente cuando se mueve a través de unidades flash USB FAT32 o exFAT?
Aunque la copia de trabajo probablemente sufrirá cambios de permisos y una eliminación obvia de enlaces simbólicos (si los usa)... que son cambios que Git detectará muy bien, aparte de eso,¿El .git/contenido del directorio es lo suficientemente sólido como para permitir mover un repositorio de un sistema operativo y/o sistema de archivos a otro?por ejemplo, Windows, distribuciones comunes de Linux, macOS, NTFS, ext FS,APF...
Puedo asumir Git versión 2+ si es necesario.
Respuesta1
Sí, la base de datos del repositorio esgeneralmenteportátil en todos los sistemas operativos modernos,incluidoVentanas. No depende de ningún atributo extendido y, hasta ahora, tampoco depende de la distinción entre mayúsculas y minúsculas. Los nombres de archivos dentro de la base de datos parecen tener un máximo de 52 caracteres.
El requisito principal es que los nombres de archivospreservarsu caso, incluso en sistemas de archivos que no distinguen entre mayúsculas y minúsculas (por ejemplo, si copia .git/HEAD de ext4 a FAT32 a APFS a HFS+ a ext4, debería permanecer .git/HEAD y no convertirse en .git/head). Afortunadamente, todos los sistemas de archivos enumerados anteriormentesonpreservación de mayúsculas y minúsculas, así que está bien.
Una cosa a tener en cuenta es que cada rama o etiqueta se representa como un archivo independiente en .git/refs. Git impone un límite estricto en el conjunto de caracteres para poder trabajar con cualquier sistema de archivos, pero eso no siempre es suficiente; si va a pasar a un sistema de archivos que no distingue entre mayúsculas y minúsculas (como APFS o NTFS), es mejor que el repositorio no contenga múltiples ramas o etiquetas que difieren solo en caso. Del mismo modo, Git no prohíbe el uso de nombres de dispositivos DOS heredados, como auxnombres nulde ramas/etiquetas.
(Técnicamente, mover el repositorio a través de diferentes sistemas de archivos puede perder algunos metadatos del archivo, como el a-westado de "solo lectura" ( ) de los blobs de objetos, pero esto no es algo que Git analice de todos modos).
Si usa FAT32 solo como transporte temporal, considere usar git pack-refs --all --pruney rm -rf .git/logspara evitar problemas con el nombre de la sucursal, por improbables que sean. Ejecute también a git repack -d; git prunepara reducir la cantidad de archivos de objetos sueltos.
Incluso puede utilizarlo git bundlepara crear un blob compatible con el transporte que contenga todo o parte del historial de confirmaciones.
Respuesta2
Si bien copiar el .gitdirectorio funcionará en la mayoría de los casos, hay algunas advertencias que requieren atención:
git-svn puede recordar cierta información del usuario que no desea copiar, como el nombre y la dirección de correo electrónico, por ejemplo en
.git/logs/refs/remotes/trunk.Un repositorio clonado contendrá un enlace al principal que el comando de copia no cancelará. Puedes eliminar ese enlace usando
git remote remove origin.Si tiene enlaces simbólicos en el
.gitdirectorio, querrá asegurarse de eliminar la referencia a ellos. Por ejemplo:cp -r -L <source-repo-dir> <destination-repo-dir>Algunos elementos de configuración pueden variar según la plataforma, como controladores de diferencias personalizados y scripts de enlace que hacen referencia a programas externos. Al copiar entre diferentes plataformas se deben verificar elementos como
core.ignorecase,core.autocrlf, ycore.safecrlfprobablementecore.fileModealgunos otros.clon de git es una operación segura que puede operar entre computadoras:
git clone ssh://[email protected]/path/to/my-project.gitLa clonación crea automáticamente una conexión remota llamada "origen" que apunta al repositorio original, lo que facilita la interacción con un repositorio central.
Puede que le resulte interesante leer el siguiente tutorial para mover selectivamente un directorio git: