SVN: еквівалент зовнішніх даних у Git?

У мене є два SVN-проекти, які використовуються з іншого сховища SVN, використовуючи svn: externals .

Як я можу мати однакову структуру макета сховища в Git?

У Git є два підходи, схожі на svn: externals:

• Злиття піддерева вставляють код зовнішнього проекту в окремий підкаталог у межах вашого репо. Це має детальний процес налаштування, а потім дуже просто для інших користувачів, оскільки він автоматично включається під час перевірки або клонування сховища. Це може бути зручним способом включити залежність у свій проект.
  Легко витягнути зміни з іншого проекту, але складно подати зміни назад. І якщо інший проект повинен злитися з вашим кодом, історія проекту об’єднується, і два проекти фактично стають одним.

• Підмодулі Git ( посібник ) посилаються на певний комітет у сховищі іншого проекту, подібно до svn: externals з-rаргументом. Підмодулі легко налаштувати, але всі користувачі повинні керувати підмодулями, які не включаються автоматично в каси (або клони).
  Хоча повернення змін в інший проект легко, але це може спричинити проблеми, якщо репортаж змінився. Тому взагалі не годиться повертати зміни до проекту, який активно перебуває в стадії розробки.

Як я вже згадував у " Оновлення нової версії підмодуля Git ", ви можете досягти тієї ж зовнішньої функції SVN з підмодулями Git 1.8.2:

git config -f .gitmodules submodule.<path>.branch <branch>

Цього цілком достатньо, щоб підмодуль слідував за гілкою (як у ПОСЛІДНІЙ комісії віддаленої гілки підмодуля верхнього репо-репо ). Все, що вам потрібно зробити, це:

git submodule update --remote

Це оновить підмодуль.

Більш детальна інформація знаходиться у " git submoduleвідстеженні останніх "

Щоб перетворити існуючий підмодуль в одну відстежуючу гілку : перегляньте всі кроки в " Підмодулі Git: Вкажіть гілку / тег ".

Я автор інструменту gil (git link)

У мене є альтернативне рішення проблеми - інструмент gil (git links)

Це дозволяє описувати та керувати складними залежностями git-сховищ.

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

Розглянемо, що у вас є такі проектні залежності: зразок графіка залежності репозиторію git

Тоді ви можете визначити .gitlinksфайл із описом відношення репозиторіїв:

# Projects
CppBenchmark CppBenchmark https://github.com/chronoxor/CppBenchmark.git master
CppCommon CppCommon https://github.com/chronoxor/CppCommon.git master
CppLogging CppLogging https://github.com/chronoxor/CppLogging.git master

# Modules
Catch2 modules/Catch2 https://github.com/catchorg/Catch2.git master
cpp-optparse modules/cpp-optparse https://github.com/weisslj/cpp-optparse.git master
fmt modules/fmt https://github.com/fmtlib/fmt.git master
HdrHistogram modules/HdrHistogram https://github.com/HdrHistogram/HdrHistogram_c.git master
zlib modules/zlib https://github.com/madler/zlib.git master

# Scripts
build scripts/build https://github.com/chronoxor/CppBuildScripts.git master
cmake scripts/cmake https://github.com/chronoxor/CppCMakeScripts.git master

Кожен рядок описує посилання git у такому форматі:

1. Унікальна назва сховища
2. Відносний шлях сховища (починається з шляху файлу .gitlinks)
3. Репозиторій Git, який буде використовуватися в команді git clone відділення репозиторію для оформлення замовлення
4. Порожній рядок або рядок, розпочатий з #, не розбираються (трактуються як коментар).

Нарешті, вам потрібно оновити сховище кореневого зразка:

# Clone and link all git links dependencies from .gitlinks file
gil clone
gil link

# The same result with a single command
gil update

В результаті ви будете клонувати всі необхідні проекти та зв’язувати їх один з одним належним чином.

Якщо ви хочете здійснити всі зміни в деякому сховищі зі всіма змінами в сховищах, пов’язаних з дочірніми, ви можете зробити це за допомогою однієї команди:

gil commit -a -m "Some big update"

Команди "pull", "push" працює аналогічно:

gil pull
gil push

Інструмент Gil (git-посилання) підтримує такі команди:

usage: gil command arguments
Supported commands:
    help - show this help
    context - command will show the current git link context of the current directory
    clone - clone all repositories that are missed in the current context
    link - link all repositories that are missed in the current context
    update - clone and link in a single operation
    pull - pull all repositories in the current directory
    push - push all repositories in the current directory
    commit - commit all repositories in the current directory

Детальніше про проблему залежності рекурсивних субмодулів git .