Я читал различные учебники git, но все же имею некоторые открытые вопросы относительно того, как использовать репозитории git &.Ищет консультацию, как структурировать репозиторий/ветвь git
Вот ситуация у меня есть:
У меня есть базовый код «A», который поддерживается внешним партнером, и я получить исходный код обновляется каждые несколько месяцев для него. Основываясь на базе кода «A», я создал еще один продукт «B», который является моим основным продуктом. Затем я использую продукт B в качестве базы для своих клиентов. У каждого клиента есть свои небольшие корректировки. Поэтому я поддерживаю отдельную базу кода для каждого клиента. Визуально это будет выглядеть примерно так:
A
|
B
// \ \
C D F G
Теперь проблемы :) Каждый раз изменение происходит на код базовый «А» или «В», у меня сложная задача, чтобы объединить все изменения в других кодовых базы. Я ищу способ, как использовать Git для облегчения этой задачи слияния кода для меня.
Прочитав учебники, я многому научился. Но, тем не менее, у меня есть фундаментальный вопрос о том, как должна выглядеть моя структура репозитория/филиала. Вот мои вопросы:
- Нужно ли иметь хранилище для каждой базы кода?
- Если да, то как я могу выполнять код, сливается между различными хранилищами?
Должен ли я иметь один репозиторий с несколькими ветвями для каждой базы кода?
- Какой должна быть моя главная ветка? A или B?
- Как должно выполняться слияние? используя rebase?
- являются филиалами, хранящимися в отдельных папках?
Есть ли другой (лучший) способ решения проблемы?
Любая помощь будет замечательной! Спасибо
Нет чистого разреза между A и B. У меня может быть один файл «foo.txt» во всех ветках с различным контентом. Например, например: on ** A ** foo.txt is '"boo"'; on ** B ** '"boo with B"'; on ** C ** - '"boo with B & C"'; on ** D ** -'" boo with B & D "' – Gintautas
Правильно, идея субмодулей тогда не применяется. Это звучит как 6 ветвей и объединяет в одном направлении (т. е. когда A обновляет, объедините его в B, затем слейте B в C/D/E/F) – Joost