7.11 Інструменти Git - Підмодулі

Найпростіша модель використання підмодулів у проекті — просто користуватись підпроектом та отримувати оновлення з нього подеколи, проте не змінювати нічого у своїй копії. Розгляньмо тут простий приклад.

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

Тепер, якщо ви перейдете назад до головного проекту та виконаєте git diff --submodule, то побачите, що підмодуль було оновлено, та отримаєте список комітів, які були до нього додано. Якщо ви не бажаєте набирати --submodule щоразу при виконанні git diff, то можете встановити це типовим форматом, якщо встановите змінну конфігурації diff.submodule у значення “log”.

Якщо зараз зробити коміт, ви змусите підмодуль отримувати новий код, коли інші оновляться.

Також існує простіший метод це зробити, якщо вам не хочеться вручну отримувати та зливати зміни до піддиректорії. Якщо виконати git submodule update --remote, Git перейде до ваших підмодулів та отримає й оновить за вас.

Без додаткових налаштувань, ця команда вважає, що ви бажаєте оновити свою копію з гілки master репозиторія підмодуля. Однак, ви можете встановити якусь іншу, якщо бажаєте. Наприклад, якщо ви хочете, щоб підмодуль DbConnector слідкував за гілкою “stable” свого репозиторія, ви можете задати це або у файлі .gitmodules (щоб всі інші також слідкували за нею), або просто в локальному файлі .git/config. Установімо гілку у файлі .gitmodules:

Якщо пропустити -f .gitmodules, команда зробить зміни лише для вас, проте напевно більш розумно зберігати цю інформацію в репозиторії, щоб усі інші робили те саме.

Наразі при виконанні git status, Git покаже нам, що є нові коміти (“new commits”) у підмодулі.

Якщо ви встановите налаштування status.submodulesummary, Git також покаже вам короткий виклад змін у підмодулях:

Тепер, якщо виконати git diff, ми побачимо як наші зміни у файлі .gitmodules, як і декілька комітів, які ми отримали та готові зберегти до нашого проекту підмодуля.

Це дуже файно, адже ми можемо бачити журнал комітів, які збираємося зберегти в коміті в нашому підмодулі. Після збереження також можна побачити цю інформацію за допомогою git log -p.

Без додаткових опцій Git спробує оновити всі ваші підмодулі при виконанні git submodule update --remote, отже якщо у вас їх багато, то можливо варто передати імʼя саме того підмодуля, який ви бажаєте оновити.

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

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

Досі, коли ми виконували команду git submodule update щоб отримати зміни з репозиторіїв підмодулів, Git брав зміни та оновлював файли у піддиректоріях, проте залишав підрепозиторії у так званому стані “відокремлений HEAD” (detached HEAD). Це означає, що немає локальної гілки (як “master”, наприклад), яка слідкує за змінами. Без робочої гілки, що стежить за змінами, це означає, що навіть якщо ви збережете зміни в коміті підмодуля, ці зміни ймовірно будуть втрачені під час наступного виконання git submodule update. Вам доведеться виконати додаткові кроки, щоб за змінами в підмодулі стежили.

Щоб налаштувати підмодулі для легшої розробки, треба зробити дві речі. Вам треба перейти в кожен підмодуль та переключитись на гілку, над якою ви будете працювати. Потім треба сказати Git, що робити, якщо зроблено зміни, а git submodule update --remote отримує зміни з першоджерела. Є варіант зливати їх з вашою локальною роботою, або спробувати перебазувати вашу локальну роботу поверху нових змін.

Спершу, перейдімо до директорії нашого підмодуля та переключимось до гілки.

Спробуймо варіант “зливати”. Щоб задати його вручну, можна просто додати опцію --merge до виклику update. Тут ми побачимо, що була зміна на сервері цього підмодуля, і її злито.

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

Тепер, якщо ми оновимо наш підмодуль, то побачимо, що станеться, якщо ми зробили локальні зміни, а першоджерело також має зміни, які нам треба обʼєднати.

Якщо ви забули передати --rebase чи --merge, Git просто оновить підмодуль до того, що б там не було на сервері, та переведе ваш проект до стану відокремленого HEAD.

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

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

Якщо ви зробили зміни, що призвели до конфлікту з чимось з першоджерела, Git повідомить про це під час оновлення.

