Я создаю начальный проект (для себя), который буду использовать в качестве основы для нескольких других проектов. После поиска лучших практик для этого я нашел несколько полезных стратегий. Но я не уверен, какую стратегию использовать, и не чувствую, что у меня есть полное решение; рабочий процесс, который объясняет все шаги, необходимые для удовлетворения моих потребностей.
Пока я нашел 2 основные стратегии.
- Используйте несколько пультов:
git clone -o seed ssh://[email protected]/user/seed.git new_project_name
Семя -o переименовывает источник в seed, который по-прежнему можно использовать для извлечения изменений.
Создайте новый пустой репозиторий GitHub new_project_name. Затемgit remote add origin ssh://[email protected]/user/new_project_name.git
(Что такое правильный рабочий процесс git для создания проекта на основе «начального» репозитория?)
- Используйте несколько ветвей:
git clone https://github.com/username/seed.git/n
git branch myproject
git checkout myproject
Все ваши изменения не будут зависеть от исходного проекта. Если вы хотите быть в курсе и видеть, где находится начальный проект, все, что вам нужно сделать, это:
git checkout master
git pull
Теперь все ваши файлы исчезнут, и вы увидите, как выглядят последние материалы в «seed». Если вы хотите, чтобы ваш проект получил свои изменения, вы должны сделать это:
git checkout myproject
git merge master
(Как организовать репозитории git при создании исходный проект)
Если я использую стратегию «несколько пультов», я предполагаю, что не смогу вносить какие-либо изменения, которые я вношу в код, исходящий из начального проекта, поскольку начальный проект затем получит весь код, связанный с проектом, из которого я выталкиваю ( ?).
Если я использую стратегию «несколько веток», я предполагаю, что мне придется отправлять все проекты в мое начальное репо как разные ветки (?). Если я хочу изменить какой-либо код, исходящий из начального проекта, я всегда могу проверить и изменить мастер, а затем объединить изменения с веткой (ветвями).
Я чувствую, что должен использовать какое-то сочетание этих двух стратегий (или что-то совершенно другое). Потому что сразу же я столкнулся с проблемой, что я хотел изменить readme.md, package.json, gulpfile и т. д. в каждом проекте (который основан на seed-проекте). Если я затем git pull внесу какие-либо улучшения в исходный проект, я предполагаю, что изменения в этих файлах будут перезаписаны, или, по крайней мере, существует большой риск того, что придется иметь дело с постоянными проблемами слияния. Какую стратегию следует использовать, чтобы максимально упростить решение этих потенциально запутанных проблем?
(Я также рассматривал возможность разветвления, но это не кажется актуальным, если только все репозитории не являются просто альтернативными версиями одного и того же программного обеспечения (?), и вы хотите, чтобы один человек отвечал за слияние с основной версией (?). )
