Как поддерживать длинные ветки 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 в ваши долговременные ветки функций. Таким образом, вы получаете только то, что вам нужно. Обратите внимание: если вы позволите этим ветвям жить достаточно долго, они могут в конечном счете получить довольно несинхронный от мастера. Время от времени вам может понадобиться создать временную ветку вашей долговременной ветки функций и объединить ее в нее только для проверки работоспособности - посмотрите, есть ли конфликты, посмотрите, не изменились ли изменения в главном устройстве, и так далее на.
Лучше всего было бы периодически объединять мастер в свои долговечные ветки функций. Это довольно безопасно, но может также объединиться во множество изменений, которые вам не интересны, и усложнять ситуацию.
Я бы не рекомендовал периодически переустанавливать мастер. Это затрудняет синхронизацию для всех, а также затрудняет сохранение сложной истории (слияния) в ваших ветвях функций и делает конфликт более болезненным.