Я хотел бы получить несколько советов по лучшей обработке и управлению проектами, которые имеют следующую структуру:
Из родительского проекта (совместно используемого многими проектами) мне нужно получить заданную структуру каталогов и файлы, т.е.
.
|-- modules/
| |-- file_1_parent.py
|
|-- controllers/
|-- file_2_parent.py
Из этого родительского проекта выводятся несколько зависимых дочерних, которые добавляют файлы в каталоги.
Тогда ситуация может выглядеть следующим образом (в скобках указаны имена проектов, которым принадлежат файлы/каталоги)
.
|-- modules/ (parent project)
| |-- file_1_parent.py (parent project)
| |-- file_1_child.py (child project)
|
|-- controllers/ (parent project)
|-- file_2_parent.py (parent project)
|-- file_2_child.py (child project)
Чтобы быть конкретным, в моем случае родительским проектом является проект web2py/django, из которого я хочу получить несколько подпроектов.
Вопрос в том,
Я думал о следующих подходах:
git submodule или git subtrees:
Это не работает, потому что мне нужна очень жесткая структура каталогов и файлов из родительского проекта.git remotes в локальном проекте, то есть два git origins, один в родительский и один в дочерний проект: Против этого решения говорит то, что для того, чтобы где-то развернуть проект, я не могу просто запустить git clone, а должен вручную установить несколько git remote -v origin..gitignore: Возможно, это не решение, что не так уж плохо, но я не знаю инструмент для достижения этого. Возможно, существует инструмент, который может установить данную версию из репозитория github с помощью какой-либо команды, например some_paket_manager install path/to/git/repo==v.0.0.9




Просто выполняйте обычные слияния, единственное, что вам нужно помнить, это когда/если вы объединяете обратную работу с родительскими файлами, выполненную в дочерней ветке, чтобы удалить файлы, специфичные для дочернего проекта, и изменения из результата слияния. Git держит все в порядке, пока вы записываете, что вы на самом деле делаете. git diff --diff-filter=A --name-only @ покажет вам все файлы, добавленные во время полета, например. что-либо, внесенное слиянием без фиксации, так что сделайте слияние без фиксации, исправьте результаты, чтобы они включали только те изменения, которые вы хотите, зафиксируйте это, готово. Как только вы поймете, что нужно исправить, вы сможете многое автоматизировать, но это не всегда будет просто удаление каждого нового файла.
вы можете нажимать и извлекать отдельные истории, имена и границы репо — все на ваше усмотрение. Таким образом, одним из способов было бы центральное репо только для родительской ветки, чей мастер вы извлекаете в «родительскую» ветку в репозитории каждого клиента, ветвление/слияние из него для клиентского проекта, как обычно, и любая родительская работа, которая в конечном итоге выполняется в клиентское репо извлекается, как показано в ответе здесь, возвращается в промежуточную ветку в родительском репо для тестирования и слияния с мастером.
Итак, вы предлагаете иметь родительский и дочерний элементы в качестве ветвей в одном проекте? Но как я тогда смогу поделиться родительскими файлами, а также их изменениями между всеми проектами, которые зависят от родителя? Обновив родительские файлы в отдельной ветке, мне нужно будет обновить родительские файлы каждого проекта с помощью «копировать и вставить»? И большое спасибо за ответ!!