Чому git використовує хеші замість ревізійних номерів?

Мені завжди було цікаво, чому git надає перевагу хешам над ревізійними номерами. Номери редакції набагато зрозуміліші та простіші для посилання (на мій погляд): Є різниця між тим, щоб сказати комусь подивитися на редакцію 1200 або здійснити 92ba93e! (Просто навести один приклад).

Отже, чи є причина такої конструкції?

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

Вам потрібні хеші в розподіленій системі. Скажімо, ви і колега працюєте над тим самим сховищем, і ви обидва здійснюєте зміну локально, а потім натискаєте на неї. Хто може бути ревізійним номером 1200, а хто ревізійним номером 1201, якщо жодна із сторін не знає один про одного? Єдине реалістичне технічне рішення - створити хеш змін за допомогою відомого методу та зв’язати речі на основі цього.

Цікаво, що HG підтримує номери версій, але вони явно є лише локальною функцією - у вашому сховищі є один набір, репо-служба вашого колеги матиме інший набір залежно від того, як вони натиснули та витягли. Це робить використання командного рядка трохи привітнішим, ніж Git.

Цілісність даних.

Я з повагою не згоден з нинішніми відповідями. Хеші не потрібні для DVCS, див. Базарний шлях . Ви можете добре вчинити з будь-яким іншим глобальним унікальним ідентифікатором. Хеші - це міра гарантувати цілісність даних: вони являють собою дайджест інформації, що міститься в об'єкті (фіксація, дерева, ...), на який посилається хеш. Змінення вмісту, не змінюючи хеш (тобто атака перед зображеннями або атака зіткнення ), вважається, є важкою, хоча і неможливою. (Якщо ви насправді задумаєтесь, подивіться на статтю Марка Стівенса 2011 року ).

Отже, посилання на об'єкти за допомогою їх хеша SHA дозволяє перевірити, чи був вміст підроблений. І, враховуючи, що вони (майже) гарантовано є унікальними, їх також можна використовувати як ідентифікатори редагування - зручно.

Докладніше див. У Розділі 9 книги Git.

Словами мирянина:

• Хеші мають бути майже універсальними. Це НЕ гарантується, але вкрай малоймовірно, що ті самі SHA створюються для різного вмісту. На практиці для даного проекту ви можете трактувати його як унікальний.
• Для номерів редакції вам доведеться використовувати простір імен, щоб спеціально перейти до версії 1200.
• Git може працювати як розподіленим, так і / або централізованим. Тож як ви можете зробити номери ревізії правильними та унікальними?
• Також використання ревізійних номерів створило б помилкову думку про те, що новіші версії повинні мати більш високі цифри, і це було б неправдою через розгалуження, злиття, повторне використання тощо.
• Ви завжди можете розмістити теги до комітетів.

Математично:

• Для монотонного збільшення номерів версій потрібно буде повне замовлення на комісії Git.
• Коміти Гіта утворюють спрямований, ациклічний графік (DAG), який можна упорядкувати лише частково / топологічно .

Хеш - це не унікальне рішення для розподілених VCS. Але якщо мати справу з розподіленою системою, можна записувати лише часткове впорядкування подій. (Для VCS подія може бути скоєною.) Тому підтримувати монотонно зростаючий номер перегляду неможливо. Зазвичай ми приймаємо щось на зразок векторного годинника (або векторної часової позначки) для запису такого часткового впорядкованого відношення. Це рішення, яке використовується на базарі .

Але чому Git не використовує векторний годинник, а хеш? Я думаю, що першопричиною є вишня . Коли ми виконуємо вишню в сховищі, часткове впорядкування комітетів змінюється. Для відображення нового часткового впорядкування для деяких годин векторні годинники повинні бути перепризначені. Однак таке перепризначення в розподіленій системі може викликати непослідовні векторні годинники. Це справжня проблема, з якою вирішується хеш.