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

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

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

У нашего Мерзавца repo есть много ответвлений, выглядит примерно так:

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

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

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

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

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

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

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

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

Так, мои фактические вопросы были бы:

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

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

Большое спасибо заранее в течение Вашего времени и справки.

11
задан Tom Davies 22 February 2010 в 16:35
поделиться

1 ответ

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

Хорошо, и настоящий ответ. Встроенного способа нет, потому что (если предположить, что это не ускоренная перемотка) вам действительно нужно проверить файлы, чтобы git сделал свою магию слияния. К счастью, на самом деле вы делаете не так уж много (git checkout && git merge), поэтому написать скрипт не составит труда. Вы можете усложнить это с помощью конфигурационного файла или даже добавить некоторые пользовательские вещи в .git/config (например, git config branch..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 для проверки того, что master уже был слит в данную ветку, и избегать её проверки. Если вы переходите к прошлым неудачным слияниям, вы можете выполнять проверку и слияние отдельно, на случай, если именно проверка не удалась (это может подразумевать грязное рабочее дерево, что означает, что все они будут неудачными). Надеюсь, этого достаточно, чтобы начать!

8
ответ дан 3 December 2019 в 10:44
поделиться
Другие вопросы по тегам:

Похожие вопросы: