Насколько устойчивы коммиты Git при отключении питания?

Однажды я использовал Git (я все еще использую его), и электричество отключилось, когда я делал коммит.

Когда я (на самом деле, электричество) вернулся, репозиторий был испорчен. Я не помню точное имя, но это было что-то вроде «недействительные ссылки» или что-то в этом роде.

Легко догадаться, что фиксация была нарушена в середине операции (я делал коммит через IntelliJ, который выполняет автоматическое добавление индекса). Также было легко догадаться, что на самом деле 'commit' не такой ACID, как операция с СУБД с тем же именем.

Q : Есть ли способ гарантировать, что операции репо изменяют атомарность? то есть, если электричество снова отключается, и я фиксирую, я бы хотел, чтобы моя файловая система не была в поврежденном состоянии.

Я не знаю, есть ли способ заставить коммиты Git пережить точно рассчитанные сбои питания, но вы можете исправить свой репозиторий.

Предполагается, что объекты Git являются неизменяемыми, поэтому все ваши старые коммиты должны быть действительными. В соответствии с этим ответом вы можете изменить хэш, .git/refs/heads/<branch-name>чтобы изменить заголовок ветви, над которой вы работали, на предыдущий коммит (вы можете увидеть их в .git/logs/HEAD).

В комментарии к этому ответу говорится, что этот метод «по-прежнему оставляет хранилище в поврежденном состоянии, но это позволяет восстановить его». Я не проверял это (не знаю, как повторить вашу ситуацию), но я предполагаю, что восстановление выполняется с помощью git gc, который удалит поврежденный коммит.

Система хранения Git не является транзакционной, поэтому существует определенная вероятность того, что аппаратная проблема может привести к несогласованности. С другой стороны, Git также очень быстр, поэтому вам, возможно, не повезет, если вы столкнетесь с проблемами типа «сбой питания» (систематические проблемы с диском - это что-то еще). Скорость отчасти объясняется тем, что она не транзакционная; транзакции действительно довольно дороги, так как им приходится ждать подтверждения с диска, на который они записали данные. (Базы данных делают все возможное, чтобы скрыть эту стоимость, но в конечном итоге они все равно платят. Некоторые из конкурирующих DVCS являются транзакционными, и да, они работают немного медленнее на том же оборудовании, что и git.)

В худшем случае - полный катастрофический сбой диска (который, как я видел), - единственный способ восстановления DVCS - использовать тот факт, что он распространяется, Если вы до недавнего времени перенесли свои изменения в другую систему, и они предоставили их множеству разных хостов, восстановление - это просто вопрос использования одного из этих других мест в качестве источника артефакта, места, из которого можно извлечь свои ветви ( даже если только временно). Таким образом, вы вернете историю интересных веток и сможете снова быстро начать работать; все, что уничтожает множество распределенных копий вашего репо, является либо катастрофой, когда вы не беспокоитесь о программировании впоследствии (подумайте о серьезном воздействии метеорита), либо прямым действием противника. (Постарайтесь не создавать таких врагов…) Это полностью контрастирует с нераспределенными системами, где потеря центрального сервера, на котором размещено все, является смертельным ударом.