Git Subtree у деталях

Стаття також доступна російською (перейти до перегляду).

Вступ

• Можливості Git-системи по управлінню окремими підпроектами
• Спрощене керування піддеревами проекту

Розгалужена розробка веб-додатків під управлінням Git, зазвичай, призводить до необхідності мати складну структуру дерева розробки, окремі гілки якого підпорядковуються гілкам більш високого рівня. На практиці це означає наявність окремих підпроектів у межах одного суперпроекту, розміщених у вкладених підкаталогах локальних репозиторіїв. Така структура ускладнює процес синхронізації внесених змін та вимагає використання різних стратегій, щоб унеможливити появу конфліктів, зокрема, при злитті гілок дерева розробки. Однією з таких стратегій є засіб управління піддеревами git subtree, котрий дозволяє частково автоматизувати обмін даними у межах суперпроекту та організувати повноцінну роботу із необмеженою кількістю підпроектів. Розглянемо більш детально вказаний механізм та продемонструємо роботу з ним на практиці.

Можливості Git-системи по управлінню окремими підпроектами

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

Git надає наступні рекомендації та інструменти для успішного здійснення операцій по управлінню гілками дерева розробки:

• Необхідно періодично фіксувати внесені зміни у робочому каталозі за допомогою коммітів;
• Перед виконанням операції злиття бажано зберегти внесені у локальний підпроект зміни у тимчасовій гілці, щоб, у випадку здійснення невдалої операції оновлення чи злиття дозволить зберегти дані;
• Періодично здійснювати операції злиття для швидко зростаючих гілок;
• При виникненні сумнівів, щодо коректності операції злиття, завжди можна її відмінити за допомогою команди git merge --abort;
• Слід використовувати можливості управління процесом злиття гілок дерева за допомогою аргументів командної строки, наприклад, це стосується налаштувань ігнорування змін порожніх символів із використанням опції -Xignore-all-space;
• У окремих складних випадках можна застосовувати, так зване, ручне злиття, наприклад, з використанням програми dos2unix для попереднього прогону файлу через «фільтр»;
• Для виявлення причин виникнення конфліктів завжди можна скористатися командою git checkout з опцією –conflict, котра надасть додаткову інформацію для з'ясування причин появи конфліктів;
• Для виявлення причин виникнення конфліктів можна також використовувати логи за допомогою команди git log;
• Виконувати постаналіз даних одразу ж після виникнення конфлікту за допомогою команди git diff, що дасть змогу побачити об'єкти, що конфліктують.

Можна виділити три основні стратегії або механізми Git по управлінню піддеревами одного суперпроекту:

• Механізм підмодулів (команда git submodule);
• Класичний механізм злиття гілок (команда git merge);
• Засіб спрощеного керування процесом (команда git subtree).

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

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

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

Засіб спрощеного керування процесом найкраще підходить для організації роботи нескладних проектів Адміністраторами з невеликим досвідом роботи. Саме для таких випадків він є найбільш прийнятним. Він може знадобитися при використанні бібліотек функцій у якості самостійних підпроектів.

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

Спрощене керування піддеревами проекту

Розглянемо застосування спрощеного механізму керування підпроектами за допомогою git subtree. Виділимо основні його переваги над іншими стратегіями управління:

• Простота освоєння та застосування;
• Підтримка попередніх версій програми;
• Відсутність додаткових файлів метаданих;
• Код підпроекту доступний одразу ж після клонування головного проекту;
• Вміст каталогу може бути змінений без необхідності копіювання програмної залежності у окремий репозиторій.

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

• Створення та активація локального Git-репозииторію із ім'ям reposit_lesson;
• Створення у межах репозиторію підпроекту, котрий буде містити дані віддаленого публічного репозиторію;
• Забезпечення поновлення даних підпроекту.

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

$ mkdir reposit_lesson
$ cd reposit_lesson

Ініціюємо порожній репозиторій:

$ git init

Ініціалізація пройшла успішно – «Initialized empty Git repository in /root/reposit_lesson/.git/».

З метою внесення змін, створимо файл із ім'ям .testfile:

$ touch .testfile

Додамо створений файл до індексу Git:

$ git add .testfile

Зафіксуємо внесені у репозиторій зміни за допомогою виконаного комміту:

$ git commit -m "Initial commit lesson repository"

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

$ git subtree add --prefix js_node https://github.com/nodejs/node.git  main

git fetch https://github.com/nodejs/node.git main
warning: no common commits
remote: Enumerating objects: 642893, done.
remote: Counting objects: 100% (124/124), done.
remote: Compressing objects: 100% (108/108), done.
remote: Total 642893 (delta 67), reused 45 (delta 16), pack-reused 642769
Receiving objects: 100% (642893/642893), 905.01 MiB | 11.01 MiB/s, done.
Resolving deltas: 100% (469670/469670), done.
From https://github.com/nodejs/node
 * branch        	main   	-> FETCH_HEAD
Added dir 'js_node'

Для періодичного оновлення коду підпроекту даними із віддаленої первісної гілки можна користуватися наступною командою:

$ git subtree pull --prefix js_node https://github.com/nodejs/node.git main

Для більш складних випадків краще використовувати можливості віддаленого відслідковування внесених змін. У такому разі, нам необхідно додати підпроект у якості віддаленого підключення. Каталог із даними, що оновлюються із віддаленого репозиторію буде мати ім'я node_remote. Введемо у терміналі:

$ git remote add -f node_remote https://github.com/nodejs/node.git

Після успішного створення підключення, знову введемо команду створення підпроекту, як і у випадку без відслідковування. Тільки тепер в ній замість посилання на віддалений репозиторій буде стояти ім'я node_remote. Для цього введемо у командній строчці:

$ git subtree add --prefix js_node node_remote main

Як бачимо, на виході команди з'явилося повідомлення про те, що каталог js_node вже існує. І це зрозуміло, оскільки введена команда, по суті, дублює ту, що була введена раніше, але має скорочену форму.

Введемо команду для отримання останньої версії підпроекту із первісної віддаленої гілки:

$ git fetch node_remote main

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

Пулінг даних підпроекту тепер можна здійснювати за допомогою наступної конструкції:

$ git subtree pull --prefix js_node node_remote main

Команда врахувала те, що нових змін не було внесено після здійснення нами останнього оновлення, повідомивши на виході: «Already up to date».

Доречі, якщо Вам потрібен потужний інструмент для віддаленої взаємодії команди, можемо запропонувати для Вас віртуальний сервер з GitLab. GitLab включає в себе Git, інструменти CI/CD, online редактор коду, Wiki та багато інших можливостей. Сервер автоматично налаштовується одразу після оплати замовлення, за 2-3 хвилини Ви вже можете почати з ним працювати. Додатковою перевагою є автоматичне щоденне створення бекапів.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

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