может, но заметят сразу, а не к концу.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
TBD, стоит ли заморачиваться
- Автор темы WMix
- Дата начала
Нормально все, если не сидеть в своей ветке годами. Ребейзишься на мастер/девелоп регулярно и все окей.
Если уж возникла такая ситуация, когда две длинные ветки у двоих, то договариваемся, кто в кого ребейзится, ну или промежуточную ветку делаем и такой вложенный git flow получается на двоих. Но это исключительная ситуация, я такое припоминаю всего 1 раз.
Опять же не понимаю, что мешает одновременно с этим использовать feature toggles. Там, где это надо и можно безболезненно сделать, без фанатизма.
А у гугла такие объемы кода, что вряд ли у кого-то тут есть опыт работы с такими огромными codebases, и вряд ли мы себе представляем их проблемы.
чем больше я думаю о тбд тем больше склоняюсь к мысле что ветвление совершенно глупое занятие, "сами себе лишнюю работу делаем".
я не вижу плюсов в этой моделе, вижу одни минусы.
я не вижу плюсов в этой моделе, вижу одни минусы.
неделя тоже достаточно большой срок, а проект может и 3 недельки длится.
feature toggles это как раз решение которое делает "ветку" в коде. спрашивается, зачем еще ветка в cvs?
Не надо смешивать выключатели для фич и стиль ветвления. Выключатели это своя специфика, т.к. изолирование фич зачастую требует серьёзных накладных расходов и дублирования кодовой базы. Твой код со старым пересекается только в одном месте, конфликтов быть не может при любом раскладе. Это как иммутаельность на сложных структурах
А по поводу бранчевания - ты не дурак, если думаешь что в рамках твоего проекта и твоей команды какой-то способ лучше, значит тебе виднее. Я при TBD всё равно буду локально плодить ветки и вливать в транк фичу только по готовности. Здесь главное чтобы не было тупого правила об обязательном пуше в конце рабочего дня.
А по поводу бранчевания - ты не дурак, если думаешь что в рамках твоего проекта и твоей команды какой-то способ лучше, значит тебе виднее. Я при TBD всё равно буду локально плодить ветки и вливать в транк фичу только по готовности. Здесь главное чтобы не было тупого правила об обязательном пуше в конце рабочего дня.
Вурдалак
Продвинутый новичок
Ветка позволяет сделать чистое атомарное внедрение фичи. Меньше кода, меньше вероятности ошибиться. Разве это не очевидно?
Ну, я ж сказал - минимум раз в день ребейз.
С трехнедельным проектом даже ftp и "вася, не трогай index.php" сработает. То гугл, то проект на три недели
Вурдалак
Продвинутый новичок
Я вот когда на коленке скрипт пишу, это оказывается называется trunk based development или даже repository-less based development.
гугл статистика, 15000 работников 5500 коммитов в день, итого -- раз в три дня коммит на разработчика
вот это и пытаюсь понять, как не наговнять, ну те если место знаешь 3 строчки кода и с этого нужно начинать по идеи а дальше чую не попробуешь не осознаешь. выковыривать не хочется. поглядеть бы как делают. ну а так сознание что взад вперед перемержить всегда можно немного успокаивает
Я абсолютно уверен, что напрямую в мастере мало кто работает. Свою веточку же не обязательно пушить.
Я, например, сталкивался с ситуацией, когда в проекте (в который я был нанят ненадолго) использовался svn с транком на всё. Ну и ладно, пусть живут как хотят, а у меня же есть git-svn.
Я, например, сталкивался с ситуацией, когда в проекте (в который я был нанят ненадолго) использовался svn с транком на всё. Ну и ладно, пусть живут как хотят, а у меня же есть git-svn.
убедили, забрать возможность ветвления это глупо, но "долго живущая" ветка без слияния с trunk это тоже не правильно, тбд это о том
те просто дополнительный уровень, который не отменяет, а дополняет предыдущие
почему без слияния? в фичеранчи при активной разработке весьма желательно подтягивать изменения после каждого обновления в develop. Вместо тоо чтобы постоянно гадить в транк, ты безопасно вливаешь транк к себе и держишь ветку в актуальном состоянии.
Хаха! Не, у них вообще веток в свне не было. У меня в гите были, да, но этого никто не видел.
Я, правда, слышал краем уха, что щас в svn-е с merge-ами лучше стало. Но попробовать не на чем, да и желанием не горю.
мне кажется они называют процесс вылавливания правильных коммитов из "загаженого" транка - cherry-picking, хотя лучшей аллегорией будет - кофейные зерна лювак выковыривать
это и есть дистанция. (твои изменения никто не увидит) или нужно настраивать каждую ветку на деплой.. уверен, есть несколько людей которым каждый коммит интересен
Не. Ты свою ветку обновляешь через rebase, имеешь всегда свежий работающий код. А кода ветка готова, то собираешь коммиты в один и льёшь в транк и получается там работающий код и задача не раскидана по 100500 коммитах и любой кто через пару лет захочет узнать blam -ом для чего писалась строчка кода, сможет посмотреть и весь контекст.
я и говорю, но это нужно делать чаще
собрать воединое уже в этом случае не получается, да (если только по комментарию), но смысл не в этом а в continuous delivery
Ну вон в баду по ветке на каждый тикет, и 2 релиза в день делают.