Comments 25
Так а как работают github flow и gitlab flow?
Кину ссылку, как напишу статью
Про GitHub Flow просто написано здесь. Про GitLab Flow здесь (не понял зачем они это придумали, наверное затем же, зачем MR вместо PR, не использовать же GitHub Flow в GitLab).
Но MR звучит логичнее, чем PR.
MR указывает на определенную "оперативную" цель прямо сейчас — это запрос на слияние с основной веткой. PR указывает на другую "оперативную" цель — запрос на ревью, где под pull request изначально имеется ввиду "просьба" скачать эту ветку, чтобы провести ее ревью (выполнить git pull), с той же конечной целью — слияние с основной, если все ок. Это не я придумал. Так вот здесь никакой вариант не является более логичным, каждый просто отражает определенный подход к работе с изменениями, ну, или взгляд на такой подход. И в этом свете MR звучит как: "А давайте "вольем" мои изменения прямо сейчас", опуская процесс ревью. Может это для кого-то и является более логичным) Хотя я, конечно, не серьезно. Процессы здесь ни при чем, живите как хотите.
Вот пруф, из него это вытекает про PR. GitLab говорит про то же самое, но название другое. Здесь все проще — GitLab конкурент GitHub, они просто не могли использовать название GitHub flow в своей системе, как и другие термины (хотя почему?), пришлось придумывать свое. И вам они в этом никогда не признаются, хотя как раз конкурентная среда и ассоциации терминов с конкурирующим продуктом являются наиболее логичными причинами. Попытка обосновать эту логичность их терминов другими причинами не имеет смысла.
Это не пруф, а обычное описание функционала. Даже более того - в конце описания стоит именно слово merge, и это основная функция этого действия.
Все эти "просьбы посмотреть" есть у обоих конкурентов. Если это бы была основная функция, то это бы называлось review request. Ибо я нет смысла делать pull без review, но зато можно сделать review (и merge) без pull.
Ибо я нет смысла делать pull без review, но зато можно сделать review (и merge) без pull.
Тут есть различие в понимании, когда вся команда работает с неким центральным репозитарием и когда каждый разработчики работает со своим.
pull request - это в общем случае "скопируй ветку из моего репозитария в свой". Для каких-то там целей. И его, в принципе, может иметь смысл делать без review. Потому что review занимался как раз тот человек, что его тебе кидает. "Я тут с этой веткой закончил, теперь твоя очередь влить это в основную ветку". Или еще раз проревьювить. Или заняться тестированием. Или документацию написать.
Я и не называл ревью основной функцией, это лишь акцент на подходе к совместной работе, чтобы там коллега после git pull ни делал. Так что пусть каждый останется при своем мнении. Однако основная мысль в том, что они просто не хотели оставлять название, которое ассоциируется с GitHub, все намного проще.
master-a то давно нет...
А так полезная информация
Кому надо - у того есть :)
Я тоже держался сколько мог, но потом сдался
git config --global init.defaultBranch masterА зачем ещё что-то мочь и за что-то держаться?
Делаешь новый репозиторий (довольно часто) - получаешь main
Надо или переименовывать (лишние движения) или будет половина реп master, половина - main
Путаешься при документировании или переписке
Делаешь
git config --global init.defaultBranch masterЗатем произносишь сим-салабим и обязательно дунуть. Ведь если не дунуть, то чудо не произойдёт.
А если создаёшь не локально, то на всяких гитхабах в https://github.com/settings/repositories есть опция
Один раз можно и настроить окружение
Первая статья, спасибо уважаемый)
Вот я человек который не знает что такое Trunk-Based Development... это же статья для таких как я? И я ничего не понял... Что за фиччатогглы, это просто ветки или какие-то специальные штуки? Как ими чего-то отключать и подключать? Где сравнение, плюсы/минусы по сравнению с git flow? Вообщем тема не раскрыта... Пойду искать в других источниках... эх...
Скажем так, если вы не знаете зачем все это нужно - значит у вас нет проблем, которые решают различные флоу. Возможно, вы интуитивно выбрали один из подходов, и даже сами об этом не догадываетесь.
Про тонкие подробности даже сами создатели плохо пишут. Скажем, для чего в git flow вообще существует ветка master? В нее есть мержи, на ней есть теги.. Но что мешает оставить только теги вида release/x.y.z, ветвится прямо от них при необходимости, а весь master просто выкинуть? Что при этом сломается?
Ничего не мешает. Общепринятые конвенции нужны для простоты онбординга новых разработчиков. Гораздо проще пояснить, что "используем Trunk-Based c Feature Toggles", и дать ссылки, чем пытаться придумать собственный подход и правильно его задокументировать.
Я не предлагаю вам просто использовать метод A или B, и не задавать вопросов. Наоборот, ищите тот флоу который больше подходит вашей команде.
master | main - не священная корова. Мы используем Trunk Based в рутинном режиме разработки, и переключаемся на Git Flow, когда работаем над разными версиями пакета одновременно.
У меня есть проблема в старющем репозитории SVN, который толком даже не работает и не позволяет развиваться в техническом плане и в плане процессов разработки. Немного пораскинув мозгами родилась идея развернуть какой-нибудь gitlab и настроить там процессы, так сказать воспользоваться лучшими практиками. И вот теперь я узнаю что git-flow уже не модно и у меня возникает вопрос, может тогда сразу выстраивать что-то другое? Т.о. я получил новые вопросы, но не получил ответов на них.
Может кто то сталкивался с проблемой когда в гитлаб ветка не удаляется через delete?
Куча веток "призраков", я насколько понимаб окружение было удалено и они зависли
Порыскал по инету но не нашел проблему похожую
В этой статье мы рассмотрим некоторые из наиболее популярных методов, такие как Git Flow, Trunk-Based Development (TBD), на их основе базируются остальные:
GitHub Flow
С чего вы вообще это взяли? GitHub Flow — это отдельный подход, который был отдельно придуман вместо, а не на основе git-flow. Впервые об этом написал разработчик GitHub, описывая процесс, который они использовали (и используют до сих пор) в разработке — уже 12 лет подряд. И появился этот подход всего на ~1 год позже появления git-flow.
Теоретически может существовать бесконечное число (не обязательно эффективных) подходов к использованию Git, но именно GitHub Flow стал наиболее популярен благодаря своей простоте и способности обеспечивать непрерывную доставку.
Нужно глубже вникать, чтобы не нести заблуждения дальше.
Фундаментальные подходы при работе с Git