Git: есть ли более быстрый способ слияния из одной ветки в несколько ветвей, чем для каждого из них последовательно?

Моя ситуация:

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

Наш Git repo имеет несколько ветвей, которые выглядят примерно так:

master
apple
banana
cherry
...
strawberry
tangerine
...

Если каждая ветвь, полученная из фруктов, содержит производственный код для производственного экземпляра.

(Мастер не используется для активного развертывания, но содержит весь общий код и является тем, к чему мы клонировали, чтобы настроить новый экземпляр.)

Моя проблема:

Работа, характерная для одного экземпляра, достаточно проста, происходит в том, что в ветке (или в ее ветки) и т.д. и т.д.

Однако, если мне нужно внести изменения, которые будут влиять на все сайты в кластере, я делаю это на данный момент в ветки dev и объединять его в master, а затем (что мне надоедает) приходится вручную проверять каждую продукцию разветвляются по очереди и объединяют в нее мастер.

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

На данный момент у нас есть что-то вроде 8 производственных отделений, так что это не так уж плохо, но план для роста, и к тому времени, когда это дойдет до 20 (не говоря уже о 50+), это будет серьезная боль. Это также будет моей личной болью, поскольку я тот, кто, вероятно, будет иметь дело с этим на повседневной основе.

Итак, мои актуальные вопросы:

  • Есть ли что-то в функциональности ядра Git, которое мне не хватает, что позволит мне элегантно слиться с мастером на n других ветвей одним махом? (вряд ли я думаю, но, тем не менее, стоит спросить)
  • В качестве альтернативы, может ли быть способ сделать это с помощью хитрых сценариев оболочки? (из которых я мог бы добавить, я знаю очень мало, и понимаю даже меньше).

Если последний из них может помочь мне начать/указать мне в правильном направлении?

Большое спасибо за ваше время и помощь.

Ответы

Ответ 1

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

Хорошо, и реальный ответ. Там нет встроенного способа, потому что (предполагая, что это не быстрый переход) вам действительно нужно, чтобы файлы были извлечены для git, чтобы сделать свою магию слияния. К счастью, вы на самом деле ничего не делаете (git checkout && git merge), поэтому не нужно писать script. Вы можете усложнить это конфигурационным файлом или даже добавить некоторые настраиваемые элементы в .git/config (например, git config branch.<branchname>.productionbranch true, а затем использовать команды git, чтобы проверить, какие ветки имеют этот флаг), но самый простой способ - это что-то вроде это:

#!/bin/bash

production_branches=( branch1 branch2 branch3 )

for branch in ${production_branches[@]}; do
    if ! ( git checkout $branch && git merge master ); then
        exit
        # Exit on the first error
        # If you want to just plow ahead, do something like this:
        # git reset --hard       # make sure there aren't merge conflicts in the tree
        # failed_merges="$failed_merges $branch"  # remember for later
    fi
done

# if you plowed ahead above, print the branches which failed to checkout+merge
# if [ -n "$failed_merges" ]; then
#     echo "Failed merges: $failed_merges"
# fi

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