Социальные сети проводят хостинг проектов с открытым исходным кодом

Путеводитель по таким сайтам, как GitHub и BitBucket

Революционные потрясения, связанные с появлением социальных сетей, не обошли стороной мир разработки программного обеспечения. Появилось множество служб, поддерживающих совместную работу над проектами через Интернет, особенно в сфере разработки открытого программного обеспечения. Такие идеи, как распределенное управление версиями, управление версиями подпрограмм (routine forking) и запросы на извлечение (pull requests), привели к изменениям в основных процессах групповой разработки. Одна из самых популярных сетей для сотрудничества в сфере разработки программного обеспечения – сайт GitHub с его девизом "Социальное программирование". Эта статья посвящена развитию социальных сетей в контексте GitHub, но те же принципы применимы и к другим подобным сайтам, таким как BitBucket, и даже к внутренним системам организаций.

Учи Огбаджи, ведущий консультант, Fourthought Inc

Учи Огбаджи (Uche Ogbuji) – консультант и соучредитель Fourthought Inc.. компании, специализирующейся на продаже программного обеспечения и консалтинге в области XML-решений для менеджмента интелектуальный ресурсов предприятий. Fourthought разрабатывает 4Suite, платформу с открытым кодом для XML, RDF и приложений для управления интеллектуальными ресурсами. Мистер Огбаджи является также ведущим разработчиком языка запросов Versa RDF. Он – компьютерный инженер и писатель, родившийся в Нигерии; живет и работает в Болдере (Boulder), штат Колорадо, США. Вы можете найти больше информации о мистере Огбаджи, посетив его блог Copia.



27.06.2012

Обзор

Разработчики программного обеспечения ― одни из ранних пользователей социальных сетей, поэтому не удивительно, что возникают сети, специально предназначенные для сотрудничества разработчиков, особенно разработчиков открытого ПО. В мире открытого ПО давно существуют популярные службы хостинга проектов, наиболее известная из которых ― SourceForge. В течение длительного времени они строились в основном на принципах Web 1.0, которые несколько устарели, тогда как появилось множество разработок, революционизировавших способы сотрудничества в Интернете.

В основе большинства сайтов проектов ПО с открытым исходным кодом лежали централизованные системы управления исходным кодом (SCM), такие как CVS, а позднее ― Subversion. В то же время появилось новое поколение SCM - распределенные (или децентрализованные) системы управления версиями (или редакциями) (DVCS). Основная идея DVCS заключается в том, что вместо централизованного, канонического дерева исходного кода имеется система из множества рабочих копий. Это означает, что множество разработчиков могут совместно работать над проектом, даже если они подключаются к нему лишь эпизодически.

Взаимодействие между этими распределенными рабочими копиями напоминает общение членов социальных сетей. Поэтому сайты хостинга проектов естественным образом выросли вокруг идей DVCS с функциями социальных сетей в соответствии с моделью совместной работы над кодом. Сегодня в число самых популярных систем входят Mercurial, Git и Bazaar, каждая из которых предлагает тесно сопряженную, хорошо известную службу, соответственно BitBucket, GitHub и Launchpad.

В этой статье рассматриваются сайты хостинга проектов, основанные на функциях социальных сетей и DVCS, с акцентом на GitHub. Читатель должен иметь некоторое представление о системах управления версиями, но знакомство с DVCS не обязательно.

Основы сотрудничества через DVCS

При использовании DVCS для совместной работы новый пользователь, пусть это будет Алиса, создает хранилище кода, а затем предоставляет доступ к нему своим коллегам ― пусть первым из них будет Боб. Алиса может предоставить доступ и другим пользователям той же машины или же передавать данные на сменном носителе или по сети. Боб копирует ее хранилище кода с помощью совместимой DVCS-программы и получает собственное хранилище, основанное на коде Алисы. Вначале в хранилище Боба находится то же, что и у Алисы, но у него свой собственный идентификатор и жизненный цикл. Это основное отличие DVCS от централизованного хранилища.

