> я пытаюсь выработать общую стратегию поведения, которую мне нужно будет донести другим разработчикам, и такой вариант даже озвучивать нельзя.Оглядываясь назад на свой опыт освоения git, я бы рекомендовал забить для начала на стратегию, и заняться тактикой, то есть начать с того, что начать использовать git в каком-нибудь side-проекте, который делается чисто по фану, причём посредством создания ветки work и коммитов туда всего подряд в естественном беспорядке этих изменений. По мере выполнения каких-то задач, надо брать ветку work и разгребать её (создавая временные ветки, раскидывая коммиты по ним, после чего сливая эти ветки в master), создавая красивую историю решения этих задач и скидывать эту историю в master, оставляя в work только изменения связанные с незаконченными задачами. Причём делать всё это ограничивая себя командами add, commit, checkout, reset, branch и rebase. Тут я могу посоветовать: https://github.com/salemove/gojo там есть задачки на разгребание бардака в репе и приведение его в няшный вид. (В инете есть и другие задачники, в том числе и интерактивные в браузере, просто я ссылок не вижу у себя в закладках, но если поискать в гугле можно найти, я уверен.) Надо довести свои навыки в "тактике" использования git до уровня, когда ты эти задачки будешь решать не задумываясь, и может быть разок на задачу консультируясь с man'ом, чтобы понять с какими опциями надо вызывать, например, git-reset, чтобы получить именно такой reset, который нужен.
Такой подход гарантирует, что ты довольно быстро поймёшь зачем нужны ветки с коммитами, как с ними надо обходиться, и более того доведёшь всё это до автоматизма. Со временем ты подстроишь этот процесс под себя -- будешь в процессе написания кода и commit'ов его в локальную ветку лучше делить изменения кода на коммиты; научишься использовать commit --amend, чтобы сразу склеить коммиты, которые потом всё равно склеивать придётся; использовать commit --patch, чтобы разбить какие-то изменения на разные коммиты сразу, а не задним числом при помощи rebase; сразу создавать ветки изменений, чтобы не задним числом при помощи rebase отделять одно от другого; писать комментарии к коммитам, которые помогают разгребать бардак -- но это всё будет выглядеть как оптимизации workflow, с тем чтобы потом было бы проще разгребать.
После этого надо отправляться в гугл с запросом "git workflow" искать описание того, как с git огранизовывают проекты. То есть, к этому моменту у тебя уже будет создан какой-то workflow, он самоорганизуется, пока ты будешь приспосабливаться к git, приспосабливая его к себе. Но возможны разные способы организации работы с git: git это инструмент для жонглирования коммитами, не более того, как лучше ими жонглировать, сколько веток иметь непрерывных, иметь ли вообще какие-либо непрерывные ветки кроме master (может всякие testing удобнее форкать по мере надобности, и потом просто удалять их?) -- это уже как тебе удобнее. И вот тут лучше чужой опыт пособирать, чем самостоятельно пробовать все разные способы. И собирать этот опыт лучше после освоения тактики, потому что в этом случае тебе будешь гораздо легче понимать, о чём говорит автор.
ps. Насчёт холиваров о rebase/merge, я бы не рекомендовал на этом этапе обращать на них внимание. Эти холивары можно почитать потом, когда ты поймёшь основные workflow, с тем чтобы понять, когда не надо использовать rebase. Зачем же rebase надо использовать, можно почитать/посмотреть здесь: https://mtyurt.net/post/git-using-advanced-rebase-features-f...
