Задача. Есть багтрекер, есть git. Хотелось бы исправления по тикету багтрекера как-то отмечать в git'e.
Как это лучше сделать? На каждый тикет создавать ветку? Так это можно веток наплодить. Наверняка уже есть какое-то решение.
Здравствуйте, Dym On, Вы писали:
DO>Задача. Есть багтрекер, есть git. Хотелось бы исправления по тикету багтрекера как-то отмечать в git'e. DO>Как это лучше сделать? На каждый тикет создавать ветку? Так это можно веток наплодить. Наверняка уже есть какое-то решение.
Каждый тикет в своей ветке. Что страшного в большом колличестве веток, если их закрывать по завершении?
Здравствуйте, Dym On, Вы писали:
DO>Задача. Есть багтрекер, есть git. Хотелось бы исправления по тикету багтрекера как-то отмечать в git'e. DO>Как это лучше сделать? На каждый тикет создавать ветку? Так это можно веток наплодить. Наверняка уже есть какое-то решение.
В commit message помечать в машинно-разбираемом формате номер тикета.
Например, у нас это /^RT#(\d+):?\s/ в первой строке.
Рекомендуемый формат зависит от трекера, у большинства есть плагины для этого, позволяющие рисовать ссылки и автоматом писать в тикет записи о принятом коммите.
Здравствуйте, Dym On, Вы писали:
DO>Задача. Есть багтрекер, есть git. Хотелось бы исправления по тикету багтрекера как-то отмечать в git'e. DO>На каждый тикет создавать ветку?
Здравствуйте, Dym On, Вы писали:
NW>>Что страшного в большом колличестве веток, если их закрывать по завершении? DO>Неудобно, во всяких gui'ях будет в комбобоксе простыня вываливаться...
Я в основоном hg + tortoiseHg пользуюсь, там закрытые ветки по умолчанию не показываются.
Здравствуйте, Dym On, Вы писали:
DO>Как это лучше сделать? На каждый тикет создавать ветку? Так это можно веток наплодить. Наверняка уже есть какое-то решение.
Ничего страшного в большом числе веток нет. В связке Stash+JIRA, например, можно вот так:
HgLab: Mercurial Server and Repository Management for Windows
К чему это? У человека софт не позволяет работать с большим числом веток. Я предложил использовать теги. Судя по SO это помогло как минимум 31-му разработчику. Где тут кактусы?
Здравствуйте, vsb, Вы писали:
vsb>К чему это? У человека софт не позволяет работать с большим числом веток. Я предложил использовать теги. Судя по SO это помогло как минимум 31-му разработчику. Где тут кактусы?
Это я так неумело набрасываю . Суть в том, что я не мог оставить без комментария то упорство, с которым пользователи Git'а обходят его врожденные проблемы. Это раз.
А два -- если помечать тегами все слияния, то получим, по сути, ту же проблему: вместо большого числа ветвей будет то же число тегов.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
vsb>>К чему это? У человека софт не позволяет работать с большим числом веток. Я предложил использовать теги. Судя по SO это помогло как минимум 31-му разработчику. Где тут кактусы?
Н>Это я так неумело набрасываю . Суть в том, что я не мог оставить без комментария то упорство, с которым пользователи Git'а обходят его врожденные проблемы. Это раз.
А как эта проблема решается в других похожих системах?
Н>А два -- если помечать тегами все слияния, то получим, по сути, ту же проблему: вместо большого числа ветвей будет то же число тегов.
С ветвями разработчики работают постоянно — переключаются и т.д., теги это больше как некие архивные исторические данные. Особенно если организовывать их по какой-нибудь иерархической системе вроде release/1.0.0 или issue/1234.
Здравствуйте, vsb, Вы писали:
vsb>А как эта проблема решается в других похожих системах?
В Mercurial, например, имя ветки является неотъемлемой частью чейнджсета и для мердж-коммита всегда можно увидеть, из каких веток были его родители.
Git'овские ветки в Hg называются Bookmark'ами и в сочетании с работающими уже фазами и обкатываемым на данный момент функционалом по эволюции ченджсетов они являются вещью гораздо более функциональной, чем ветки в Git.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Git'овские ветки в Hg называются Bookmark'ами и в сочетании с работающими уже фазами и обкатываемым на данный момент функционалом по эволюции ченджсетов они являются вещью гораздо более функциональной, чем ветки в Git.
Еслм честно, звучит пугающе: git по сравнению с mercurial'ом уже кажется простым понятным инструментом, который "просто работает".
Здравствуйте, Константин, Вы писали:
К>Еслм честно, звучит пугающе: git по сравнению с mercurial'ом уже кажется простым понятным инструментом, который "просто работает".
Если тут накидать Git'овской терминологии (tracking branches, remote tracking branches, detached head), то станет не менее страшно.
HgLab: Mercurial Server and Repository Management for Windows
. Суть в том, что я не мог оставить без комментария то упорство, с которым пользователи Git'а обходят его врожденные проблемы. Это раз.