Клонирование хранилища, по сути, означает ветвление проекта, так как у нового хранилища отдельный идентификатор и свой жизненного цикл. Раньше ветвление программных проектов воспринималось негативно, отчасти из-за известных примеров ветвления, приводившего к разрыву между участниками проекта. Одним из таких примеров служит раскола проекта Emacs, почтенного и почитаемого текстового редактора с полезной системой утилит для программиста. От него откололся проект XEmacs, руководимый недовольными бывшими разработчиками Emacs. DVCS устраняет социальный контекст ветвления, делая его неотъемлемой частью процесса сотрудничества. Конечно, если Алиса и Боб решат идти разными путями, они в определенный момент могут разойтись, но также вероятно, что они будут склонны использовать ветвление как естественную часть своего сотрудничества.

Сигнализация об изменениях

В частности, Алиса и Боб могут внести какие-то изменения в свои хранилища; возможно Боб работает над пользовательским интерфейсом, а Алиса ― над внутренней логикой программы. В определенный момент они захотят объединить плоды своего труда. В своих персональных хранилищах они накопили отдельные наборы изменений. Набор изменений (changeset) ― это обновленные файлы, зарегистрированные посредством команды DVCS commit.

В централизованной версии системы управления наборы изменений поступают в основное хранилище и обозначаются следующим номером версии. Первая регистрация, выполненная Бобом, могла бы иметь версию 1.1, вторая – версию 1.2 и т.д. В случае DVCS это не имеет смысла, так как центрального хранилища нет, и никакого глобально управления порядком внесения изменений тоже нет, вместо этого каждому набору изменений присваивается хэш, уникальный в пределах всех хранилищ. На рисунке 1 иллюстрируется процесс первоначального клонирования и создания Алисой и Бобом отдельных наборов изменений. Звездами отмечены точки, в которых хранилища Боба и Алисы имели одинаковое состояние (когда Боб клонировал исходную копию кода Алисы.)

Рисунок 1. Первоначальный обмен в DVCS
Первоначальный обмен в DVCS

Когда Алиса и Боб захотят объединить свою работу, они сделают это путем обмена наборами изменений и урегулирования любых конфликтов, пока ни придут к новому хранилищу, содержащему их общую согласованную работу. Чтобы инициировать этот процесс, Боб может извлечь (pull) изменения из хранилища кода Алисы, или наоборот. Как именно это произойдет, не имеет значения и зависит исключительно от обстоятельств их сотрудничества. Вполне возможно, что направление обмена кодом между Алисой и Бобом будет чередоваться или меняться произвольно.

Механика слияния

Когда Боб получает изменения от Алисы, DVCS последовательно вносит каждое из них в его локальную версию кода. Вполне возможно, что изменения приведут к конфликту ― если Алиса и Боб внесли изменения в одну и ту же строку кода, или если Боб обновил файл, который Алиса исключила из своего хранилища. В случае конфликта DVCS может интеллектуально выполнить автоматическое слияние или потребовать вмешательства Боба.

Затем Боб, получивший набор изменений от Алисы, может вернуть ей объединенные результаты. DVCS обработает изменения относительно последней точки слияния и определит, что некоторые изменения, внесенные Алисой, уже присутствуют в хранилище кода Боба. Уникальные хеши ― это ключи, позволяющие идентифицировать наборы изменений в ходе этого процесса. После передачи изменений Алисе у них с Бобом будут одни и те же данные. Процесс передачи/слияния/возврата иллюстрирует рисунок 2. Обратите внимание, что он приводит к новому единому состоянию хранилищ Алисы и Боба.

Рисунок 2. Слияние наборов изменений с помощью DVCS
Слияние наборов изменений с помощью DVCS

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

Предположим, что в ходе описанного выше процесса Боб забыл взять изменения у Алисы, прежде чем отправить в ее хранилище свои. В этом случае ПО DVCS заметит, что Боб внес свои изменения уже после последней точки объединения с хранилищем Алисы. Один из основных принципов DVCS заключается в том, что набор изменений применяется только к известному начальному состоянию хранилища, называемому "общим родителем" (common parent). Так как наборы изменений Боба имеют своей отправной точкой общего родителя - момент первого клонирования кода Алисы, DVCS, применяя наборы изменений, фактически возвращается к этому состоянию. Это приведет к тому, что изменения, внесенные Алисой с момента регистрации общего родителя окажутся в отдельной ветке, которая обычно не совпадает ни с тем, чего хочет Боб, ни с тем, чего хочет Алиса. В данном случае DVCS, как правило, выдает предупреждение о том, что операция обмена приводит к созданию "многоголовки" (multiple heads). Боб может отменить передачу и получить от Алисы набор ее изменений из той же ветви, в какой находится он. Результатом будет единая ветвь, содержащая наборы изменений Боба и Алисы относительно общего родителя. В этом состоянии Боб может передать изменения Алисе, не создавая проблемы многоголовки.


