Підмодуль Git проти клона Git

Я працюю над проектом з відкритим кодом на GitHub.

У ньому є підкаталог / Vendor, в якому він має копію декількох зовнішніх бібліотек. Оригінальний керівник проекту раз у раз оновлював цей каталог новою копією зовнішньої бібліотеки.

Один розробник надіслав мені запит на тягу з ідеєю замінити цю копію на підмодуль git .

І я розглядаю, чи це гарна ідея чи ні.

Плюс підмодуль Git:

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

Мінуси Git:

• Схоже, що підмодулі git підштовхують складність від підтримуючого до людини, яка буде клонувати / витягувати проект (необхідні додаткові кроки після клонування, щоб почати працювати над проектом: "git submodule init", "git update submodule"

Яка ваша думка з цього приводу?

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

Альтернативою підмодулю є використання git subtree. Це дає переваги, git submoduleале не покладаючи складності на кінцевого споживача. Третій сховище об'єднується в основне дерево проекту, але метадані зберігаються таким чином, що ви можете:

• витягніть сторонне сховище пізніше, якщо були внесені якісь цікаві зміни
• об'єднати нові оновлення із стороннього сховища (зверніть увагу на об'єднання , не замінювати)

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

Підрядки дозволяють включити підпроекти до підкаталогу основного проекту, необов'язково включаючи всю історію підпроекту.

Наприклад, ви можете включити вихідний код для бібліотеки як підкаталог вашої програми.

Підрядки не слід плутати з підмодулями, які призначені для одного завдання. На відміну від підмодулів, subtrees не потребують спеціальних конструкцій (наприклад, файлів .gitmodule або gitlinks), які містяться у вашому сховищі, і не змушуйте кінцевих користувачів вашого сховища робити щось особливе або розуміти, як працюють підтрубки. Піддерево - це лише підкаталог, який можна виконувати, розгалужувати та об'єднувати разом із вашим проектом будь-яким способом.

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

Зауважте, що git-subtree є частиною git/contribкаталогу, і його потрібно встановлювати окремо.

Одним недоліком використання підмодулів є те, що тарболи або zip-архіви на Github (та багатьох інших службах) не включають джерела підмодулів. Тобто архіви не є самостійними. Це викликає проблему, якщо сховище невелике і не має насправді сценарію збірки, як статичний HTML-сайт залежно від бібліотеки JavaScript.

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

Їм не важко розібратися, як їх використовувати, і вони досить часто використовуються в цій ситуації, тому просто зауважте у проекті README, що ви використовуєте підмодулі та що робити, і люди повинні вміти рахувати це виходить. Перший раз, коли я зіткнувся з сховищем з підмодулем, я його запустив і запустив за 10 - 15 хвилин, і ніколи не виникав проблем із з'ясуванням, що робити з того часу.

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

Коротше кажучи - ви хочете просто використовувати лібси чи вважаєте їх частиною вашої кодової бази? Якщо вони не "ваш" код, чому вони знаходяться в контролі версій, а не просто те, що потрібно встановити?