Тепер ви можете перейти до директорії підмодуля та виправити конфлікт, як і зазвичай.

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

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

Щоб переконатись, що такого не станеться, ви можете попросити Git перевірити, що всі підмодулі були відповідно надіслані перед надсиланням головного проекту. Команда git push приймає аргумент --recurse-submodules, який можна встановити або в “check” (перевірити) або в “on-demand” (за потребою). Опція “check” змусить push просто зупинитися з помилкою, якщо будь-які збережені в підмодулі зміни не були надіслані.

Як бачите, нам також надано корисні поради щодо того, що ми можемо зробити далі. Простий варіант — перейти до кожного підмодуля та вручну надіслати до віддалених сховищ, щоб переконатись, що вони доступні ззовні, та потім знову спробувати надіслати. Якщо ви хочете, щоб усі операції push відбувалися з поведінкою check, її можна зробити типовою за допомогою git config push.recurseSubmodules check.

Інший варіант — використати значення “on-demand”, що спробує зробити те саме за вас.

Як тут можна побачити, Git перейшов до підмодуля DbConnector та надіслав його перед тим, як надсилати головний проект. Якщо надіслати підмодуль чомусь не вдасться, надсилання головного проекту теж не вдасться. Цю поведінку можна зробити типовою за допомогою git config push.recurseSubmodules on-demand.

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

Якщо один з комітів є прямим предком іншого (зливання перемотуванням), то Git просто вибере останній для зливання, отже це спрацює без проблем.

Однак, Git не спробує зробити навіть простого зливання. Якщо підмодульні коміти розійшлися та їх необхідно зливати, ви отримаєте щось таке:

Отже, по суті, сталося наступне: Git зрозумів, що дві записані точки гілок в історії підмодуля, що розійшлися, мають бути злиті. Це видно з “merge following commits not found” (злиття після комітів не знайдено), що важко зрозуміти, проте ми невдовзі все пояснимо.

Щоб вирішити проблему, вам треба зрозуміти, у якому стані мають бути підмодулі. Git дає на диво мало інформації, щоб вам допомогти: навіть не показує SHA-1 комітів з обох сторін історії. На щастя, зрозуміти це не складно. Якщо виконати git diff, то можна отримати SHA-1 комітів, записаних в обох гілках, які ви намагалися злити.

Отже, в даному випадку, eb41d76 — це коміт у нашому підмодулі, який ми мали, а c771610 — коміт, який був у першоджерелі. Якщо перейти до директорії підмодуля, вона вже має бути на eb41d76, оскільки зливання її не мало чіпати. Якщо з якоїсь причини це не так, ви можете просто створити та перейти до гілки, що вказує на нього.

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

Отже, тепер ми перейдемо до директорії підмодуля, створимо гілку на базі другого SHA-1 з git diff та вручну зіллємо.

Тепер ми отримали власне коміт, отже якщо його розвʼязати та зберегти у коміті, потім можна просто оновити головний проект результатом.

Це може бути трохи заплутано, проте насправді не таке вже й складне.

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

Ось чому повідомлення помилки раніше було “merge following commits not found”, адже він не зміг цього зробити. Це збиває з пантелику, оскільки хто б очікував, що Git намагається це зробити?

Якщо він знайде єдиний прийнятний коміт злиття, ви побачите щось схоже на:

Вам тут пропонується оновити індекс, нібито ви були виконали git add, що очистить конфлікт, а потім зробити коміт. Однак, вам, напевно, не варто цього робити. Ви можете так само легко перейти до директорії підмодуля, побачити, в чому різниця, перемотати до цього коміту, належним чином його перевірити, а потім зберігати це в коміті.

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

Є команда foreach (для кожного), що дозволяє виконати довільну команду в кожному підмодулі. Це може бути дійсно корисним, якщо у вас багато підмодулів в одному проекті.

Наприклад, скажімо, ви бажаєте розпочати працювати над новим функціоналом чи виправленням, а у нас не закінчена робота над декількома підмодулями. Ми можемо легко сховати всю роботу в усіх підмодулях.

Потім ми можемо створити нову гілку та перейти до неї в усіх підмодулях.

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

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

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

Таким чином, можна просто виконати git supdate, коли вам треба оновити підмодулі, або git spush, щоб надіслати зміни з перевіркою залежних підмодулів.