Нет, не равны. С родительской веткой работает вся команда, а с фиче-веткой — только ее часть. Потому изменения родительсткой ветки затронут большее кол-во людей и именно поэтому нужно иметь фиче-ветки как можно более готовыми к мерджу.
разве не все конфликты уйдут ровно с тем же уровнем проблем, что и при ребейзе?
Конфликты уйдут, но зато добавится +1 коммит (и он не будет пустым, как при обычном merge --no-fast-forward), а потом еще +1 коммит. Если у вас мастер достаточно часто меняется, то просто за время работы над фичей в пару дней у вас может накопиться солидный ком из таких коммитов, которые по своей сути являются мусором
Если вы работаете в более-менее взрослом проекте, то у вас уже как минимум будет две параллельные ветки: master и develop. А если еще и gitflow применяется, так вообще еще hotfix и release добавляется.
Но даже с маленькими ветками возникает проблема: что делать, если в мастере появился новый коммит? Если вы будете мерджить ветку в мастер с решением конфликтов на месте, то у вас появляется новый неоттестированный коммит и состояние мастера автоматически становится непредсказуемым, даже если на самом деле ничего страшного не произошло.
Неправильная позиция. merge нужен для вливания дочерней ветки в родительскую. Иначе получаем такой же бардак, только с другой стороны, потому что родительская ветка будет постоянно в состоянии diverged
Вот когда вы смерджите через пару недель самую нижнюю ветку в самую верхнюю, то я хочу посмотреть, как вы будете искать откуда взялся коммит из средней (коричневой) ветки, который заехал и туда и сюда. Плюс к этому коммит, заехавший в обе ветки с вероятностью 100% вызовет позднее конфликт, который вы будете решать на этапе позднего merge. Как показывает мой опыт как раз вот такие хаотические слияния вызывают наростающий ком конфликтов. При каждом merge при примерно полугоде разработки вы начинаете с конфликтов. При этом применяя rebase количество конфликтов сводится к минимуму, потому что сама суть rebase состоит в том, что вы приводите ветку к состоянию fast-forward, то есть ГАРАНТИРОВАННОМУ отсутствию конфликтов.
Это разные задачи. rebase нужен для приведения дочерней ветки в соответствие с родительской, а merge — для вливания изменений из дочерней ветки в родительскую. Разные отношения между ветками — вот и разные инструменты. Можно применять для всего merge, но тогда рано или поздно в более-менее активном проекте получаем merge hell
Если лейблы не дают зарабатывать, то пусть идут по пути Нетфликса и сами становятся лейблом. Ищи таланты, продюсируй и выставляй эксклюзивный контент. Тем более, что они уже пробовали двигаться в этом направлении и вроде как платили за написание музыки без слов.
А вот интересно, американский регулятор разрешил, а как же остальные? Есть же международные механизмы распределения орбит? Иначе Маск, условно говоря, забьет все нормальные орбиты своими спутниками и китайцам с европейцами места не останется.
Эх, а мне вот пришлось на Убунту съехать, чтобы нормально работать с докером. Работа через виртуалку неудобна до жути. Вот, все жду, когда Винда снизойдет до нативного Докера
Нет, не равны. С родительской веткой работает вся команда, а с фиче-веткой — только ее часть. Потому изменения родительсткой ветки затронут большее кол-во людей и именно поэтому нужно иметь фиче-ветки как можно более готовыми к мерджу.
Конфликты уйдут, но зато добавится +1 коммит (и он не будет пустым, как при обычном merge --no-fast-forward), а потом еще +1 коммит. Если у вас мастер достаточно часто меняется, то просто за время работы над фичей в пару дней у вас может накопиться солидный ком из таких коммитов, которые по своей сути являются мусором
Если вы работаете в более-менее взрослом проекте, то у вас уже как минимум будет две параллельные ветки: master и develop. А если еще и gitflow применяется, так вообще еще hotfix и release добавляется.
Но даже с маленькими ветками возникает проблема: что делать, если в мастере появился новый коммит? Если вы будете мерджить ветку в мастер с решением конфликтов на месте, то у вас появляется новый неоттестированный коммит и состояние мастера автоматически становится непредсказуемым, даже если на самом деле ничего страшного не произошло.
Неправильная позиция. merge нужен для вливания дочерней ветки в родительскую. Иначе получаем такой же бардак, только с другой стороны, потому что родительская ветка будет постоянно в состоянии diverged
Вот когда вы смерджите через пару недель самую нижнюю ветку в самую верхнюю, то я хочу посмотреть, как вы будете искать откуда взялся коммит из средней (коричневой) ветки, который заехал и туда и сюда. Плюс к этому коммит, заехавший в обе ветки с вероятностью 100% вызовет позднее конфликт, который вы будете решать на этапе позднего merge. Как показывает мой опыт как раз вот такие хаотические слияния вызывают наростающий ком конфликтов. При каждом merge при примерно полугоде разработки вы начинаете с конфликтов. При этом применяя rebase количество конфликтов сводится к минимуму, потому что сама суть rebase состоит в том, что вы приводите ветку к состоянию fast-forward, то есть ГАРАНТИРОВАННОМУ отсутствию конфликтов.
Это разные задачи. rebase нужен для приведения дочерней ветки в соответствие с родительской, а merge — для вливания изменений из дочерней ветки в родительскую. Разные отношения между ветками — вот и разные инструменты. Можно применять для всего merge, но тогда рано или поздно в более-менее активном проекте получаем merge hell
Он неюзабелен — нельзя достоверно ответить на вопрос "откуда это взялось" без пары часов изучения такого графа.
CircleCI попробуй. 1500 минут бесплатно и бомбовая интеграция с github
https://eslint.org/docs/rules/no-await-in-loop
https://eslint.org/docs/rules/no-await-in-loop
Единственный ноутбук на моей памяти, у которого сгорела мать — это HP. Но. понятное дело, это нерепрезентативна выборка и просто совпадение :)
Пусть ReactOS попробует
Люди еще смогут побороться с роботами путем киборгизации. Расширение физических возможностей + интеллект и креатив.
Наверное, первый случай в истории, когда женщина после 18-ти лет старалась выглядеть старше своих лет
Если лейблы не дают зарабатывать, то пусть идут по пути Нетфликса и сами становятся лейблом. Ищи таланты, продюсируй и выставляй эксклюзивный контент. Тем более, что они уже пробовали двигаться в этом направлении и вроде как платили за написание музыки без слов.
Не поверишь… Для самого Самсунга ;)
https://androidinsider.ru/analitika/samsung-priznala-porazhenie-ot-kitayskih-proizvoditeley.html
Эх, вот если бы ReactOS поддерживал бы Docker нативно — вот это была бы реально killer-фича перед обычной виндой
За один запуск можно же запускать по нескольку спутников
А вот интересно, американский регулятор разрешил, а как же остальные? Есть же международные механизмы распределения орбит? Иначе Маск, условно говоря, забьет все нормальные орбиты своими спутниками и китайцам с европейцами места не останется.
Эх, а мне вот пришлось на Убунту съехать, чтобы нормально работать с докером. Работа через виртуалку неудобна до жути. Вот, все жду, когда Винда снизойдет до нативного Докера