Допустим, Федя пишет фронт, но у него падает запрос. Она пишет Борису, который делает бэк. Он говорит, что, кажется, знает, в чём проблема и может сейчас пофиксить. Он быстро фиксит и пушит в свою ветку и просит Федю чекнуть, работает ли с фиксом. Федя, в репозитории Бориса, переключается на ветку с фиксом и проверяет. Если считать, что Борис никогда не ошибается, то твоя схема работает. Но, если он ошибается (что свойственно людям), то у вас либо будет куча коммитов вида "try to fix error", либо вы постоянно откатываетесь после ребейзов/мёржей. Этот флоу без костылей работает только в случае с отдельными репами на каждое приложение.

А как бы это было с мультирепами? Борис бы не пушил коммиты "try to fix error", а амендил бы последний коммит, или что?

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

Борис не может проверить, что его API корректно работает? Единственное, где я вижу try to fix - это когда CI ломается(и то есть решения, чтобы не пушить для проверки). Если такое нужно для функциональности - возможно у вас что-то не то с тестированием.

Коммиты можно аммендить и старые

Они не сложны. Они являются лишним шагом.

В мультирепах всё работает точно так же. Только вместо git rebase feature_for_component1 ты делаешь cd component1 git co feature git pull

Да. И это более простая операция.

Чем она простая-то?

Тем, что, например, не требует стейджить свои изменения перед ребейзом.

Ну, для чекаута с пуллом тебе хотя бы думать вообще не надо, что ты делаешь.

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

Когда ты ребейзнул плохой код? Подождать пока в ветке появится новый код и снова ребейзнуть, лол)

Сомнительный поинт. Для git stash и git rebase я тоже не особо думаю

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

Какой конфликт? Тут же нет конфликтов, потому что ты пилишь один компонент, а ребейзишь из другого

Ага. Только у тебя два коммита, которые меняют потенциально одно и тоже — от Бориса.

Так они же последовательные. Первый и второй

Если Борис амендит и форспушит фиксы, ему нужно просто обоссать ебло рассказать что так делать неправильно, как минимум потому что это ломает всех кто он него бранчуется или его чекаутит (даже чтобы просто код прочитать)

Так ветка-то чисто его.

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

Пока ты сам пилишь в своей ветке, нет ничего плохого в том, чтобы амендить и фиксапить.

И та фича, которая делается межкомпонента это точно не его ветка

Зачем амендить для фиксов, расскажи?

Зачем амендить для фиксов, расскажи?

Чтобы запушить один коммит с фиксом вместо десятка попыток, например.

Зачем амендить для фиксов, расскажи?

И захочет потом 3 опечатки свои заребейзить в один коммит.

А что плохого в нескольких коммитах-то?

А что плохого в нескольких коммитах-то?

В том что большинство производят кучу муссорных коммитов по которым бесполезно хоть что-то востанавливать

Окей, сквошьте коммиты при мердже/ребейзе в транк. Амендить-то зачем?

А тут мы упираемся в конфликты, если кто-то отпочковался от твоей ветки по пути.

Потому что Борис у Андрея не способен сделать сразу фикс нормальный и будет делать try to fix bug X first attemp try to fix bug X second attemp try to fix bug X third attemp try to fix bug X fourth attemp

А что плохого в нескольких коммитах-то?

Так делать нельзя, это же гитопс

Не понял, о чём ты.

Если у тебя 20 коммитов будут такими: fix test fix typo fix blabla Ты потом ни в жизни не разберёшь - откуда пришёл баг, всякими bisect-ами не воспользуешься. Но ты всё правильно сказал, Борис - не умеющий протестировать свой фикс - ещё более глубокая проблема.

Никто же не будет бранчеваться от ветки, которая в разработке

По сути мультирепа - это защита от ленивости и криворукости Борисов. В этом получается смысл.

Хз насчёт ребейза, но вот размеры монореп (обычно весьма немаленькие) приводят к появлению ряда проблем, которых нет в мультирепах или они стоят менее остро. 1. Клонирование жирных монореп может занимать годы. Из-за этого приходится изобретать в CI флаги с разными способами клонирования, чтобы они занимали хоть какое-то разумное время. 2. Нужно придумывать разный набор тестов, который запускается на MR и перед релизом, потому что каждый раз запускать все тесты становится очень накладно. 3. Да и в целом становится сложнее отследить изменения в CI, все эти only: и changed: обычно рассчитаны на изменения только в одном последнем коммите, а если их несколько, то приходится изобретать велосипеды, определяющие правки в твоей текущей ветке относительно основной. И эти велосипеды ещё нужно делать устойчивыми к постоянным ребейзам. 4. В сложной структуре банально сложнее разбираться, дольше вкатываются новички, сложнее запускать часть проекта, если он понадобился отдельно от всего остального. Например, для тестов одного сервиса нужно поднять не мок, а другой сервис, а его сломали в недавнем MR, и вместо основной задачи копаешься с этим багом Не то, чтобы это было специфично только для монорепы, и для отдельных тоже бывает актуально, но как-то заметно реже

А если она условно готовая, но потом в неё вносятся дополнительные изменения?

Окей, ребейзи и оставляй оригинал)

Или не ребейзи, а просто мерджи, лол. Если там и правда сквошнутый коммит, то конфлитов там не будет

Обоснуй, чем этот подход плох?

Будет. Ты же на мёрже сквошишь.

Мультирепа объективно упрощает внесение мультикомпонентных изменений. А проблемы, которые ты описываешь решаются простыми договорённостями и культурой разработки.

Ты вообще ничего не написал про этот кейс сейчас, ты это понимаешь?)

Как он будет если оригинал и новая версия не конфликтуют?

С чего они не конфликтуют? Ты сделал ветку, добавил в неё коммит A. Потом кто-то от неё отпочковался и добавил коммит B. Потом ты в первую ветку добавил коммит C. Ты смёржил (со сквошем) ветку с A и C. Теперь тебе надо решать конфликты в ветке с B.

Тебе нужно изменить в компоненте X, Y, С сделать связное изменение. Если оно у тебя раскидано по репам X, Y, C - у тебя будет 3 ветки в 3 разных репозиториях, которые нужно синхронизировать - вместе тестировать. В случае монорепы - у тебя будет одна ветка, где можно сразу всё протестировать и разово замёрджить.

Если коммит B конфликтует с A или C, то нужно. Если нет, то в случае с мерджем не нужно

Конфликт B не конфликтует ни с A, ни с C. Но вот у B родителем является A, который засквошился с C (допустим, получился коммит D). Теперь тебе надо, чтобы у B родителем стал D. И D конфликтует с A, этот конфликт тебе надо пофиксить.

Я вообще не понимаю чем так конфликты не нравятся. Это хорошо что нужно их решать, это хорошо что они вообще есть Если бы их не было, то было бы ультрадушно, пришлось бы сидеть и сверять версии в мультирепах

Мне не нужно чтобы у B родителем стал D. Мне нужно чтобы после D добавился E (который мердж коммит)

Вы просто начали тут доказывать, что у монореп их нет, и они вообще всё проще делают.

Я разобрал отдельный кейс, где монорепа неудобна. Ты только написал про то, что Борис просто ленивый, ничего не написав, почему это плохо. Конкретно этот способ иногда позволяет закрыть проблему куда быстрее.