Безопасно ли сжимать архив GIT в случае потери данных или повреждения архива?
Я использую GIT GUI, чтобы отслеживать изменения, вносимые в наши ежедневные задачи разработки и изменения кода / файлов.
В настоящее время я занимаюсь веб-разработкой, в первую очередь веб-сайтами. Я использую архив GIT для каждой папки сайта, которая содержит все файлы и документы, связанные с проектом.
Часто GIT жалуется на то, что в архиве много элементов, и чтобы сохранить архив быстрым и оптимизированным, он предлагает мне сжать архив.
Насколько это безопасно? Превзойдут ли преимущества сжатия архива возможные проблемы, которые может вызвать сжатие (стоит ли оно того)?
Я особенно обеспокоен потенциальным повреждением архива или известными проблемами / ошибками, о которых я могу не знать.
3 ответа
Формат репозитория Git надежен и очень хорошо протестирован. Безопасно делать сжатие репозитория.
Сказав это, резервные копии всегда хорошая идея.
Если вы говорите о git gc тогда это совершенно безопасно, и никакие данные не потеряны.
Git периодически выполняет это сам, но ничего не делает, пока репо не превзойдет определенный размер.
Как говорит Грег, всегда делайте резервную копию вашего репо.
git gc --prune - это другое дело. Это приведет к удалению всех объектов, на которые нет ссылок, из репозитория, что может оказаться не тем, что вам нужно (вы можете захотеть восстановить один из них позже).
TL;DR: Да, безопасно выполнять оптимизацию git-репозитория, но делайте резервные копии и тестируйте их.
Я предполагаю, что под "сжатием" вы подразумеваете git gc,
Операция настолько безопасна, насколько это возможно для окружающей среды (стабильность машины, оперативная память и надежность хранения).
Тем не менее, у всех вычислительных машин есть один недостаток: место для хранения. Быть в курсе, что git gc иногда (как это ни парадоксально) может временно увеличить размер хранилища (из-за распаковки объектов, которые могут быть удалены, но еще не удалены). Если на машине недостаточно места для хранения, это может помешать успешному выполнению операции или затруднить последовательную работу. Также, git gc может потребовать огромное количество памяти (например, больше, чем размер хранилища на диске) и завершится неудачно, если система не справится.
Тем не менее, я никогда не видел коррупцию в хранилище, казалось бы, вызванную git gc,
Если ваша резервная копия является репозиторием клонов, будьте осторожны: некоторые элементы (ветви, легкие теги, обычные теги, конфигурации, хуки и т. Д.) Не переносятся автоматически между репозиториями, некоторые частично или в некоторых случаях только со сложными правилами.
Поскольку вы беспокоитесь о безопасности данных, лучший способ быть безопасным (и это вообще не относится к git) - это регулярно выполнять резервное копирование + восстановление после сбоя. Затем время от времени создавайте изолированную тестовую среду восстановления (она может быть простой, например, папка на другом компьютере или виртуальная машина, в зависимости от контекста). Затем в этой среде полностью запустите процедуру восстановления и убедитесь, что ваши ценные данные и процессы снова становятся полностью функциональными из резервной копии, не требуя вашего основного хранилища. Таким образом, вы знаете, что в случае сбоя основного хранилища вы все еще в безопасности.