git-subtree - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

git-subtree - об'єднати піддерева разом і розділити сховище на піддерева

СИНТАКСИС

мерзотник піддерево додати -П
мерзотник піддерево додати -П
мерзотник піддерево тягнути -П
мерзотник піддерево натиснути -П
мерзотник піддерево злиття -П
мерзотник піддерево розкол -П [ВАРИАНТИ] [ ]

ОПИС

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

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

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

Їх також не слід плутати із використанням стратегії злиття піддерева. Головний
Різниця полягає в тому, що, крім об’єднання іншого проекту як підкаталогу, ви також можете
витягніть всю історію підкаталогу з вашого проекту та перетворите його на a
окремий проект. На відміну від стратегії злиття піддерева, ви можете чергувати туди-сюди
між цими двома операціями. Якщо автономна бібліотека оновиться, ви можете
автоматично об’єднати зміни у свій проект; якщо ви оновлюєте бібліотеку всередині свого
проекту, ви можете знову «розділити» зміни та об’єднати їх у бібліотеку
Проект.

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

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

КОМАНДИ

додавати
Створіть піддерева, імпортуючи його вміст із заданого або
і дистанційно . Новий коміт створюється автоматично, приєднуючись до
імпортована історія проекту зі своєю власною. З -- сквош, імпортує лише одну фіксацію
від підпроекту, а не всієї його історії.

злиття
Об’єднати останні зміни до в піддерево. Як і зі звичайним мерзотник
злиття, це не видаляє ваші власні локальні зміни; він просто об’єднує ці зміни в
останній . З -- сквош, створює лише один коміт, який містить усі
змін, а не злиття в усій історії.

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

тягнути
Точно так само злиття, але паралелі мерзотник тягнути в тому, що він отримує задане посилання з
зазначений віддалений репозиторій.

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

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

Після успішного розбиття єдиний ідентифікатор коміту друкується в стандартний виведення. Це
відповідає ГОЛОВІ новоствореного дерева, яким ви можете маніпулювати
Ви хочете.

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

Зверніть увагу, що якщо ви використовуєте -- сквош коли ви об’єднуєтеся, зазвичай не просто -- знову приєднатися
коли ти розлучишся.

ВАРІАНТИ

-q, -- тихо
Придушити непотрібні вихідні повідомлення на stderr.

-d, --налагодження
Створюйте ще більше непотрібних вихідних повідомлень на stderr.

-П , --prefix=
Вкажіть шлях у сховищі до піддерева, яким ви хочете маніпулювати. Цей варіант
є обов'язковим для всіх команд.

-м , --message=
Ця опція дійсна лише для додавання, злиття та витягування (не впевнений). Вкажіть як
повідомлення фіксації для коміту злиття.

ВАРІАНТИ ДЛЯ ДОДАТИ, ЗЛИТИ, PUSH, ЗВИЙТИ

-- сквош
Цей параметр дійсний лише для команд додавання, об’єднання та витягування.

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

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

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

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

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

ВАРІАНТИ ДЛЯ SPLIT

--annotate=
Цей параметр дійсний лише для команди split.

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

Щоразу, коли ви розділяєте, вам потрібно використовувати те саме , інакше у вас немає a
гарантувати, що нова відтворена історія буде ідентичною старій. Що буде
перешкоджати коректній роботі злиття. git subtree все одно намагається змусити його працювати,
особливо якщо ви використовуєте --rejoin, але це не завжди може бути ефективним.

-б , --branch=
Цей параметр дійсний лише для команди split.

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

--ігнорувати-приєднується
Цей параметр дійсний лише для команди split.

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

--onto=
Цей параметр дійсний лише для команди split.

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

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

-- знову приєднатися
Цей параметр дійсний лише для команди split.

Після розділення об’єднайте щойно створену синтетичну історію назад у свою основну
проект. Таким чином, майбутні розколи можуть шукати лише ту частину історії, яка була
додано після останнього --rejoin.

