Контроль доступа

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

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

Работа с хранилищем

Есть два способа разработки кода с применением системы контроля версий:

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

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

Предпочтение следует отдать подходу «часто и понемногу». С помо% щью тегов можно пометить основные крупные версии, поэтому воз% можности другого подхода также оказываются доступными.

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

Внимательно относитесь к хранилищу. Следите, чтобы не записать в него не& работающий код, который не позволит работать остальным разработчикам.

Одна из наиболее мощных возможностей, предоставляемых система% ми контроля за исходным кодом, – это ветвление: создание несколь% ких параллельных потоков разработки из файла или группы файлов. Ветвление находит ряд применений, в том числе:

•Одновременное добавление нескольких функций к базовому коду.

•Предоставление личного рабочего пространства разработчику для сохранения не вполне отлаженного кода, чтобы не нарушить рабо% тоспособность базового кода.

•Сопровождение старой версии продукта при одновременной работе над новой версией.

Допустим, что ваш продукт – графический редактор, и вы хотите доба% вить в него новые инструменты. Кроме того, вы хотите начать новый проект на базе тех же исходных файлов с целью перенести продукт в другую операционную систему. Обе задачи начинаются независимо, но в конце концов должны быть объединены. Это распространенная ситуация. Для каждой задачи вы создаете в хранилище ветвь и моди% фицируете код в ней, а не в основном разрабатываемом коде. Этим са% мым вы разделяете две задачи. Один разработчик создает новые ин% струменты, другой – занимается переносом. Один не мешает другому.

Как и следует из названия, ветви создают в хранилище древовидную структуру параллельных версий файлов. Всегда есть, по крайней ме% ре, одна линия разработки кода, называемая стволом (по очевидным причинам). На рис. 18.1 показано, как на практике может происхо% дить ветвление отдельного файла. Он был создан (версия 1) и первона% чально разрабатывался в стволе (центральная колонка). В версии 2 мы создаем ветку первой функции (для новых графических инструмен% тов) и в ней производим сохранение ряда версий. Ни одна из них ни% как не влияет на ствол. Работа над стволом продолжается параллель% но, и в версии 3 создается вторая ветка для задачи портирования кода.

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

Даже если вам не нужно одновременно разрабатывать новые функции в своем базовом коде, ветвление можно с успехом применять в разра% ботке одной линии. При такой системе основная версия остается ста% бильной: это всегда законченный отлаженный продукт – возможно, последняя выпущенная версия кода. Каждая функция разрабатывает% ся в своей ветви функции или релиза, и сам продукт выпускается из этой ветки. Закончив разработку, мы сливаем ветку со стволом и снова

Версия 1

Рис. 18.1. Ветвление проекта в системе контроля версий

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

Краткая история систем контроля за исходным кодом

Существует много разных систем контроля за исходным кодом – как с открытыми, так и с коммерческими лицензиями. Часто выбор систе% мы определяется существующей в компании традицией. («Мы всегда работали с… и хорошо ее знаем».) К сожалению, это не всегда означа% ет, что выбран правильный или лучший инструмент. Во многих ком%