NetBSD переходит на Mercurial. И Git. Одновременно.

С чем я могу согласиться, так это с тем, что кажется не хватает какой-то сущности, описывающей патч-серию. Не ветка, в которой может быть много чего, а именно то, что получается, когда генерируешь через git format-patch --cover-letter. Серия коммитов и описание зачем оно нужно. Описание по сути сейчас это текст PR, но если мы говорим о больших фичебранчах, то там такая серия может быть и не одна. И было бы удобно trailers, ссылки и прочее привязывать именно туда.

Коммитер в ветку может поставить не то. Все что человек вводит, он может ввести не так.

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

Артефакты, от него нагенеренные, уже лежат в репозитории. Их придется убирать.

Так и что? Речь о том, что ты меняешь метаданные коммита, но в истории (git log) этот никак не отражается. Это впрочем касается и работы с ветками в git`е, а не только тегов.

Это чрезвычайно тривиальная задача, она буквально везде решена. Вот где угодно: BitBucket, GitHub, GitLab, Forgejo, LKML. Все справились.

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

Так проблема не в этом, проблема в том что теперь у тебя вместо одной сущности (имя ветки) их две.

Эти сущности не нужно использовать одновременно (либо одно, либо другое): см. как сделано в mercurial, где есть т.н. short-term ветки (аналог веток в git) и permanent ветки.

Точно тем же механизмом проверяется валидность коммитов. Это один и тот же механизм hooks.

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

Генерирует. Куча проектов этим пользуется.

Ещё раз: это всё является специфичным для проекта и полагается на соглашение по наличию определенных тегов. Куча проектов это используют. Другая куча использует немного по-другому. Третья куча вообще ничего не знает про git-describe.

Точно также как строка вида «Merge branch ‘feature/add-something’» это не более чем human-readable комментарий, а не документированный атрибут коммита, по которому можно определить ветку - источник merge.

При условии, что у тебя стратегия merge PR контролируется на стороне UI для мержа и там ты можешь форсить любую политику, какую тебе захочется. Так что если тебе в проекте нужно, чтобы у тебя были MR, это контролируется галкой в UI.

Так бога ради, мы уже установили, что зафорсить правильную историю в Git это один клик в UI.

Что значит не всегда? Галка в UI стоит, принятие PR всегда вырождается в git merge –no-ff на стороне сервера.

Ох, я уже ведь писал, что это верно, только в случае, если это твои личный репо или ветка. В остальных случаях это весьма и весьма непросто. Для того, чтобы «продавить» такое изменение нужно во-первых самому разобраться в специфике git (что такое ветки в git, и чем они отличаются от веток в других VCS), во-вторых аргументировано убедить заметную часть разрабочиков, работающих с репо, и собственно ответственое лицо, принимающее решение, по настройкам репо или конкретных веток.

Вот возьмем твою фразу: «зафорсить правильную историю в Git»

Что есть правильная история? В интернетах полно самых разных мнений, вплоть до противоположных. Одни команды/майнтейнеры/разработчики считают что merge commit нужен, другие считают, что лишний («FF и линейная история наше всё»), третьи - что вообще не нужно форсить эти ограничения.

Можешь ли ты сослаться на относительно авторитетный источник, который бы обосновывал правильность именно такой merge политики или хотя бы плюсы и минусы? Или привести какую-то статистику по частоте использования того или иного подхода?

Когда мы начинаем уходить в сторону «ну вот разработчики пользуются тулзой неправильно», мы уходим не туда. Если разработчики не пользуются тулзой правильно и процессы у них всратые, то нет никаких веток, есть мастер с кучей коммитов «fix things lol» по пять тыщ строк.

Откуда такой вывод про разработчиков? Я в предыдущем комментарии писал, что относится к зоне ответственности разработчика, а что задача - VCS.

Разработчики занимаются своими прямыми обязанностями - пишут код, формируют аккуратные коммиты, и осведомлены о порядке внесения изменений в те или иные ветки согласно установленному регламенту. Но при этом абсолютно не горят желанием исследовать, как там устроен DAG в git, какие последствия несет присутствие/отсутствие merge commit, и в каких случаях нужно писать свой хук. Как и майнтейнер репо.

Просто потому, что в других VCS это работает «из коробоки» по умолчанию более-менее ожидаемым образом. И ветка в них, как правило, это перманентная ветка, а не ссылка на последний коммит, как в git. При переходе с другой VCS на git эти нюансы совсем не очевидны - и там branch, и тут branch (ну кроме ситуаций, когда разработчик ни с какой VCS, кроме git не работал).

Касательно «правильного использования тулзы» см. мой вопрос выше про авторитеный источник.

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

Говорю же, ОКР. Написать один раз в имени ветки или один раз в имени коммита? Какая разница-то?

Так и что? Речь о том, что ты меняешь метаданные коммита, но в истории (git log) этот никак не отражается. Это впрочем касается и работы с ветками в git`е, а не только тегов.

