Линейная история. История всегда линейна, никаких циклов в этом графе нет. При разработке ветки с новой фичей периодически делается rebase на main (или на test, если у вас отдельная ветка для разработки), ну или хотя бы перед тем, как отдать фичу на code review или слияние.
Большой плюс в том, что когда смотришь на историю main, то всё очень просто и понятно. Также удобно смотреть pull request-ы по коммитам.
У этого подхода я вижу два минуса:
1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос. Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).
2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
Спагетти. Каждое изменение вносится в исходную ветку через merge. При визуализации разобраться в этом решительно невозможно.
Плюсы/минусы аналогичны минусам/плюсам выше.
Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
