Наскільки надійні вчинки Git, коли потужність гасне?

Одного разу я користувався Git (я все ще використовую його), і електроенергія знизилася, коли я робив зобов’язання.

Коли я (власне, електрика) повернувся, git repo зіпсувався. Я не пам'ятаю точної назви, але це було щось на кшталт "недійсні рефлекси" чи щось подібне.

Неважко здогадатися, що фіксація була порушена в середині операції (я робив фіксацію через IntelliJ, який робить додавання індексу автоматично). Неважко було здогадатися, що насправді "фіксувати" - це не такий ACID, як операція СУБД з такою ж назвою.

Питання : Чи є спосіб переконати, що операції по переробці по відношенню до атомності? тобто, якщо електроенергія знову знизиться, і я виконую обов'язки, я хотів би, щоб моя файлова система не була в корумпованому стані.

Я не знаю, чи є спосіб, щоб змусити Git переживати ідеально відключені електроенергії, але ви, можливо, зможете виправити своє сховище.

Об'єкти Git повинні бути незмінними, тому всі ваші старі зобов’язання повинні бути дійсними. Відповідно до цієї відповіді , ви можете змінити хеш, .git/refs/heads/<branch-name>щоб змінити керівника відділення, над яким ви працювали, на попередній комітет (ви можете побачити їх у .git/logs/HEAD).

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

Система зберігання Git не є транзакційною, тому, безумовно, є ймовірність, що проблема з обладнанням може залишити речі в непослідовному стані. З іншого боку, Git також дуже швидкий, тому вам доведеться по-справжньому не пощастити, щоб потрапити на проблеми типу «відключення живлення» (систематичні проблеми з диском - це щось інше). Швидкість частково пояснюється тим, що вона не є транзакційною; транзакції дійсно досить дорогі, оскільки їм доведеться чекати підтвердження з диска, що він записав дані. (Бази даних роблять всілякі речі, щоб спробувати приховати цю вартість, але в кінцевому підсумку вони все одно платять ціну. Деякі з конкурентів DVCS є транзакційними, і так, вони досить повільніші на тому ж апаратному забезпеченні, що і git.)

У гіршому випадку - загальний катастрофічний збій диска (який я бачив) - єдиним способом відновлення DVCS є використання факту його розподілу. Якщо ви донедавна перенесли свої зміни до іншої системи, і вони поділилися ними з багатьма різними хостами, відновлення - це лише питання використання одного з цих інших місць як джерела артефакту, місця для витягування ваших гілок ( навіть якщо просто тимчасово). Так, ви потягнете історію цікавих гілок назад, і ви зможете знову працювати знову; все, що видаляє відразу багато розповсюджених копій репо, є або катастрофою, коли ви не турбуєтесь про програмування згодом (подумайте про великий вплив метеориту), або це відверта дія противника. (Намагайтеся не створювати таких ворогів ...) Це в цілому на відміну від нерозподілених систем, де втрата центрального сервера, на якому розміщено все, є смертельним ударом.