И побеждает... git

Что в общем закономерно и справедливо.

При рассмотрении популярности систем управления исходными текстами, разработчики, вне зависимости от типа используемой операционной системы, поставили на первое место Git (30.7% Windows, 65.4% Linux и 78.3% Mac OS X). При этом популярность Git за год заметно выросла. После Git работающие в Windows разработчики выбирают Subversion (23.9%), Mercurial (20.7%) и TFS (Microsoft Team Foundation Server, 20.6%). Работающие в Linux, кроме Git, активно используют Mercurial (15.4%) и Subversion (12.3%). При этом популярность Mercurial со временем падает (с 25% до 20.7%), а Subversion растет (рост с 8.8% до 12.3%). Доля пользователей Bazaar (3.7%) и TFS (0.6%) среди опрошенных незначительная.  

http://www.opennet.ru/opennews/art.shtml?num=31215

Про git на "Инструменты Agile"

Небольшая подборка выступлений по практическому использованию инструментов разработки в agile-командах (Yandex, Softline...) http://lib.custis.ru/Agile-tools-2010

И собственно цитата всего поста:

«GIT - инструмент для богов». «…После того, как мы убедились, что не все люди боги…»

Упрощенный обмен метками в git

Есть в git не очень, по меньшей мере пока, понятный и логичный момент - при пуше, созданные и измененные метки не отправляются на сервер. Из за чего, обмен изменениями с коллегами приходится проводить в 2 этапа:
сначала делать git push, а потом еще и git push --tags. И аналогично для pull/fetch

Но сие поведение можно задать в файле настроек, для каждого репозитария

Или выполнить для репозитория команды:

git config --add remote.origin.push +refs/tags/*:refs/tags/*
git config --add remote.origin.push +refs/heads/*
git config --add remote.origin.fetch +refs/tags/*:refs/tags/*

Риски использования распределенных систем управления версиями

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

Из недостатков, видевшихся мне перед нашим переходом на него основным была возможность организованного хаоса, когда все начнут пользоваться распределенностью и лезть другу другу в репозитарии. На практике все оказалось гораздо приятнее и безопаснее - работаем как и раньше, с центральным репозитарием, но "ветвимся" малой кровью и имеем всю историю локально, намного меньше завися от внешнего центрального репозитария, в периоды отсутствия связи.

Встретилось вот еще пара интересных статей на эту тему:

Риски распределенного контроля версий
Контроль версий и «правило 80 процентов»

Вкратце: с централизованной системой, людей принуждают взаимодействовать и просматривать работу друг друга; с децентрализованной системой, поведение по умолчанию состоит в скрытом ветвлении проекта каждым разработчиком.

Необходимо будет прилагать специальные усилия для обмена кода и самоорганизации в некоторую командную структуру.

Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение.

А поведение по-умолчанию — «ветвить», а не сотрудничать!

Это поощряет людей забираться в пещеры и кодить там объемные доработки, а затем «сбрасывать» эти «кодовые бомбы» на своих товарищей, причем до момента «сброса» код не может быть кем-либо проверен.

Да, правильные практики возможны с DVCS, но они не поощряются, что заставляет меня беспокоиться о будущем разработки с открытым исходным кодом...