Я перестал понимать что происходит. Ты хочешь историю мержей? Она есть. Хочешь в git-log видеть определенный trailer? Это есть. Все есть.

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

Самое тривиальное из всех возможных. Более того, откуда именно достать номер тикета это мелкая деталь реализации. Его либо оттуда достать надо, либо отсюда. Достать-то все равно надо.

Эти сущности не нужно использовать одновременно (либо одно, либо другое): см. как сделано в mercurial, где есть т.н. short-term ветки (аналог веток в git) и permanent ветки.

Все это, повторюсь, чтобы лишнюю строчку не писать в тексте коммита. Куда ты все равно пишешь вещи вроде Signed-off-by. Ну безумие же.

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

Нет никаких готовых решений. Как именно BitBucket должен узнать что XXX-1234 в имени ветки dev/XXX-1234-add-foobar это номер тикета? Его все равно парсить нужно, в любом случае. Меняется только место, которое ты парсишь будешь.

Точно также как строка вида «Merge branch ‘feature/add-something’» это не более чем human-readable комментарий, а не документированный атрибут коммита, по которому можно определить ветку - источник merge.

Ваще пофиг, если это будет работать в 100% случаев. А это будет работать в 100% случаев если только специально не ломать.

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

Лол их везде нужно дописывать, потому что в Git нет сущности «номер тикета». Её и в Mercurial нет. Потому что к DVCS это вообще никакого отношения не имеет.

Ох, я уже ведь писал, что это верно, только в случае, если это твои личный репо или ветка. В остальных случаях это весьма и весьма непросто. Для того, чтобы «продавить» такое изменение нужно во-первых самому разобраться в специфике git (что такое ветки в git, и чем они отличаются от веток в других VCS), во-вторых аргументировано убедить заметную часть разрабочиков, работающих с репо, и собственно ответственое лицо, принимающее решение, по настройкам репо или конкретных веток.

Это нужно делать во всех случаях. Особенно когда у тебя два типа веток, вместо одного. Любая сложная система требует соглашения об использовании. Ты не можешь просто сказать «ну, у меня два типа веток и теперь-то все хорошо». Нет, теперь в два раза больше сущностей об использовании которых нужно договариваться. Это же очевидно, ну.

Что есть правильная история? В интернетах полно самых разных мнений, вплоть до противоположных. Одни команды/майнтейнеры/разработчики считают что merge commit нужен, другие считают, что лишний («FF и линейная история наше всё»), третьи - что вообще не нужно форсить эти ограничения.

Ну наконец-то до тебя дошло. Что такое правильная организация кода в любом случае решается в рамках проекта. Это нельзя затолкать в CLI и всем будет нормально, потому что у некоторых людей вообще нет понятия «main», у них пять релизов параллельно. А у других ветки живут годами и мержатся друг в друга по пять раз на дню, и в рамках ветки сильно больше одного тикета.

Просто потому, что в других VCS это работает «из коробоки» по умолчанию более-менее ожидаемым образом. И ветка в них, как правило, это перманентная ветка, а не ссылка на последний коммит, как в git. При переходе с другой VCS на git эти нюансы совсем не очевидны - и там branch, и тут branch (ну кроме ситуаций, когда разработчик ни с какой VCS, кроме git не работал).

Ты это считаешь «из коробки» просто потому что оно ложится на твой процесс и теперь тебе странно, что в Git это не дефолт. А на чей-то другой процесс это не ложится и им будет непонятно что за шизу ты им притащил и как это убрать.

Лол их везде нужно дописывать, потому что в Git нет сущности «номер тикета». Её и в Mercurial нет. Потому что к DVCS это вообще никакого отношения не имеет.

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

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

В Git это решается через trailers:

foo: do this

Blah-blah.

Ticket: XXX-1234
Signed-off-by: me

Вытаскивание всего этого поддерживается на уровне тулинга типа git-log. Возможно это можно было бы прицепить к коммиту через тот же механизм, что и PGP подпись, но это никогда ни у кого не вызывало проблем. Это решенная задача, она работает в сотнях компаний без каких-либо проблем. Ей можно решить по-другому сделав специальный API, но зачем?

