верблюжий? Нет, мы не накладываем никаких ограничений на имена, за исключением того, что пробелы, как правило, не приветствуются. Главное - это содержание, а не презентация. Пока в названии четко определено, что оно делает, мы счастливы.
Я думаю, что самое большое изменение, которое вы можете сделать, это поместить все ваши проекты в один репозиторий на верхнем уровне.
Мы не используем каталоги веток или тегов, так как у нас много сотен проектов, каждый из которых разделен на группы версий (то есть у нас есть базовая платформа с версиями и множество плагинов, которые находятся под каждым номером базовой версии)
Например:
base v1
+--- moduleA
+----moduleB
base v2
+--- moduleA
+----moduleB
Мы думали о том, чтобы разместить ветку тегов под каждым из каталогов модулей, но мы почти всегда имеем дело с головной версией, поэтому для нас это не проблема. Мы регулярно объединяем изменения из более старых модулей базовой версии в новые - например, вносим изменения в модуль A для базы v1, изменения объединяются в модуль A базы v2. Мы не идем назад, если в этом нет необходимости.
Каждый модуль имеет примечание к выпуску, в котором описывается номер версии и изменения. В комментарии к журналу есть описание и номер версии. Это облегчает вывод предыдущих версий без необходимости иметь множество ветвей тегов с уникальными именами. Если бы мы начали использовать ветви тегов (это было предложено), то мы сделали бы полную копию пути в каталог / tags), мы все равно слились бы в одну ветку тегов и поместили комментарий в журнале, отмечающий номер выпуска, мы просто слишком много модулей, чтобы управлять ими как папкой с 1 тегом на ветку. И нет, мы никогда не вносим изменения в исторические изменения - если клиенту требуется новая функциональность, ему необходимо обновить его до последней версии (что никогда не будет проблемой, пока они не изменят версию базовой платформы)
Мы также не используем ветвления, так как мы склонны работать над головной версией каждого модуля, если нам нужен ветвь для основного набора изменений, мы будем ветвиться на базовом уровне, поэтому мы создадим ветка "base v2 - performance" и ветка всё. Это позволяет легко сгруппировать множество изменений, так как это лучше всего подходит для нас. Разветвление отдельных модулей может привести к слишком большому количеству помех в репо - поскольку у нас есть пара сотен, было бы легко потерять их, если бы у нас было разветвлений на модуль.
Да, мы вносим изменения в ствол, но это нормально для нашего рабочего процесса - вещи не фиксируются, пока они не готовы к работе. Все изменения, внесенные в более старые базовые версии, являются только исправлениями ошибок, и у нас слишком много модулей, чтобы управлять ими в полном цикле dev-test-release. Мы исправляем, если это окажется плохим исправлением, мы исправляем снова. Иногда мы меняем этот подход для более крупных разработок и создаем ветку в папке веток (вне корня). Путь ветвления воссоздает путь к исходному модулю (поэтому легко определить, какой он, а объединение обратно так же просто, как изменить / переходы на / trunk в начале пути).
Единственная проблема, с которой мы сталкиваемся в этой системе, - это когда мы помещаем модуль в проект веб-приложения (redmine). Мы хотели иметь один проект Redmine для всех версий модуля, но наша компоновка была такой, что стало немного трудно получить root-права на хранилище. Если бы мы могли связать путь репо с каждой версией в Redmine, то это ограничение исчезло бы.
Это не обязательно лучший вариант для всех, и я бы рекомендовал использовать больше веток, но это работает для нас (отчасти потому, что мы работали в предыдущей системе контроля версий, которая была "безопасной" и не поддерживала филиалы / слияние).