...особенно при перемещении через USB-флеш-накопители FAT32 или exFAT?
Даже несмотря на то, что рабочая копия, вероятно, пострадает от изменения прав доступа и очевидного удаления символических ссылок (если они используются)... эти изменения Git прекрасно обнаружит, кроме этого,достаточно ли .git/надежно содержимое каталога, чтобы позволить переместить репозиторий из одной операционной системы и/или файловой системы в другую?например, Windows, распространенные дистрибутивы Linux, macOS, NTFS, ext FS,АПФС...
При необходимости я могу предположить версию Git 2+.
решение1
Да, база данных репозитория естьобычнопереносим на все современные операционные системы,включаяWindows. Он не полагается ни на какие расширенные атрибуты и пока не полагается на чувствительность к регистру. Имена файлов внутри базы данных, похоже, имеют длину максимум 52 символа.
Главное требование — чтобы имена файловсохранятьих случае, даже на файловых системах, нечувствительных к регистру (например, если вы копируете .git/HEAD из ext4 в FAT32, затем в APFS, затем в HFS+, затем в ext4, он должен остаться .git/HEAD, а не стать .git/head). К счастью, все файловые системы, перечисленные выше,являютсясохранение регистра, так что это нормально.
Следует помнить, что каждая ветвь или тег представлены в виде отдельного файла в .git/refs. Git накладывает строгие ограничения на набор символов для работы с любой файловой системой, но этого не всегда достаточно — если вы переходите на файловую систему, нечувствительную к регистру (например, APFS или NTFS), лучше надеяться, что репозиторий не содержит несколько ветвей или тегов, отличающихся только регистром. Аналогично, Git не запрещает использовать устаревшие имена устройств DOS, такие как auxили nulв качестве имен ветвей/тегов.
(Технически перемещение репозитория между разными файловыми системами может привести к потере некоторых метаданных файлов, таких как a-wсостояние «только для чтения» ( ) объектных объектов, но сам Git на это не обращает внимания.)
Если вы используете FAT32 только как временный транспорт, рассмотрите возможность использования git pack-refs --all --pruneи rm -rf .git/logsдля избежания проблем с именами ветвей, какими бы маловероятными они ни были. Также запустите git repack -d; git pruneдля уменьшения количества свободных объектных файлов.
Вы даже можете использовать его git bundleдля создания удобного для транспортировки BLOB-объекта, содержащего всю историю коммитов или ее часть.
решение2
Хотя копирование .gitкаталога в большинстве случаев сработает, есть некоторые предостережения, на которые следует обратить внимание:
git-svn может запомнить некоторую информацию о пользователе, которую вы не хотите копировать, например, имя и адрес электронной почты, в файле
.git/logs/refs/remotes/trunk.Клонированный репозиторий будет содержать ссылку на родительский объект, которую команда копирования не удалит. Вы можете удалить эту ссылку, используя
git remote remove origin.Если у вас есть символические ссылки в
.gitкаталоге, вам следует убедиться, что вы разыменовали их. Например:cp -r -L <source-repo-dir> <destination-repo-dir>Некоторые элементы конфигурации могут различаться на разных платформах, например, пользовательские драйверы различий и скрипты хуков, которые ссылаются на внешние программы. При копировании между разными платформами следует проверить такие элементы, как
core.ignorecase,core.autocrlf,core.safecrlf,core.fileModeи, возможно, некоторые другие.git-клон это безопасная операция, которая может выполняться между компьютерами:
git clone ssh://[email protected]/path/to/my-project.gitКлонирование автоматически создает удаленное соединение, называемое «origin», указывающее на исходный репозиторий, что упрощает взаимодействие с центральным репозиторием.
Вам может быть интересно прочитать следующее руководство по выборочному перемещению каталога git: