2016-02-03 3 views
0

Я читал различные учебники git, но все же имею некоторые открытые вопросы относительно того, как использовать репозитории git &.Ищет консультацию, как структурировать репозиторий/ветвь git

Вот ситуация у меня есть:

У меня есть базовый код «A», который поддерживается внешним партнером, и я получить исходный код обновляется каждые несколько месяцев для него. Основываясь на базе кода «A», я создал еще один продукт «B», который является моим основным продуктом. Затем я использую продукт B в качестве базы для своих клиентов. У каждого клиента есть свои небольшие корректировки. Поэтому я поддерживаю отдельную базу кода для каждого клиента. Визуально это будет выглядеть примерно так:

 A 
    | 
    B 
// \ \  
C D F G 

Теперь проблемы :) Каждый раз изменение происходит на код базовый «А» или «В», у меня сложная задача, чтобы объединить все изменения в других кодовых базы. Я ищу способ, как использовать Git для облегчения этой задачи слияния кода для меня.

Прочитав учебники, я многому научился. Но, тем не менее, у меня есть фундаментальный вопрос о том, как должна выглядеть моя структура репозитория/филиала. Вот мои вопросы:

  • Нужно ли иметь хранилище для каждой базы кода?
    • Если да, то как я могу выполнять код, сливается между различными хранилищами?
  • Должен ли я иметь один репозиторий с несколькими ветвями для каждой базы кода?

    • Какой должна быть моя главная ветка? A или B?
    • Как должно выполняться слияние? используя rebase?
    • являются филиалами, хранящимися в отдельных папках?
  • Есть ли другой (лучший) способ решения проблемы?

Любая помощь будет замечательной! Спасибо

ответ

0

Непонятно, насколько чистым является разрез между А и В. Вы можете либо решить поместить все это в один репозиторий, либо разделить каталоги, либо поместить их в отдельные репозитории и сделать A подмодулем B, возможно. Это зависит от того, как вы получаете эти обновления.

Что касается ветвей; вы можете иметь одну ветвь для каждого варианта B, а затем всякий раз, когда вы делаете обновление для B, которое должны иметь другие кодовые базы, вы просто добавляете git merge B в другие ветви, если это необходимо. Поскольку вы, кажется, изменяете B (вместо того, чтобы расширять его) для каждого из кодовых баз, наличие B в качестве подмодуля не будет работать здесь.

В отношении отдельных папок для филиалов: нет, а не напрямую. Когда вы просматриваете одну ветку, другой код недоступен в вашем рабочем каталоге. Вам нужно будет проверить другую ветку, чтобы переключиться на другую кодовую базу, изменив содержимое рабочего каталога. Вы можете настроить multiple working trees, хотя, если вы обнаружите, что переключаете много. Это немного экспериментальная функция, хотя, и есть несколько ошибок, когда вы также работаете с подмодулем.Вы также можете просто просто поддерживать несколько экземпляров одного и того же репозитория, принимая накладные расходы. Или просто переключайтесь между ветвями, когда вам нужно.

+0

Нет чистого разреза между 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

+0

Правильно, идея субмодулей тогда не применяется. Это звучит как 6 ветвей и объединяет в одном направлении (т. е. когда A обновляет, объедините его в B, затем слейте B в C/D/E/F) – Joost

Смежные вопросы