В Git это решается через trailers:

Не совсем. Это имитация.

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

Я ровно то же про SVN слышал. Что git не нужен, SVN решает все проблемы, работает в сотнях компаний. Некоторые типа firkax до сих пор это утверждают. Вообще не аргумент.

Не совсем. Это имитация.

Что значит «имитация»? Информация передается? Передается.

Вообще не аргумент.

Если будешь так сильно передергивать, то оторвешь. Есть задача: привязать номер тикета к коммиту. Она решена? Да. Непротиворечиво? Да. С этим кто-то страдает, кроме ОКРщиков, которым страшно в commit message строчку написать? Нет. Требуются аргументы сильнее ‘hurr durr моя попка болит потому что это соглашение, а не ABI репозитория’, чтобы ABI принести.

P.S. оно кстати было в svn и называлось property.

Не совсем. Это имитация.

Что значит «имитация»? Информация передается? Передается.

Аналогично тому как сишники ООП имитируют через some_struct->method(some_struct, ...). ООП вроде есть, но как-то через жопу. Это фактически разница между нативной поддержкой чего-то и ручным запиливанием поверх.

С этим кто-то страдает, кроме ОКРщиков, которым страшно в commit message строчку написать? Нет.

А я вот не уверен, что не страдают. Основную проблему я тут вижу не в ОКР, а в том, что внешний тулинг это может по-разному парсить и валидировать, и где-то могут вылезти проблемы из-за разных форматов.

А я вот не уверен, что не страдают

Ну это тревожность, она лечится эсциталопрамом.

Азазазазаза затроллировал лалку!

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

Я понимаю, но я ни разу не слышал на это жалобы. На невнятный fixup с rebase и автосквош слышал. На то что теги надо отдельным ключом синкать слышал. На то что патчи без заранее выбраного общего предка норматьно не бекпортировать тоже слышал. И вот это прям реальные боли, которые регулярно неудобства создают.

А я вот не уверен, что не страдают. Основную проблему я тут вижу не в ОКР, а в том, что внешний тулинг это может по-разному парсить и валидировать, и где-то могут вылезти проблемы из-за разных форматов.

Не нравится пихать информацию в само сообщение коммита, тогда можешь запихнуть в примечания(git-notes). А в чём проблема договориться о формате? Вот есть json которые не так уж просто парсить, но ничего как-то пользуются.

Да, это буквально properties. LMAO, то есть все есть, просто это никому не нужно.

Я перестал понимать что происходит. Ты хочешь историю мержей? Она есть. Хочешь в git-log видеть определенный trailer? Это есть. Все есть.

я просто напомнил о том, что веток и тэгов не отслеживаются в git log, а только в reflog. И это недостаток git вообще, и в частности применительно к твоему предложению маркировать коммиты тегами. Подпись тега лишь слегка уменьшает эту проблему.

Ваще пофиг, если это будет работать в 100% случаев. А это будет работать в 100% случаев если только специально не ломать.

Осталось выяснить, кем или чем гарантирована работа в 100% случаев. На human-readable тексты никто обычно никаких гарантий не дает (что разработчики не поменяют их в другой версии). Наконец сам коммитер может поменять текст по умолчанию.

Самое тривиальное из всех возможных. Более того, откуда именно достать номер тикета это мелкая деталь реализации. Его либо оттуда достать надо, либо отсюда. Достать-то все равно надо.

Все это, повторюсь, чтобы лишнюю строчку не писать в тексте коммита. Куда ты все равно пишешь вещи вроде Signed-off-by. Ну безумие же.

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

Нет никаких готовых решений. Как именно BitBucket должен узнать что XXX-1234 в имени ветки dev/XXX-1234-add-foobar это номер тикета? Его все равно парсить нужно, в любом случае. Меняется только место, которое ты парсишь будешь.

Лол их везде нужно дописывать, потому что в Git нет сущности «номер тикета». Её и в Mercurial нет. Потому что к DVCS это вообще никакого отношения не имеет.

Конечно в git нет такой сущности как тикет. Но для реализации связи есть куча разных способов:

1. хранить эту информацию не в VCS, а в bug/task трекере, как связь с commit id. IMHO в случае git это предпочтительный вариант

2. использовать метаданные коммита, по аналогии с подписью коммитов в git. Этот вариант (также как и вариант с комментарием), плох тем, что исправления приведут к смене commit id.

3. git notes

4. ветка (в git этот вариант работает плохо, см. ниже про fossil)

