Обновить
87
zerkms@zerkms

Пользователь

50
Подписчики
Отправить сообщение
Долгоживущие ветки в репозитории в моём случае это не необходимость, это лишь данность. Ветки есть просто потому что они есть и не удалены. Не удалены — потому что они никому не мешают
Нет, эти ветки исторические, они создаются в момент решения задачи, потом по завершению задачи мерджатся куда нужно и просто остаются в истории, без удаления (потому что зачем их удалять?)).

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

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

Итого — у вас 1 организационный инструмент и 1 технический, у меня — 1 технический, при том же результате.

> говорите что для нормальной работы на большом проекте нужно 1000 веток

Это исторические ветки, которые после решения задачи просто напросто не были удалены. Понимаете, проект живёт долго, потому фич было больше 1000. А бренчи удалены не были. И они никому не мешают, они где-то там вверху графа, и их никто даже не видит. Есть они не просят, для анализа графа и решения текущих задач не мешают. В чём проблема-то? :-)
>> Как то вы не так работаете с ветками

У вас свой опыт, у меня свой. У меня он работает. Прекращайте считать свой опыт единственно верным.

>> Ни каких ветвлений и срача в истории

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

Объём ветвлений зависит ТОЛЬКО от числа разрабатываемых фич. Вне зависимости от подхода граф будет ветвиться только по числу фич, и ваше решение даст ту же самую картинку, что и моё. Разве что вы удалите потом названия бренчей из графа, а я нет.

Вы с этим хоть согласны?
В комит не вместишь столько, сколько можно вместить в документе, который описывал фичу. Я не понимаю, почему вы принципиально хотите ограничить себя в объёме доступной информации.

Так или иначе, я здесь не для того, чтобы вас переубедить. Для вас работает один способ, для меня другой. Не убедил — окей.
Пара дней что-то решают? :-)

Ну серьёзно, за пару дней ещё не было ничего даже близко рабочего и отражающего суть будущего проекта. Не говоря уже о том, что они могли не знать о намерениях друг друга, или знать не всё.
> и чем более ветвистое это дерево тем сложнее с ним работать
Удаление имени бренча «проблему» с ветвистым DAG никуда не убирает. Просто из этого дерева пропадают метки (бренчи) напротив некоторых ченджсетов, а дерево остаётся тем же самым, с которым «сложно работать» :-)
Например, это позволит узнать цель тех или иных модификаций
А это проблема скорее организационная :-)

Они не мешают, потому особенно никого это не волнует.

> а ветки — это именно ветки с историей.

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

А если вспомнить, что ринадлежность ченджсета тому или иному бренчу в гите происходит в рантайме, то удаление бренча это скорее зло, чем добро. Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено (если только не оставлять это же имя в комментариях специально для этого)
фичабренчи, особенность проекта :-)

репозиторий на гите

> Но теги то понятно почему куча, это просто указатели.

Бренчи в гите это точно такие же указатели. Их единственное различие, что они с HEAD двигаются вместе.
А successful branching model запрещает в одной и той же ветке работать вдвоём разве?
Ну это субъективно.

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

ps: у меня нет никаких проблем, я просто попытался придумать хоть какое-нибудь применение mercurial phases (я об этом даже специально сказал, чтобы не подумали, что я и вправду их использую)))
Занятно :-) Логика в ваших словах есть, но на практике я просто ребейзю свои коммиты до тех пор, пока они не готовы, а потом по результатам сквашу, если нужно и пушу.
Мой вопрос был скорее о том, что вся реализация букмарков в меркуриале обязывает юзать -f при пуше, что чревато проблемами
> для каждой фичи всегда создается отдельная локальная ветка

Зачем? В чём смысл держать 2 фичабренча (общий и локальный)?
Я термин «локальная» ветка определяю как ветка, которая показывается в `git branch`, вне зависимости от того, есть у неё апстрим, или нет.

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

Для случаев, когда вы из локальной ветки не хотите что-то случайно запушить — есть phase secret.
Потому что даже у локальной ветки может быть апстрим из origin. И в неё все ченджсеты отправляются при пуше
image — вот так вот
Но её без форса не запушишь. А форс, это преступление против человечества :-)

Информация

В рейтинге
Не участвует
Откуда
Веллингтон, Wellington, Новая Зеландия
Зарегистрирован
Активность