Как поддерживать длинные ветки git

Git ветки идеально должны длиться в течение короткого времени, вероятно, на 1-2 дня. Затем он объединяется в некоторую магистраль.

Но в некоторых случаях, когда мы работаем с очень большими функциями, мы поддерживаем ветки. И когда 2 или 3 человека работают над этими очень большими функциями в исключительных областях кода, становится довольно сложно поддерживать их.

Наряду с горячими исправлениями, которые идут в стабильную ветвь, нам нужно держать эти 2-3 больших ветки синхронно со стабильной ветвью. Поэтому мы в конечном итоге делаем это довольно часто.

(in feature-branch1) $ git merge stable
(in feature-branch2) $ git merge stable
(in feature-branch3) $ git merge stable

Есть ли правильный способ поддерживать эти длинные ветки в git? Делая вышеизложенное, история git выглядит беспорядочной. Эти ветки функций в основном выталкиваются на удаленный, что означает, что мы не можем видеть rebase в качестве опции. Что еще я могу сделать?

Ответ 1

Слияние в стабильной ветки время от времени на самом деле является самым простым и лучшим, что вы можете сделать, чтобы обновлять свою ветку функций. Я бы не рекомендовал переупаковывать, потому что одновременно может быть больше людей, работающих над этой функцией, и они должны будут reset их локальные ветки много раз каждый раз, когда был принудительный толчок. Даже если только один человек работает в ветки признака, слияние лучше, потому что оно ясно показывает точку в истории, где вы ввели исправления из устойчивой ветки.

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

Если вы действительно хотите избежать слияния новых функций от стабильного в ветки функции, но просто хотите получить исправления, вы можете вставлять исправления ошибок в ветвь функции. Однако это может быть очень много работы, потому что это требует, чтобы вы всегда находились на вершине всего, что происходило в стабильном состоянии. Используйте git cherry, чтобы помочь вам:

# commits from "stable" that are not present in
# the current branch will be prefixed with "+"
git cherry HEAD stable

Ответ 2

Rebasing возможен, если команда достаточно мала и состоит из разумно опытных пользователей git.

Что вы можете сделать, например, согласитесь, что функция-ветвь будет стабилизироваться каждую ночь. Или вы можете отправить электронное письмо, если вы переустановите ветвь feature-branch на stable.

Все должно быть хорошо, но в случае, если вы забыли синхронизировать с дочерней ветвью, скажите, что вы положили C поверх старой ветки Feature oldFB, которая была переустановлена на oldFB':

S1 - oldFB - C <-- feature-branch
    \
     S2 - oldFB' - D <-- origin/feature-branch

По-прежнему можно переустановить свои фиксации C, запустив:

git checkout feature-branch
git rebase --onto origin/feature-branch oldFB C

Обратите внимание, что вам нужно вручную найти фиксацию с именем oldFB на диаграмме выше.

Ответ 3

Лучшим вариантом является объединение только необходимых небольших ветвей bugfix/feature в ваши долговременные ветки функций. Таким образом, вы получаете только то, что вам нужно. Обратите внимание: если вы позволите этим ветвям жить достаточно долго, они могут в конечном счете получить довольно несинхронный от мастера. Время от времени вам может понадобиться создать временную ветку вашей долговременной ветки функций и объединить ее в нее только для проверки работоспособности - посмотрите, есть ли конфликты, посмотрите, не изменились ли изменения в главном устройстве, и так далее на.

Лучше всего было бы периодически объединять мастер в свои долговечные ветки функций. Это довольно безопасно, но может также объединиться во множество изменений, которые вам не интересны, и усложнять ситуацию.

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