[Devel] Репозитории проектов по АСУ

Evgeny Sinelnikov sin на etersoft.ru
Ср Июл 22 15:19:45 MSD 2009


17 июля 2009 г. 11:56 пользователь Larik Ishkulov (gentro на etersoft.ru) написал:
> 2009/7/17 Evgeny Sinelnikov <sin на etersoft.ru>
>>
>> Выглядит это так.
>> # клонируем
>> $ git clone git://git.etersoft.ru/projects/Project.git
>> # работаем, комитим, заливаем к себе
>> $ git push git.eter:public/Project.git master
>> # снова работаем, снова комитим, снова заливаем
>> $ git push git.eter:public/Project.git master
>> # В конце дня публикуем
>> $ ssh git.eter public Project public/Project master
>>
>>
>> --
>> Sin (Sinelnikov Evgeny)
>> _______________________________________________
>> devel mailing list
>> devel на lists.etersoft.ru
>> http://lists.etersoft.ru/mailman/listinfo/devel
>
> Я так понимаю имелось в виду не public а projects
> $ git push git.eter:projects/Project.git
>
> Зачем в данном случае личный публичный репозиторий?
> После команды public в него будут добавлятся коммиты из public/Project
> master, потом делаться rebase, потом потом делатся push в public/Project?
>

Дело в том, что вся эта свистопляска с rebase и единым репозиторием
противоречива подходу, принятому для распределённых систем контроля
версий. Аналогично и я могу спросить, а зачем единый репозиторий...
Адекватных ответов я слышал несколько:
1. Чтобы всегда "знать" где лежат "последние" исходники.
2. Чтобы не переспрашивать окружающих "кто главный", в случае
использования личных репозиториев, что особенно актуально при смене
ролей...

На деле, первое является следствием второго... Остальное - это попытка
"сделать из Git Subversion". То есть попытка применить порядок работы
(workflow), принятый для централизованных систем контроля версий
(далее ЦСКВ) в распределённой системе контроля версий (далее РСКВ).

В чём же разница?
Разница в том, что в ЦСКВ принят подход, при котором исходники
отчуждаются... У автора нет своего личного репозитория... Поэтому
каждый, начиная работу, готовится получить сюрприз, в виде чего-то
нового... А ответственность за получившийся результат размывается
коллективной безответсвенностью... В итоге, что же там получилось,
никому не известно... Точнее известно, но каждый раз тому, кто
последний коммитил, а поскольку проследить за этим невозможно by
design, то, по сути, это не известно...

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

Но... Роль лидера действительно может переходить от человека к
человеку...Так что итоговый репозиторий всё-таки полезен... Для его
автоматической поддержки в girar я и предложил сделать специальный
механизм, который будет отслеживать, чтобы коммиты были всегда fast
forward, делать rebase, если нужно, и т.д.

Кстати, для fast forward есть специальная настройка в git config:
       receive.denyNonFastForwards
           If set to true, git-receive-pack will deny a ref update
which is not a fast forward. Use this to prevent such an
           update via a push, even if that push is forced. This
configuration variable is set when initializing a shared
           repository.

В общем, я считаю, что подход с одним репозиторием как средство для
обмена исходниками в команде, которая активно ведёт проект,
безобразным. Мне это мешает. Я не хочу принимать решения за ту часть
проекта, про которую я ничего не знаю, если я выполняю только какую-то
её часть. И не хочу давать возможность что-то заливать всем подряд
если проект веду я.

-- 
Sin (Sinelnikov Evgeny)


Подробная информация о списке рассылки devel