mayton2019

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

И в целом это вопрос не про гит а про организацию процессов и риски.

Refactoring.

Если команда большая (больше чем скрам) то имеет смысл раз в неделю собираться на голосовом
митинге в полном составе и хотя-бы по 5 минут заслушать каждого. Кто чем болеет. Какие проблемы.
Какие разработки. Далее по результатам надо думать о создании общего репозиатрия кода.
Что-то вроде библиотеки. И сводить в библиотеку только реально нужное и разделяемое между
проектами. Библиотекой должны заниматься опытные. Она должна иметь структуру и документированность.
Она должна вбирать в себя только полезное. По принципу реального боевого кода. Код который
морально устарел или не используется лучше выбросить из библиотеки.

Нужно создать условия когда код из библиотеки не копируется а инклудится в проекты. Если кто-то
берет наброски и "дорабатывает" - надо смотреть что он доработал и почему.

По иному - вряд-ли получиться. Сниппеты и горизонтальная переброска кусков кода между верстальщиками
и разработчиками - это хаос. Кроме роста количества файлов и сниппетов - ничего полезного не будет.

Доступ к истории проекта закрывать нельзя. Это противоречит идеологии версионного контроля. В старых версиях кроме sensitive info могут быть знания по предметной области. Нам в разработке с одним банком очень помог анализ истории. По крайней мере мы поняли некоторые причины дефектов мультипоточки.

То что пароли и токены коммитились - это epic fail, но лучше их обновить чем поступать как тупо. Вы-же не хотите походить на пришельцев-бюрократов расы "вогонов" (из романа Дугласа Адамса) которые уничтожили планету Земля только потому что им надо было шоссе построить в космосе.

А попробуй сделай
$ git gc

Если это единый проект - то ему нужен один репозиатрий.

Вам надо в git складывать не бэкапы Sqlite а текстовое представление wiki по состоянию на сегодняшний день. Насколько я помню там есть
свой язык форматирования типа markup. Так что все будет норм.

На текущем проекте требуют, что бы под каждое, даже небольшое изменение, баг (заменить цвет уведомления) создавать отдельную ветку

Да. С точки зрения современных технологий управления исходным кодом - это нормально. Это выглядит бюрократично - но это защита, когда что-то пошло не так. Всегда можно без участия автора взять и откатить назад точечно именно то изменение которое привело к ошибкам за 1 день до релиза.

И сложно себе представить что нужно откатить если ты ушел в отпуск и в 1 мердж реквест положил штук 5 своих задач.

Вобщем не нужно боятся бюрократии. Нужно ее умело использовать и поворачивать эти техники так чтобы всей команде было комфорто и спокойно. И не нужно бояться за перформанс при выполеннии операций. Этот перформанс вообще не имеет значения с точки зрения ентерпрайза. Ты логаешь общее время разработки куда входит и работа с кодом и работа с репозитарием.

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

Вот
rsync .... --delete

Обычно сборщик обладает свойством генерации архе-типов. Например типичное Scala-akka приложение создается так.
$ sbt new akka/akka-quickstart-scala.g8

Вот вам надо создать такое. Сборщик там или просто генератор - не суть важно. Ваш шаблон - это архе-тип.