Социальные последствия основных взаимодействий DVCS

DVCS обеспечивает большую гибкость, но проекты должны накладывать на ее базовое использование некоторые более широкие рабочие процессы, особенно когда вовлекается все больше и больше людей с различными ролями и уровнями взаимодействия. Как правило, имеется общепризнанное хранилище, которое начинает приобретать некоторые черты прежнего централизованного хранилища, но лишь отчасти. Ветвление происходит легко и естественно, и у тех, кто заинтересован в проекте, регулярно появляются многочисленные хранилища, и лишь соглашение позволяет участникам избежать хаоса. Это особенно характерно для проектов разработки ПО с открытым исходным кодом, где каждому разрешено клонировать или извлекать код из основного хранилища. Руководитель или руководители проекта определяют свое основное хранилище и дают доверенным участникам проекта разрешение на внесение изменений.

Запрос на извлечение

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

Благодаря характеру DVCS и тщательному управлению наборами изменений появляется возможность немного улучшить этот процесс. В частности, при старой системе внесения исправлений история конкретных изменений, которые привели к созданию исправленной версии, часто терялась. В DVCS участник проекта может извлечь код из основного хранилища, внести изменения в своем рабочем хранилище, выполнив все обычные процедуры, а затем представить результирующие наборы изменений на рассмотрение и обсуждение. Этот процесс называется запросом на извлечение (pull request). По существу, участник просит, чтобы основной разработчик извлек из его рабочего хранилища предлагаемые изменения и после обсуждения уточнил их и внес в основное хранилище.

В таких системах, как GitHub, функция запроса на извлечение (см. раздел Ресурсы) оформлена как удобный интерфейс рабочего процесса "выдвижения" хранилища, чтобы инициировать запрос на извлечение, обсуждение предлагаемых изменений и последующее внесения результирующего набора изменений в целевое хранилище.

Популярность и последователи

Никакая социальная сеть не будет полной без системы, позволяющей людям следовать за другими, и вызванного этим конкурса популярности. Основные DVCS-сайты не являются исключением. Вы можете следовать за разработчиком или проектом, если найдете его интересным, и разработчик будет уведомлен об этом факте и может решить, стоит ли ему следовать за вами. Терминология может варьироваться: в GitHub, например, за человеком "следуют", а за проектом "наблюдают", но идея та же, что и в Twitter или Facebook, с аналогичной социальной динамикой. Впечатление, производимое разработчиком или состоянием проекта, измеряется числом последователей и может играть определенную роль в социальной динамике, которая накладывается на DVCS, например, влияя на то, какое направление "выиграет" в ожесточенных спорах вокруг ветвления версий.


Заключение

Программного обеспечения с открытым исходным кодом становится все больше, и оно стало огромной частью глобальной картины информационных технологий. Этот рост стал результатом не только напряженной работы, но и творчества ярких личностей и информационно-пропагандистской деятельности. Хотелось бы сказать, что в социальных сетях, стремящихся воплотить процесс сотрудничества в области разработки открытого ПО, главенствующую роль играет это ПО, а все остальное вторично. Увы, из социальной сети нельзя исключить социальный аспект. Те, кто, следуя своей потребности в самовыражении, участвовал в таких сайтах, как GitHub – в качестве пользователя, участника проекта или руководителя своего собственного проекта, ― знают, что важно понимать не только базовый рабочий процесс, но и социальный подтекст, неразрывно связанный с обменом битами.

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

Ресурсы

Научиться

Получить продукты и технологии

  • GitHub - популярный сайт хостинга проектов, где хранилищами кода управляют с помощью DVCS Git.
  • BitBucket - сайт хостинга проектов, тесно связанный с DVCS Mercurial, но поддерживающий и Git.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=823173
ArticleTitle=Социальные сети проводят хостинг проектов с открытым исходным кодом
publish-date=06272012