Касательно других DVCS, я уже давал ссылку на пример fossil https://www.sqlite.org/whynotgit.html#git_does_not_track_historical_branch_names

Там как раз дан пример: перманентная ветка в fossil на 5 коммитов (не считая merge), связанных с багрепортом через имя ветки, ну или через теги (перманентные ветки в fossil сделаны через теги). И такая же ветка в github. Видно, что в случае git куча «лишних» коммитов, не относящихся к фиксу.

Про mercurial не знаю. Увы.

Это нужно делать во всех случаях. Особенно когда у тебя два типа веток, вместо одного. Любая сложная система требует соглашения об использовании. Ты не можешь просто сказать «ну, у меня два типа веток и теперь-то все хорошо». Нет, теперь в два раза больше сущностей об использовании которых нужно договариваться. Это же очевидно, ну.

Почти любое git workflow предполагает наличие «постоянных» и «короткоживущих» веток. Ну или общих интеграционных веток и приватных девелоперских. Это даже не особо специфично для git, и по-моему опыту при миграции с другой VCS тут каких-то особых проблем не возникало.

Ну наконец-то до тебя дошло. Что такое правильная организация кода в любом случае решается в рамках проекта.

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

Но вот когда постепенно выясняется, что git по умолчанию не хранит данных достаточных для отображения веток в привычном по другим VCS виде. И вообще очень много важной информации хранит исключительно в виде human-readable комментариев. И нужно тратить время на исследование и поиск решения. Это уже весьма неприятно.

Там как раз дан пример: перманентная ветка в fossil на 5 коммитов (не считая merge), связанных с багрепортом через имя ветки

Никак не могу понять что все так прицепились к прикреплению имени ветки/бранча к коммиту. Вот я увидел например баг в каком-то проекте, сгенерировал патч и отослал текстом через имейл/мессенджер/форум а разработчик применил его. И вот тут получается нету ни ветки/бранча ни таски, а коммит есть.

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

я просто напомнил о том, что веток и тэгов не отслеживаются в git log, а только в reflog

История мержей? Или о чем мы?

Осталось выяснить, кем или чем гарантирована работа в 100% случаев. На human-readable тексты никто обычно никаких гарантий не дает (что разработчики не поменяют их в другой версии). Наконец сам коммитер может поменять текст по умолчанию.

Роботом, который коммиты мержит.

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

Мне не нравится что при написании коммита мне нужно что думать как бы случайно не вставить в текст строку «ВЫ ВСЕ ПИДОРЫ». Это, к сожалению, никуда не уйдет. Даже если мы принесем номер тикета в git-notes, у нас все равно есть риск что кто-то продолбается.

хранить эту информацию не в VCS, а в bug/task трекере, как связь с commit id. IMHO в случае git это предпочтительный вариант

А это спорно. Я вот хочу видеть в git log что там по тикетам.

Там как раз дан пример

As an example, suppose a customer asks you: «What ever became of that ‘prefer-coroutine-sort-subquery’ branch from two years ago?»

Кажется что это будет звучать как «слушайте, а почему мы сделали вот так?», и тогда люди все равно пойдут в PR обсуждать.

Но вот когда постепенно выясняется, что git по умолчанию не хранит данных достаточных для отображения веток в привычном по другим VCS виде. И вообще очень много важной информации хранит исключительно в виде human-readable комментариев. И нужно тратить время на исследование и поиск решения. Это уже весьма неприятно.

А надо тратить? Вот те проблемы, что в fossil поднимались, они решаются чтением обсуждений в PR. Потому что ни разу не было вопроса «а что там с веткой?», всегда были вопросы «а почему фичу сделали вот так?».

Срач git vs hg уныл по определению, на вкус и цвет все карандаши разные, как известно.

Куда более интересный вопрос – как они в NetBSD собираются технически добиваться синхронизации этих двух репозиториев? Они же ведь собираются, я надеюсь? :)))

то что форум, багтрекер ... вместе с репой дублируется это гениально, но git популярней, помечтать очень хочется

Куда более интересный вопрос – как они в NetBSD собираются технически добиваться синхронизации этих двух репозиториев?

А в чём именно проблема?

Например хочу перенести коммит из git в hg, мои действия:

• подтягиваю коммит локально в hg.
• в git создаю коммит добавляя все изменения и информацию из hg коммита как-то время/автор/описание.
• пушю изменения git на сервер.

Вот так можно по одно коммиту bash скриптом делать в обе стороны. Хотя по нормальному можно конвертер нормальный написать.

