Слияние, перебазировка или ветка для постоянной ветки?

Question

Концептуально: у меня есть ветка от master , называемая 'core' .

Эта ветвь будет существовать вечно.

Раз в неделю core необходимо регистрировать любые изменения, внесенные в master .

Один раз в месяц изменения, сделанные в core , необходимо отправить обратно в master .

core иногда будут иметь ветви типа feature1 или feature2 , которые могут существовать в течение месяца или двух, затем они будут объединены в core , а ветвь функций будет удалена, тогда core будетперенесите эти изменения в master в конце месяца.

Я мог бы сделать это, используя rebase или слияние, или я мог бы создавать новую ветку core каждый месяц после того, как она быласлился с master .

Я думаю, что лучший способ сделать это - просто использовать 'merge' еженедельно и ежемесячно, но я не настолько хорошо разбираюсь в github, так что это правильный путь или нетВы предвидите какие-либо проблемы в будущем?

          week1    week2     month end
--o--o--o--o--o--o--o--o--o--o--o--o--o--o--o master
  \        \         \         / \
   o--o--o--o--o--o--o--o--o--o---o--o--o--o core
          \              \             /
           o--o--o--o--o--o--o--o--o--o      feature

над мастером работает большая команда, ядро ​​имеет небольшую команду, и функция, как правило, будет состоять из одного человека (хотя его все еще отправляют на github для тестирования или демонстрации функции), команды ядра и мастеране часто трогать одни и те же файлы.

Answer 1

Предлагаемый вами рабочий процесс немного похож на Git flow (см. Также этот код ).

Что касается вашего вопроса о слиянии или перебазировании, он долженСледует отметить, что git rebase является деструктивной операцией (она не только изменяет SHA1 перебазированных коммитов, но также возможно, что кодовая база каждого коммита в ветви исходного кода компилируется, в то время как некоторые или все эти коммиты делаютбольше не компилируется после ребазирования!).Напротив, git merge сохранит все коммиты из двух ветвей на кону и создаст коммит слияния, который может включать изменения разрешения конфликта, если это будет необходимо.

Возможно, этот "недостаток" git rebaseпричина, по которой на практике поток Git всегда реализуется с использованием git merge (на самом деле git merge --no-ff, см. соответствующий doc ).

Однако некоторые команды могут выбрать другой рабочий процессдля интеграции вкладов в master, требующих использования git rebase origin/master всякий раз, когда существует некоторый конфликт между ветвью объектов и master (для того, чтобы иметь более «красивую», линейную историю).Тем не менее, в этом случае рекомендуется проверять, что каждый перебазированный коммит все еще компилируется (чтобы не мешать делению на части ).