7.13 Інструменти Git - Заміна

Як ми вже наголошували, обʼєкти в базі даних Git незмінні, проте Git надає цікавий засіб вдавати заміну обʼєктів своєї бази на інші.

Команда replace дозволяє задати обʼєкт у Git та сказати "щоразу як ти звертаєшся до цього обʼєкту, вдай нібито це _інший обʼєкт". Це найбільш корисно для заміни одного коміту вашої історії на інший без потреби переписувати всю історію за допомогою, наприклад, git filter-branch.

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

Спробуймо це. Візьмімо існуючий репозиторій, розділимо його на два, один новітній, інший історичний, та потім побачимо, як можна воззʼєднати їх без редагування значень SHA-1 новітнього репозиторія за допомогою replace.

Ми використаємо простий репозиторій з пʼятьма простими комітами:

Ми бажаємо розбити це на дві лінії історії. Одна буде з першого до четвертого коміту - це буде історичною. Друга лінія буде містити лише четвертий та пʼятий коміти - це буде новітня історія.

Ну, створити давню історію просто: треба лише покласти гілку в історію, а потім надіслати цю гілку до гілки master нового віддаленого репозиторія.

Тепер ми можемо надіслати нову гілку history до гілки master нового репозиторія:

Добре, отже наша історія опублікована. Тепер складніше завдання — зрізати нашу новітню історію, щоб зменшити її. Нам потрібне перекривання, щоб ми могли замінити коміт одного репозиторія еквівалентним комітом з іншого, отже ми збираємося зрізати до четвертого та пʼятого комітів (і четвертий коміт перекривається).

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

Щоб це зробити, нам треба вибрати точку розриву, у даному випадку це третій коміт, тобто 9c68fdc словами SHA. Отже, наш базовий коміт буде засновано на цьому дереві. Ми можемо створити наш базовий коміт за допомогою команди commit-tree, яка просто бере дерево та поверне нам SHA-1 новісінького коміту без батьків.

Добре, отже тепер, коли в нас є базовий коміт, ми можемо перебазувати решту нашої історії поверх нього за допомогою git rebase --onto. Параметр --onto треба встановити у SHA-1 суму, щойно отриману від commit-tree, а місцем перебазування буде третій коміт (батько першого коміту, який треба зберегти, 9c68fdc):

Добре, отже тепер ми переписали нашу новітню історію поверх технічного базового коміту, який тепер містить інструкції щодо відновлення повної історії, якщо комусь треба. Тепер ми можемо надіслати цю історію до нового проекту, та тепер при клонуванні цього репозиторія, вони побачать лише останні два коміти, а потім базовий коміт з інструкціями.

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

Тепер співробітники матимуть нові коміти в гілці master, а історичні коміти у гілці project-history/master.

Щоб їх обʼєднати, можна просто викликати git replace з комітом, який ви хочете замінити, та комітом, яким ви бажаєте його замінити. Отже, ми хочемо замінити "четвертий" коміт з гілки master "четвертим" комітом з гілки project-history/master:

Тепер, якщо подивитись на історію гілки master, виявляється, вона матиме такий вигляд:

Вражає, еге ж? Без необхідності змінювати всі SHA-1 суми першоджерела, ми впорались замінити один коміт історії геть іншим, і всі звичайні інструменти (bisect, blame тощо) працюватимуть, як ми й очікуємо.

Що цікаво, тут досі зазначено 81a708d як SHA-1, хоч насправді використовуються дані коміту c6e1e95, яким ми його замінили. Навіть якщо виконати таку команду, як cat-file, вона все одно покаже замінені дані:

Памʼятайте, що справжній батько коміту 81a708d був наш коміт-заповнювач (622e88e), а не 9c68fdce, як тут зазначено.

Ще одна цікава річ: відомості про це зберігаються в посиланнях:

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