Якщо ваші split коміти в кінцевому підсумку об’єднані з підпроектом вище по потоку, і тоді ви хочете
отримати останню вихідну версію, це дозволить алгоритму git об’єднати більше
розумно уникати конфліктів (оскільки він знає, що ці синтетичні коміти вже є частиною
вищезазначеного сховища).

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

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

приклад 1. ДОДАТИ КОМАНДА

Припустимо, що у вас є локальне сховище, до якого ви хочете додати зовнішній
бібліотека постачальника до. У цьому випадку ми додамо репозиторій git-subtree як підкаталог
вашого вже існуючого репозиторію git-extensions ~/git-розширення/:

$ git subtree add --prefix=git-subtree --squash \
git://github.com/apenwarr/git-subtree.git master

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

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

Зараз ми маємо а ~/git-extensions/git-subtree каталог, що містить код від master
гілка git://github.com/apenwarr/git-subtree.git у нашому репозиторії git-extensions.

приклад 2. ВИТЯГ A ПІДДЕРЕВО ВИКОРИСТАННЯ ЗОВНІСТИТИ, ВЕЛИКИЙ І ЗВИЙТИ

Давайте використаємо репозиторій вихідного коду git як приклад. Спочатку отримайте власну копію
репозиторію git.git:

$ git клон git://git.kernel.org/pub/scm/git/git.git test-git
$ CD test-git

gitweb (commit 1130ef3) був об’єднаний з git після коміту 0a8f4f0, після чого його не було
довше обслуговуються окремо. Але уявіть, що його обслуговували окремо, і ми хотіли
щоб витягти зміни git до gitweb з того часу, щоб поділитися з вищестоящим. Ви можете
зробити це:

$ git subtree split --prefix=gitweb --annotate='(split) ' \
0a8f4f0^.. --onto=1130ef3 --rejoin \
--гілка gitweb-latest
$ gitk gitweb-останній
$ git push [захищено електронною поштою]:whatever/gitweb.git gitweb-latest:master

(Ми використовуємо 0a8f4f0^.. тому що це означає «всі зміни від 0a8f4f0 до поточного
версія, включаючи сам 0a8f4f0.")

Якби gitweb спочатку був об’єднаний за допомогою мерзотник піддерево додавати (або відбувся попередній розкол
вже було зроблено з указаним --rejoin), то ви можете виконувати всі свої розбиття без необхідності
щоб запам'ятати будь-які дивні ідентифікатори фіксації:

$ git subtree split --prefix=gitweb --annotate='(split) ' --rejoin \
--філія gitweb-latest2

І ви можете так само легко об’єднати зміни з попереднього проекту:

$ git subtree pull --prefix=gitweb \
[захищено електронною поштою]:whatever/gitweb.git майстер

Або, використовуючи -- сквош, ви можете перемотати назад до попередньої версії gitweb:

$ git subtree merge --prefix=gitweb --squash gitweb-latest~10

Потім внесіть деякі зміни:

$ date >gitweb/myfile
$ git додати gitweb/myfile
$ git commit -m 'створив мій файл'

І знову швидко вперед:

$ git subtree merge --prefix=gitweb --squash gitweb-latest

І зауважте, що ваша зміна все ще неушкоджена:

$ ls -l gitweb/myfile

І ви можете розділити його і подивитися на свої зміни порівняно зі стандартним gitweb:

git log gitweb-latest..$(git subtree split --prefix=gitweb)

приклад 3. ВИТЯГ A ПІДДЕРЕВО ВИКОРИСТАННЯ ФІЛІЯ

Припустимо, що у вас є вихідний каталог із багатьма файлами та підкаталогами, і ви хочете
витягніть каталог lib у власний проект git. Ось короткий спосіб зробити це:

Спочатку створіть нове сховище, де забажаєте:

$
$ git init --bare

Назад у свій вихідний каталог:

$ git subtree split --prefix=lib --annotate="(split)" -b split

Потім перемістіть нову гілку в нове порожнє сховище:

$ git push split: master

Використовуйте git-subtree онлайн за допомогою служб onworks.net