Задать вопрос

Anton Bormotov

Комментарии

  • Как Вы формируете release notes?

    @qqwrst
    Смотрите:
    2 и 3 совершенно верно. Тэгируется только master ветка.
    Когда в develop выполнили merge всех бранчей разработчиков, тестируем develop бранч на QA сервере. После того как тестировщики и проект мэнеджеры дают зеленый свет, мы делаем merge develop бранча в master. После этого тэгируем мастер новой версией. Соответственно, в мастере появляются все новые коммиты, в том числе merge коммиты от бранчей разработчиков. Сообщения этих merge коммитов и являются release notes для нас, поскольку несут описание новых фич/features.

    А теперь первый ворос:
    - Последний тег пусть будет v1.1.3. А что тогда будет в текущем HEAD?

    Пусть v1.1.3 указывает на текущий HEAD мастера и мы сейчас в мастере. Предположим в develop бранче есть 5 коммитов. Мы сливаем изменения в мастер (git merge --no-ff origin/develop) и получаем 5+1 новых коммитов в мастере.
    Теперь HEAD указывает на последний коммит.
    Соответственно можно получить git log между v1.1.3 и HEAD.
    Или создать новый тэг для текущего HEAD: git tag v1.1.4.
    После этого посмотреть git log можно уже между двумя тэгами: v1.1.3 и v1.1.4

    Надеюсь что то прояснит это небольшое объяснение. :)
    Написано

  • Как Вы формируете release notes?

    @qqwrst
    Очень просто - только номер новой версии (цифра меняется в зависимости от изменений):
    1. Сливаем ветку develop в ветку master.
    git clone -b master
    git fetch origin develop
    git merge --no-ff --no-edit origin/develop

    2. Смотрим текущий список тэгов:
    git tag -l
    Вывод:
    v1.1.1
    v1.1.2
    и т. д.

    4. Извлекаем release notes между последним тэгом и текущим HEAD (как написал выше, с помощью git log)

    3. Создаем новый тэг:
    Либо git tag v1.1.3 and git push --tags origin master, либо curl запрос в github api, он там сам его создает и push не нужен.
    Написано

  • Как Вы формируете release notes?

    @qqwrst
    %b как я понял, это сообщение merge коммита, поэтому merge обязательно с опцией --no-ff.
    Написано

  • Как Вы формируете release notes?

    @qqwrst
    Добрый. Нет, немного не так.
    У нас есть develop бранч.
    Разработчик создает свой бранч (checkout из develop), например feature/update-qa.env-file
    Фиксирует туда коммиты, а потом создает pull request (push на github обязательно, конечно).
    Называя pull request, он следует определенному формату, но это не обязатено. Мы делаем это что бы иметь ту же систему именования, что и в task tracking tool.
    Название pull request и есть в git log опция format:%b (см. man git-log, секция format:)

    Таким образом нет необходимости использовать какой то "определенный формат" и потом делать grep.

    Попробуйте так сделать, на тестовом репозитории, например.
    Если что то непонятно, пишите, помогу по возможности.
    Написано

  • Входные данные хранятся в MySQL, Как хранить и вычислять данные "на лету" при обновлении одной из таблиц?

    @qqwrst Автор вопроса
    Дмитрий, я попробовал объяснить ситуацию более детально, если у Вас будет время, пожалуйста прочтите. Если у вас также есть ссылки касаемо выноса запроса в redis, был бы очень признателен. Спасибо.
    Написано