Ну то есть, отслеживанием человек должен заниматься, ручками? Или…

Ну то есть, отслеживанием человек должен заниматься, ручками? Или…

Есть ведь хуки в git, то-же самое должно быть в hg. После коммита в одну или другую сторону просто запускать скрипт который перенесет коммит.

Да, возможно.

Примерно так же, как работал Subgit.

то я бы разделил его на 2: блобы - в Subversion, код - в DVCS

В реальном мире такое не работает, потому что гребцам с трудом один инструмент даётся, а ты в два раза больше предлагаешь.

А то я уже вроде рассказывал про случай, когда у заказчика контент сайта сохранялся в Git и один раз они случайно туда запушили пару видео по 1GB. После этого git status выполнялся по 30 секунд…

А, ну, собственно.

а разработчик применил его. И вот тут получается нету ни ветки/бранча ни таски, а коммит есть.

Или есть:

1. разработчик получил патч
2. создал bug/task. Это нужно, чтобы задокументировать проблему включая разные доп. сведения (логи, скриншоты и пр.). Иногда форум/mailing list частично выполняет роль багтрекера.
3. создал ветку
4. применил патч (первый commit)
5. сделал pull request на merge
6. на review получил замечания
7. сделал правки по замечаниям (второй commit)
8. сделал pull request + merge (тут опционально будет третий merge commit). Здесь ветка, созданная под bug, может быть удалена, но не обязательно
9. перевел (создал новый) bug на второго разработчика
10. второй разработчик стал бэкпортировать изменения в другие ветки
11. и т.д.

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

Изменения, вносимые по какому-то багрепорту и т.п., формируют упорядоченную последовательность commit`ов. Пока работа над задачей не закончена, ветка очевидно нужна как указатель на место следующего изменения. После окончания работы - тут вопрос спорный. По моему мнению ветка это полезная информация при дальнейшей работе с историей. Правда ветки в git для этого весьма неудобны. По другим мнениям, озвученным в этой теме, достаточно связи каждого коммита с багтрекером или тега.

P.S. ну и в дополнение: обычно на имена веток завязаны права доступа и всякие merge политики в настройках git-сервера

История мержей? Или о чем мы?

нет, я имею в виду, что если единственное изменение это например переименование/создание ветки или установка/удаление тега, то отражается это только в reflog. Ну и в каких-нибудь других логах сервера.

История PR - тоже только на стороне сервера (но это понятно, т.к. PR - это надстройка на git).

Роботом, который коммиты мержит.

Приходим всё к тому же: любое приложение для работы (просмотр/анализ) с историей в git должно учитывать настройки конкретного робота (включая и отсутствие такового).

Мне не нравится что при написании коммита мне нужно что думать как бы случайно не вставить в текст строку «ВЫ ВСЕ ПИДОРЫ». Это, к сожалению, никуда не уйдет. Даже если мы принесем номер тикета в git-notes, у нас все равно есть риск что кто-то продолбается.

Это как раз некритично: опечатки, нецензурная лексика - это все было и будет в человеческой переписке (а комментарии пишутся человеками для человеков). И VCS - это не цензор и не спеллчекер, чтобы решать эту проблему.

А вот то, что VCS лезет в текст комментария и пытается там найти признаки связей с task/bug, вызывает у меня недоумение. Полно же будет ложных срабатываний. (я об этом, если что https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword).

На этом фоне git trailers выглядит относительно безобидно. У них хотя бы фиксированное положение в хвосте коммита и key-value формат.

Кажется что это будет звучать как «слушайте, а почему мы сделали вот так?», и тогда люди все равно пойдут в PR обсуждать.

Не совсем. Задача именно в том, чтобы найти все коммиты относящиеся к фиче или bug`у. Если же ты имеешь в виду, что в метаданных PR этот список есть, то эта информация привязана к серверу. Т.е. во-первых мы терям распределенность, во-вторых завязываемся на возможности git сервера (а предоставляет ли он API для работы с PR), в третьих не всякий merge это PR. Если я как разработчик произвожу merge между своими же ветками, то PR (и прочий gated сheckin) мне там совершенно не нужен (тем более и делается такой merge на локальных ветках вне сервера).

А надо тратить? Вот те проблемы, что в fossil поднимались, они решаются чтением обсуждений в PR. Потому что ни разу не было вопроса «а что там с веткой?», всегда были вопросы «а почему фичу сделали вот так?».

Из моей практики ответы на вопросы «почему» содержатся в почтовой переписке, багтрекере и документации по проекту (которая в идеале тоже лежит в репозитарии).