Опыт по git

Объединить ветки в одну и добавить опцию в систему сборки, чтобы собирать тот или иной вариант.

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

Обычно тут 3 варианта: либо выделять форк в отдельный репозиторий и развивать совершенно независимо, либо сливать в мастер в отдельную директорию, делая, вероятно, часть кода общей и развивать как набор связанных утилит, либо вообще разбивать на 3 репозитория - общий код в виде библиотеки и два независимых приложения. Нет, в отдельной ветке независимое приложение никто не держит.

чтобы собирать тот или иной вариант.

А лучше оба вместе.

А лучше оба вместе.

Я так понял это одно и то же приложение, а не два разных.

Так уж сложилось) Сейчас сделал форк просто одного репозитория. А как лучше делать когда у этих двух приложений, например, есть пару общих модулей?

Выдели модули в отдельный репозитариум и научись в git submodule

Если приложения и библиотеки связаны между собой, то не вижу смысла разделять на несколько репозиториев. Особенно, если они небольшие.

научись в git submodule

Не стоит. Лучше git subtree для таких целей.

научись в git submodule

Не стоит. Лучше git subtree для таких целей.

git subtree явно лучше, но почему на github используют исключительно (или в основном) именно submodules?

Я же вроде написал. Либо держать в одной репе общие модули и два приложения, либо всё по отдельным репам. В зависимости скорее всего от того могут ли модули в теории понадобиться где-то ещё.

git subtree ничем не лучше, потому что засоряет историю и репозиторий в целом.

git subtree ничем не лучше

Твое мнение понятно и проигнорировано.

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

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

Минус - если надо быстро сделать какую-то правку во втором приложении и выкатить билд, а этот проект давно не открывался, то он может быть сломан и тяжело будет откатиться на последнюю совместимую версию или же адатировать код, чтобы он заработал.

Ну и держать три репозитория вместо одного придется.

Тоже очень удивляет этот момент.

При этом, нельзя в zip-архиве выкачать срез репозитория вместе с сабмодулями.

git subtree явно лучше, но почему на github используют исключительно (или в основном) именно submodules?

мне пока не приходилось использовать subtree, но submodules полезны тем, что для каждой ветки идет привязка к конкретным ревизиям submodules. это очень важно, если ветки основного проекта требуют конкретных ревизий/веток submodule. особенно когда submodule используется в нескольких разных проектах/репозиториях.

насколько я понял из документации, subtree делает немного другое. он «копирует» другой репозиторий в твой, вместе с историей. коммиты после этого не попадут в исходный репозиторий.

кстати, еще одно применение submodule, это если в репозитории есть модуль большого размера, который нужен очень малому количеству пользователей.

например, в моем случае это файлы для сборки под OSX. лишние 100 MB для скачивания, тогда как исходники с гитхаба качают практически только линуксоиды.

посредством submodule, им не надо качать лишний объем.

submodules полезны тем, что для каждой ветки идет привязка к конкретным ревизиям submodules. это очень важно, если ветки основного проекта требуют конкретных ревизий/веток submodule. особенно когда submodule используется в нескольких разных проектах/репозиториях.

Насколько я понимаю, subtree дает такую же точную привязку + дает возможность патчить исходники по месту без возни с дополнительным репозиторием. Кстати, если проект использует в качестве submodule чужой репозиторий X, его нужно поправить, но прав на запись в X нет - что делается?

коммиты после этого не попадут в исходный репозиторий.

Ну, если нужно интенсивно менять submodule _и_ отдавать изменения в апстрим - наверное, submodule лучше. Но, по моему опыту, для библиотечного кода подход subtree удобнее - все исходники в одном месте, клонирование одной командой без зависимости от интернета.

если в репозитории есть модуль большого размера, который нужен очень малому количеству пользователей.

Типа «largefile для бедных»? Мне никогда не было нужно, так что судить не берусь.

Кстати, если проект использует в качестве submodule чужой репозиторий X, его нужно поправить, но прав на запись в X нет - что делается?

в этом случае, я не использую submodule. что делают те, кто использует, не знаю.

Но, по моему опыту, для библиотечного кода подход subtree удобнее - все исходники в одном месте, клонирование одной командой без зависимости от интернета.

согласен, для библиотечного лучше.

Типа «largefile для бедных»? Мне никогда не было нужно, так что судить не берусь.

нет, 100 мегабайт исходников, нужных для сборки под макось.

речь об этом репозитории

А как можно вынести в отдельный репозиторий уже созданные модули в проекте, которые сейчас находятся под контролем версии? Как клонировать submodule из репозитория я научился)) но это если уже есть репа с модулями, а если я хочу пару модулей выделить и сделать их submodule в текущем проекте?

А я не говорил что я гуру ГИТа )).
Как-то они выделялись, но каждый день я этим не занимаюсь и уже успел забыть.