Взаимодействие с людьми

merging myfile

0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit)

$ hg commit -m 'Bring in bugfix from stable branch' $ cat myfile

This is a fix to a boring feature. This is exciting and new!

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

6.2.6. Ветви для новых функций

Для больших проектов эффективным способом управлять изменениями будет разбиение команды на несколько меньших групп. Каждая из которых будет использовать свою собственную ветку клонированную из единой «главной» ветки, используемой для всего проекта. Люди работающие над отдельными ветками обычно хорошо изолированны от изменений в других ветках.

Рисунок 6.1. Ветви для новых функций

Когда отдельная функция приобретает удобоваримую форму, кто-то из команды, работавшей над данной функцией затягивает изменения из главной ветки в ветку функции и выполняет слияние, а затем заливает изменения назад в главную ветку.

6.2.7. Релиз по расписанию

Некоторые проекты организованы по принципу «поезда»: выпуск новой версии планируется каждые несколько месяцев, и все функции, которые завершены к «отправлению поезда», включаются в релиз.

Эта модель имеет много общего с моделью «ветви для новых функций». Отличие следующее: в случае, если функция не вошла в релиз (опоздала на поезд), один из членов команды-разработчика функции вытягивает вошедшие в релиз изменения в ветку функции и производит слияние, после чего команда продолжает работать «поверх» нового релиза и, таким образом, сможет включить функцию в новый релиз.

6.2.8. Модель ядра Linux

Вразработке ядра Linux есть неглубокая иерархическая структура, окруженная очевидным облаком хаоса. Поскольку большинство разработчиков Linux используют git, распределенный инструмент управления версиями, подобный Mercurial, полезно описать рабочий процесс в этом окружении. Если вам понравятся идеи, подход легко переносится на другие инструменты.

Вцентре сообщества сидит Линус Торвальдс (Linus Torvalds), создатель Linux. Он публикует единственный исходный архив, который считается «авторитетным» текущим деревом всего сообщества разработчиков. Любой может клонировать дерево Линуса, но он очень разборчив в выборе деревьев с которых можно вливать изменения.

У Линуса есть несколько «доверенных лейтенантов». Как правило он помещает любые изменения, которые они издают, в большинстве случае даже не рассматривая их изменения. Некоторые из лейтенантов вообще являются «мейнтейнерами», отвечающими за отдельные подсистемы в пределах ядра. Если случайный разработчик ядра

62

Взаимодействие с людьми

хочет сделать изменения в подсистему, которые они хотят внести в дерево Линуса, они должны узнать кто является мейнтейнером подсистемы и попросить его внести изменения. Если мейнтейнер рассмотрит их изменения и согласиться их взять, то он передаст их Линусу должны образом.

Уиндивидуальных лейтенантов имеются свои собственные подходы к рассмотрению, принятию и публикации изменений, и для того чтобы решить когда передать их Линусу. В дополнение, существует несколько хорошо известных веток которые люди используют для различных целей. Например, некоторые люди обслуживают «stable» («стабильную ветку») репозитория с несколько устаревшей версией ядра, внося критические исправления если они необходимы. Некоторые мейнтейнеры публикуют несколько деревьев: одно для экспериментальных изменений, одно для изменений которые они собираются внести в стабильные и так далее. Другие просто публикуют отдельные деревья.

Уэтой модели есть две важные особенности. Первая это «только внесение». Вы должны спросить, убедить или попросить другого разработчика сделать изменения за вас, потому что практически нет веток, куда может помещать код одна персона, и не существует способа помещать код в ветки, контролируемые кем-то еще.

Вторая базируется на репутации и доверии. Если вы никому не известны, Линус вероятно проигнорирует ваши изменения и даже оставит вас без ответа. Но майнтейнер подсистемы вероятно рассмотрит их, если они пройдут его критерии пригодности. Чем более «хорошие» изменения вы вносите, тем более вероятно что они будут доверять вашему суждению и принимать ваши изменения. Если вы хорошо известны и поддерживаете долгое время какуюлибо возможность в ветке, которые Линус еще не принял, люди с похожими интересами могут вносить ваши изменения регулярно, для того чтобы не отставать от вашей работы.

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

Людям, пришедшим с более строгих проектов, и сравнивающих процесс разработки ядра Linux с места откуда они пришли, процесс разработки кажется полностью безумным. Разработка подчиняется прихотям людей; люди делают большие изменения всякий раз, как считают это нужным; и темп эволюционирования потрясает. Но все же Linux — это успешная и хорошо оцениваемая часть программного обеспечения.

6.2.9. Втягивающее против совместно-вносимого сотрудничества

Постоянным источником жара в open source сообществе является вопрос, которая из двух моделей разработки лучше: та, в которой люди всегда берут изменения у других, или та, в которой множество людей вносят изменения в общий репозиторий.

Обычно, покровители модели совместного вноса используют инструменты принуждающие использовать этот метод. Если вы используете инструмент централизованного контроля версий вроде Subversion, нет возможности выбрать модель: инструмент даёт вам только совместный внос, и если вы захотите что-то ещё, вам придётся прикрутить свой собственный метод сверху (как например наложение патча вручную).

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

6.2.10. Когда разработка сталкивается с управлением ветвлениями

Единожды создав несколько распределенных репозиториев и начав распространять изменения между локальным и общим репозиториями, вы с вашей командой начнете становиться связанными, но столкнетесь с немного другой проблемой: управлением направлениями, в которых ваша команда может разом двинуться. Хотя эта тема тесно связана с тем, как ваша команда взаимодействует, она довольно глубока, чтобы заслужить собственное рассмотрение в Глава 8, Управление релизами и ветками.

63