Поиск слияния происходит из тега через ветки в git

Мой продукт - плагин для IntelliJ. Я поддерживаю несколько версий базовой платформы IntelliJ и выпускаю сборки моего плагина для каждого из них, так как их API часто меняются между версиями. Я просто работаю над этим, поэтому я развиваюсь в мастер, а затем поддерживаю ветку для каждой из других версий. Поэтому мое репо выглядит следующим образом:

   1.6.0  1.6.1-eap1
.... a---b---c--- master
      \       \
       d-------e--- idea-2017.1
        \       \
         f-------g--- idea-2016.3
          \       \
          ...     ...  etc etc

a является стабильным выпуском и помечен 1.6.0. c является выпуском EAP (бета) и отмечен 1.6.1-eap1. Эта схема отлично подходит для этих двух случаев.

Иногда я хотел бы создать сборку dev, которая не входит в канал выпуска, но пользователи могут загружать ее вручную и тестировать, если захотят. Я хотел бы создать сборку dev для каждой платформы, так как пользователи-разработчики могут использовать любую версию IntelliJ. Лучший способ, я могу думать, - создать ветку для dev, например, тег 1.6.0 (commit a), а затем соответствующие ветки от commits d, f и т.д., На которых я может объединить ветвь dev и создать из нее сборки dev.

Предполагая, что я хочу написать script для создания и поддержки этих ветвей, как я могу найти коммит d, f и т.д. из тега 1.6.0, чтобы создать ветки dev dev из <? p >

Ответы

Ответ 1

Для проблемы "найдите между a ang g самое раннее коммит из idea-2016.3, которое не было в idea-2017, а самое раннее в idea-2017, которое не было в master" решение было бы использовать команда:

git log --oneline --source --ancestry-path  master idea-2017 idea-2016.3 --not 1.6.0

вывод в истории аналогичен вашему:

cf32d9f idea-2017 e
88f264c idea-2016.3 g
5bc9fa1 idea-2017 d
3f460fe idea-2016.3 f
224cac8 master c
67620cd master b

Затем найдите последнюю строку, отмеченную idea-2016.3 и последнюю, помеченную idea-2017, это будет ваша фиксация.

Обратите внимание, что выход может быть нежелательным, если возникла проблема с блокировщиком из-за различий в версии, например, в f, которая была исправлена ​​в следующем f'. Поэтому я бы все же рассмотрел явные тегирования.

Ответ 2

Вот что я в итоге сделал:

#!/bin/sh

set -e  # Automatically abort if any simple command fails

die () {
    echo >&2 "[email protected]"
    exit 1
}

[ "$#" -eq 2 ] || die "Usage: $0 <branch name> <tag>"

tag_commit=$(git rev-list --abbrev-commit -n 1 $2)
[ "${tag_commit}" = "" ] && die "No commit found for $2"

child_commit() {
  git log --graph --pretty=format:"%h %p" --decorate -20  --first-parent $1 | grep $2 | cut -c 3-10
}

branch_2017_1=$(child_commit idea-2017.1 $tag_commit)
[ "${branch_2017_1}" = "" ] && die "No commit found for idea-2017.1"

branch_2016_3=$(child_commit idea-2016.3 $branch_2017_1)
[ "${branch_2016_3}" = "" ] && die "No commit found for idea-2016.3"

branch_2016_2=$(child_commit idea-2016.2 $branch_2016_3)
[ "${branch_2016_2}" = "" ] && die "No commit found for idea-2016.2"

branch_2016_1=$(child_commit idea-2016.1 $branch_2016_2)
[ "${branch_2016_1}" = "" ] && die "No commit found for idea-2016.1"

git branch "$1" $tag_commit
git branch "$1-2017.1" $branch_2017_1
git branch "$1-2016.3" $branch_2016_3
git branch "$1-2016.2" $branch_2016_2
git branch "$1-2016.1" $branch_2016_1

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

Секретный соус находится в функции child_commit, которая вырезана из здесь.

Ответ 3

Наверное, самым простым способом является поддержка списка поддерживаемых имен версий/ветвей в оболочке script?

Я думаю об этом, если вы добавите другое изменение:

1.6.0      eap1 eap2
.... a---b---c---h--- master
      \       \   \
       d-------e---i--- idea-2017.1
        \       \   \
         f-------g---j--- idea-2016.3
          \       \   \
          ...     ...  etc etc

Вы хотите, чтобы это изменение (h) было объединено с головкой ветвей, показанной на вашей диаграмме, т.е. h объединяется в e и g. В ветке 2017.1 указывалось бы на e, которое является правильной фиксацией для слияния.

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

Плюс, если вы просто сохраняете список веток, вы можете легко поддерживать старые версии.