Что такое контроль версий, и зачем он вам нужен? Система контроля версий (СКВ) - это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов. Для примеров в этой книге мы будем использовать исходные коды программ, но на самом деле под версионный контроль можно поместить файлы практически любого типа.

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

Локальные системы контроля версий

Многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы.

Чтобы решить эту проблему, программисты уже давно разработали локальные СКВ с простой базой данных, в которой хранятся все изменения нужных файлов (см. рисунок 1-1).

Рисунок 1-1. Схема локальной СКВ.

Одной из наиболее популярных СКВ такого типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами версий (патч - файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.

Централизованные системы контроля версий

Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий (см. рис. 1-2).

Рисунок 1-2. Схема централизованного контроля версий.

Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте.

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

Распределённые системы контроля версий

И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных (см. рисунок 1-3).

Рисунок 1-3. Схема распределённой системы контроля версий.

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

Распределенная система управления версиями Git. Часть 1

Введение

Серия контента:

1. Введение

Во время работы над проектом его участники часто сталкиваются с проблемами синхронизации и ведения истории файлов, решить которые помогают системы управления версиями (СУВ). Цель этой серии статей – познакомить читателя с принципами работы СУВ и подробно рассмотреть одну из них, а именно Git. Почему Git? В последнее время эта система набирает популярность, и ее важность для свободного ПО (и для проекта GNU/Linux, в частности) сложно переоценить.

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

Автор сознательно опускает терминологию функций, ключей и прочих тонкостей, чтобы четко, ясно и в общем виде представить вам картину. Данная статья предполагает, что читатель знаком с Unix-подобными операционными системами (ОС), а также имеет базовые знания в области алгоритмики и информатики в целом.

В следующих материалах мы углубимся в структуру и философию Git, специфику этой системы и тонкости практической работы с ней. Завершит цикл статья о взаимодействии Git с другими СУВ (такими как Subversion, CVS, Mercurial и др.).

2. Git – это...

Git – это распределённая система управления версиями файлов. Код программы написан в основном на языке С. Проект был создан Линусом Торвальдсом в 2005 году для управления разработкой ядра Linux и, как и GNU/Linux, является свободным программным обеспечением (ПО), при этом стороннее использование подчиняется лицензии GNU GPL версии 2. Вкратце данное соглашение можно охарактеризовать как ПО со свободным кодом, которое должно развиваться открыто, т.е. любой программист вправе продолжить совершенствование проекта на любом его этапе. За свое недолгое время существования данная система была введена многими ведущими разработчиками. Git используется в таких известных Linux-сообществу проектах, как Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Системы управления версиями

Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией. Разберем общий вид разработки на примере.

Предположим, есть некий проект, который вы разрабатываете, несколько отделов программистов и вы – координатор (или руководитель). По отношению к системе контроля, будь то сервер (если речь идет о централизованной системе) или локальная машина, любой разработчик проекта ограничен только правами доступа на изменение и/или чтение версий файлов данного хранилища. В любой момент вы можете сделать откат данных до необходимой вам версии. Вы, как координатор, можете ограничить доступ определенным пользователям на обновление версии файла. Также СУВ предоставляет интерфейс наблюдения и поиска версий файлов. Например, можно создать запрос: “Где и когда менялся данный кусок кода?”.

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

4. Отличия распределённых систем управления версиями

Распределённые системы управления версиями – это СУВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СУВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СУВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта. Рассмотрим эту особенность, продолжая предыдущий пример.

У каждого разработчика на машине есть свой локальный репозиторий – место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СУВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.

5. Основные возможности и особенности Git

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

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

Git – довольно гибкая система, и область её применения ограничивается не только сферой разработки. Например, журналисты, авторы технической литературы, администраторы, преподаватели вузов вполне могут использовать её в своем роде деятельности. К таковым задачам можно отнести контроль версий какой-либо документации, доклада, домашних заданий.

Выделим основные отличия Git от других распределенных и централизованных СУВ.

Архитектура Git

SHA1 (Secure Hash Algorithm 1) – это алгоритм криптографического хеширования. Каждый файл вашего проекта в Git состоит из имени и содержания. Имя – это первые 20 байтов данных, оно наглядно записывается сорока символами в шестнадцатеричной системе счисления. Данный ключ получается хешированием содержимого файла. Так, например, сравнив два имени, мы можем почти со стопроцентной вероятностью сказать, что они имеют одинаковое содержание. Также, имена идентичных объектов в разных ветвях (репозиториях) – одинаковы, что позволяет напрямую оперировать данными. Хорошим дополнением сказанному выше служит ещё то, что хеш позволяет точно определить поврежденность файлов. Например, сравнив хеш содержимого с именем, мы можем вполне точно сказать, повреждены данные или нет. Далее под именем мы будем понимать имя файла, а строку символов будем называть SHA1-хешем.

Стоит упомянуть о так называемых коллизиях. “Вполне точно определить поврежденность” означает, что существуют такие файлы, различные по содержанию, SHA1-хеш которых совпадает. Вероятность таких коллизий очень мала, и по предварительной оценке равна 2 в -80-й степени (~ 10 в -25-й степени). Точной оценки нет, так как на данный момент мировому сообществу не удалось эффективно расшифровать данную криптографическую схему.

Объекты Git

Работу с версиями файлов в Git можно сравнить с обычными операциями над файловой системой. Структура состоит из четырех типов объектов: Blob, Tree, Commit и References; некоторые из них, в свою очередь, делятся на подобъекты.

Blob (Binary Large Object) – тип данных, который вмещает лишь содержимое файла и собственный SHA1-хеш. Blob является основным и единственным носителем данных в структуре Git. Можно провести параллель между данным объектом и инодами (inodes) в файловых системах, поскольку их структура и цели во многом схожи.

Дерево (Tree)

• собственный SHA1-хеш;
• SHA1-хеш blob’ов и/или деревьев;
• права доступа Unix-систем;
• символьное имя объекта (название для внутреннего использования в системе).

По своей сути объект является аналогом директории. Он задает иерархию файлов проекта.

Commit – тип данных, который содержит:

• собственный SHA1-хеш;
• ссылку ровно на одно дерево;
• ссылку на предыдущий commit (их может быть и несколько);
• имя автора и время создания commit’а;
• имя коммитера (commiter – человек, применивший commit к репозиторию, он может отличаться от автора) и время применения commit’а;
• произвольный кусок данных (блок можно использовать для электронной подписи или, например, для пояснения изменений commit’а).

Данный объект призван хранить снимок (версию) группы файлов в определенный момент времени, можно сравнить его с контрольной точкой. Commit’ы можно объединять (merge), разветвлять (branch) или, например, установить линейную структуру, тем самым отражая иерархию версий проекта.

Reference – тип данных, содержащий ссылку на любой из четырех объектов (Blob, Tree, Commit и References). Основная цель его – прямо или косвенно указывать на объект и являться синонимом файла, на который он ссылается. Тем самым повышается понимание структуры проекта. Очень неудобно оперировать бессмысленным набором символов в названии, ссылку же, в отличие от SHA1-хеша, можно именовать так, как удобнее разработчику.

Из ссылок, в свою очередь, можно выделить ряд подобъектов, имеющих некоторые различия: Ветвь, Тег. Рассмотрим их.

Ветвь (Head, Branch) – символьная ссылка (Symbolic link), которая указывает на последний в хронологии commit определенной ветви и хранит SHA1-хеш объекта. Является типом данных журналируемых файловых систем. Данный вид объекта определяется не в самом Git, а наследуется от операционной и файловой систем. Ветвь используется как синоним файла, на который она ссылается, т.е. Git позволяет оперировать ею напрямую. Можно позволить себе не задумываться о том, работаете ли вы с последней версией или нет.

Тег (tag) – тип данных, который в отличие от ветвей неизменно ссылается на один и тот же объект типа blob, tree, commit или tag. Его, в свою очередь, можно разделить на легковесный (light tag) и тяжеловесный или аннотированный (annotated tag). Легкий тег, кроме неизменности ссылки, ничем не отличается от обычных ветвей, т.е. содержит лишь SHA1-хеш объекта, на который ссылается, внутри себя. Аннотированный тег состоит из двух частей:

• первая часть содержит собственный SHA1-хеш;
• вторая часть состоит из:
  • SHA1 объекта, на который указывает аннотированный тег;
  • тип указываемого объекта (blob, tree, commit или tag);
  • символьное имя тега;
  • дата и время создания тега;
  • имя и e-mail создателя тега;
  • произвольный кусок данных (данный блок можно использовать для электронной подписи или для пояснения тега).

Иными словами, проект в Git представляет собой набор blob’ов, которые связаны сетью деревьев. Полученная иерархическая структура может, в зависимости от времени, быть отражена в виде commit’ов – версий, а для понимания их структуры в Git присутствуют такие объекты, как ссылки. Исключая действия со ссылками, почти вся работа с объектами системы максимально автоматизирована изнутри. Отталкиваясь от механизма ссылок, мы приходим к следующей идее – работать именно над группами файлов. По мнению автора, мысль является ключевой в философии Git. Задав, например, операцию для данного commit’а, она рекурсивно отработает свою часть по дереву, на которое ссылается. Являясь расширением общепринятого взгляда “действие над каждым файлом”, нововведение упрощает реализацию и подход со стороны программиста над повседневными задачами СУВ, такими как слияние/разделение ветвей, опять же рекурсивно автоматизируя процесс. Данный подход прост для понимания, быстро работает и гибок в реализации своих целей. Многие из этих черт достигаются благодаря Unix-ориентированности системы, т.е. оперируя стандартными устройствами, Git опирается на уже имеющиеся в операционной системе решения.

Проясним момент хранения данных. Содержание файлов разных версий в хронологии занимает довольно много памяти. Так, например, в проекте из двадцати файлов двадцати версий архив будет весить в 20 раз больше (возможно, порядка сотни мегабайтов), а что будет, если количество и тех и других в 10 раз больше (вроде бы не намного)? Размер занятого пространства возрастет в 100 раз (т.е. примерно 1 ГБ). В реальных задачах скорость роста занимаемой памяти далеко не линейно зависит от времени. Для решения данной проблемы существует несколько оптимизаций:

• каждый объект Git хранится в виде обыкновенного архива (tar.gz);
• для всей иерархии файлов применяется последовательная дельта-компрессия.

Разберем на примере.

У вас есть трехлетняя история вашего проекта, в ней порядка тысячи файлов и ста версий. Если в определенный момент нужно будет обратиться к самой ранней версии, Git придется разархивировать дельта-компрессию всей истории файла. Неутешительно, но на данный процесс может уйти до полудня. Git предлагает делать так называемые контрольные точки, т.е. хранить недельта-архивированный файл через некоторое количество версий, которое назовем глубиной компрессии. Тогда в нашем примере вся история сужается до некоторого наперед заданного количества дельта-компрессий, разархивировав которые, можно взглянуть на любую версию в хронологии. Заметим, что дельта-компрессию наиболее целесообразно использовать над одними видами ближайших в иерархии объектов, для этого репозиторий необходимо отсортировать соответственно по типу и размеру. Данный ряд операций, описанных в этом пункте, выполняет функция git-repack (и git-gc, которая её содержит).

Слияние и разделение ветвей

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

Представим себе момент разработки проекта, когда главной поставленной целью является скорость работы программы. Один из возможных тактических вариантов решения – разбить разработчиков на две группы, каждая из которых будет решать одну и ту же задачу. При этом ветвь истории проекта должна раздвоиться. Данная процедура называется ветвление (branch). Действие разветвления ветви – это простое создание её копии, которая впоследствии будет иметь свою историю.

Пусть мы получили два уже законченных результата одной и той же задачи, над которой работали две группы программистов. Как нам быть? Посмотреть, чей код быстрее и надежнее? Это слишком просто, но не всегда лучший выход. Хорошее решение – это, немного разобравшись в коде и файлах, разбить их на подзадачи или блоки кода. И только тогда уже выявлять сильные и слабые стороны данных кусочков. Конечно, этот вариант подходит только в том случае, когда вы заранее предусмотрели, что впоследствии сможете собрать все эти частицы воедино. Случай, когда вы сами разрабатываете код, улучшая и исправляя некоторые ошибки, равнозначен приведенному примеру. Данный процесс объединения двух целых в одно называется слияние (merge). Процесс объединения двух версий и есть ключевой момент ведения проекта. Как бы то ни было, стоит избегать автоматизированного исполнения данной операции. Отличительная черта Git – это максимально достоверный и довольно быстрый способ решения задачи ветвления.

К достоинствам системы можно отнести:

1. Unix-ориентированность.
2. Идеологическая выдержанность (следуя правилам использования системы, очень сложно попасть в безвыходную ситуацию или получить то, чего вы не ожидали).
3. Высокая производительность (это одно из самых явных достоинств системы, плата за которое есть «Идеологическая выдержанность» и «Unix-ориентированность»).
4. Интеграция Git со сторонними СУВ, такими как Subversion, Mercurial, …
5. Управление группой файлов (системе нет необходимости рассматривать изменения в каждом файле по отдельности, она запоминает любые изменения всего проекта, и если вдруг вам понадобится проследить единичные изменения, она выдаст ровно ту часть, которая связана с данным файлом).
6. Операция слияния (максимально автоматизированная реализация сложной задачи).

К недостаткам отнесем:

1. Unix-ориентированность (стоит отметить отсутствие зрелой реализации Git на не Unix-системах).
2. Необходимость периодического выполнения команды git-gc (пакует группы файлов и удаляет те, которые не связанны ссылками).
3. Коллизии хеширования (совпадение SHA1 хеша различных по содержанию файлов).

6. Интерфейсы Git

«Сколько людей, столько и мнений». Попробуем выделить ряд типов интерфейсов для работы с системой. Для определенных целей по-своему лучше каждое из приведеных ниже видов приложений.

Для людей, которые не занимаются разработкой вплотную, для «консерваторов» – тех, кто любит “кнопочки и галочки” и сознательно хочет оградить себя от непомерных усилий запоминания функций, ключей и многих тонкостей, больше подойдет вариант в стиле TortoiseGit или Git Extensions – простые интерфейсы. Они позволяют действовать преимущественно мышью и работают в привычной для многих ОС Windows.

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

Можно выделить и третий тип интерфейсов – смешение первых двух. Т.е. у вас есть консольное приложение, например, “родная” оболочка git. Вы можете использовать ряд дополнительных утилит, таких как Gitk или QGit, для отображения деревьев, упрощения обзора иерархии версий, различий между версиями, поиска нужных объектов.

Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

Зачем это нужно

Сам я являюсь студентом технического ВУЗа и практически постоянно работаю с документами (текстами, рисунками, чертежами), изменяя их по три (десять, сто) раз на дню. Порой получается так, что правки, сделанные в течение последней недели, необходимо отменить и вернуться к документам в состоянии недельной давности. Хорошо, если правок было сделано немного, в этом случае могут помочь полсотни ударов по Ctrl+Z. Однако если в течение этой недели шла более-менее активная работа с документом, просто так восстановить статус «до важной правки, сделанной неделю назад» не получится. Для этого необходима копия документа на момент «до важной правки», а также еще десяток копий «до другой важной правки», «до сомнительной правки» и «до правки, которую, скорее всего, придется отменить». В принципе, такой подход возможен и практикуется многими. До недавнего времени я и сам держал важные версии файлов, сохраняя их с префиксами «дата_время», и, вроде бы, был доволен. Преимуществом этого метода является простота, недостатком – «разбухание» рабочих папок и неудобство использования. И, если с первым из них можно как-то бороться (большими жесткими дисками и 7zip’ом), то с неудобством что-то нужно было делать.

Что с этим можно сделать, или что такое СКВ

Вырываем абзац из Википедии: «Система управления версиями (от англ. Version Control System, VCS или Revision Control System) – программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое». Похоже на принцип работы самой Википедии – все версии статей со всеми правками доступны для изучения.
Таким образом, использование СКВ в ситуации, когда нужно хранить множество версий файлов – то, что надо. К преимуществам такого подхода относятся удобство использования и экономия свободного дискового пространства благодаря так называемому дельта-сжатию (когда сохраняются не сами файлы в различных версиях, а изменения от версии к версии, что уменьшает объем хранимых данных). Давайте попробуем.

Какие бывают СКВ

Та же Википедия подсказывает, что СКВ бывают централизованные и распределенные, большие и маленькие, с примочками и без. Нас это не особо интересует, так как мы будем пользоваться (по крайней мере, сначала) только частью функционала СКВ. Этот самый функционал и рассмотрим.
Практически все СКВ представляют собой некое хранилище, в котором хранятся все версии файлов, с которыми мы работаем. Здесь необходимо уточнить, что версии хранимых файлов чаще всего определяет пользователь. Внесли мы, допустим, с десяток мелких правок и решили, что пора бы сохранить результаты нашей деятельности в хранилище. В голову приходит аналогия с периодическим нажатием Ctrl+S, с тем лишь отличием, что к данной версии файла можно будет обращаться в будущем. Естественно, что «одним махом» таким образом можно занести в хранилище версии сколь угодно большого количества файлов. Называется это действие «commit», или «фиксация изменений» по-простому.
В любой момент в репозиторий (а именно так по-умному называется хранилище) можно добавить новый или удалить существующий файл, и СКВ будет «помнить» когда и что мы добавили/удалили. А благодаря комментариям при commit’ах можно еще и описать для чего собственно данный commit выполняется («добавили фенечку туда-то»/«удалили возможно нужный кусок оттуда-то»).
Когда же мы, наконец, понимаем, что пора бы нам вернуться к версии недельной давности, у нас имеется вся история изменений. И тут мы можем выбирать, как поступить. Если необходимо скопировать из старого файла нужный кусочек и вставить в текущую версию – просто извлекаем из хранилища старый файл и копируем из него необходимое. Если же необходимо полностью откатиться назад и продолжить работу со старой версией нам на помощь снова приходит СКВ – можно вернуться к ранней версии и создать так называемую новую ветку («branch»), сохранив при этом все, от чего мы «отказались», откатившись в версиях на неделю назад. Таким образом, историю версий проекта графически можно представить в виде дерева – от «корней» (начала проекта) до «ветвей» (удачных и неудачных правок). Кроме того, «ветку» можно создать и искусственно, к примеру, в том случае, когда из одних исходных файлов мы решим развить две различные версии – в первой работаем над одними фенечками, во второй – над другими. Более того, в случае, если рабочие файлы представляют собой текстовые документы (и в некоторых других), возможно объединение различных веток в одну – так называемое слияние («merge»). Теперь представим, что над проектом работают несколько человек, и каждый занимается своей такой «фенечкой». Наличие общего репозитория в этом случае сильно упрощает разработку.

От теории к практике, или начинаем использовать СКВ

Итак, надеюсь, я убедил вас в том, что использование СКВ – это хорошо. Осталось лишь научиться использовать СКВ. Этим и займемся.
Существуют различные системы контроля версий, отличающиеся друг от друга различными аспектами использования. Так как нас не интересуют (по крайней мере, сначала) тонкости работы различных систем, остановимся на самой простой и дружелюбной из них. По моему скромному мнению, такой системой, как ни странно, является Mercurial – «кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода» с графической оболочкой TortoiseHg. Работа с системой возможна под Windows, Linux и Mac OS X.
Сразу оговорюсь, что буду описывать работу с системой в Windows. Освоившим Linux не составит труда изучить все по аналогии.
Кроме того, параллельно обучимся работать с бесплатным хостингом Mercurial репозиториев – bitbucket.org, необходимым в случае, если вы работаете над проектом не одни или же, что очень удобно, хотите иметь доступ ко всем версиям проекта через интернет. По сути, это удобная замена Dropbox, если вы использовали его ранее.
Для начала устанавливаем Mercurial + TortoiseHg отсюда: tortoisehg.bitbucket.org.
Эта система работает в консоли, поэтому для удобства использования позже напишем несколько *.bat файлов для типичных операций.
Все операции производятся командой hg. Вызванная без параметров, она выводит список основных команд.
В качестве репозитория выступает любая выбранная нами директория (я буду использовать папку “C:\project\”), в которой и должны храниться все файлы нашего будущего проекта. Разумеется, никто не запрещает иметь несколько репозиториев на одном компьютере.
Чтобы система «поняла», что мы хотим создать репозиторий, выполняем команду:
hg init c:\project
после которой будет создана папка “c:\project\”, если она не была создана ранее и папка “c:\project\.hg\”, в которой Mercurial будет хранить всю служебную информацию.
Тут же вспоминаем, что хотим получить не только локальный репозиторий на своем компьютере, но и удаленный репозиторий, в который будем отправлять все наши изменения (или, как говорят умники, «пушить» изменения в удаленный репозиторий, от англ. «push»). Для этого идем на bitbucket.org, регистрируемся, и создаем свой первый репозиторий (Repositories - Create new repository). Даем репозиторию имя (я для определенности назову его remote_project) и жмем на Create repository.
Теперь у нас имеются два репозитория – локальный, находящийся в папке “c:\project\” и удаленный, расположенный по адресу “bitbucket.org/имя_вашей_учетки/remote_project/”, где имя_вашей_учетки – указанное при регистрации на bitbucket, remote_project – имя репозитория, выбранное при его создании.
Для того, чтобы продолжить изучение, нам необходимо поместить что-нибудь в наш локальный репозиторий. Просто создайте в нем (в моем случае – в папке “c:\project\”) любой файл вашего будущего проекта либо скопируйте туда ваш текущий проект.
Теперь, строго говоря, нам необходимо указать Mercurial: «мы добавили в папку проекта такой-то и такой-то файлы и пару новых папок», для этого предусмотрена команда “hg add”. Однако, более удобен другой подход – при очередном commit’е мы прикажем Mercurial подхватить все свежесозданные файлы из папки проекта и забыть про удаленные, это гораздо легче, чем каждый раз при создании нового документа выполнять “hg add c:\project\new_document.doc”.
Итак, приступаем к нашему первому commit’у. Выполняется он следующей командой:
hg commit –A –m “comment to commit”
Разберем все по порядку. Команда должна вводиться тогда, когда мы находимся в репозитории (то есть предварительно необходимо выполнить “cd c:\project”). Опция “-A” необходима для того, чтобы Mercurial «подхватил» свежесозданные файлы (см. выше), опция “-m” позволяет добавить к commit’у комментарий. Эти комментарии будут отображаться при просмотре версий (или changeset’ов – списков изменений) в TortoiseHg и на странице проекта в bitbucket.org. Очень важно давать осмысленные комментарии, чтобы потом не мучаться, вспоминая, когда же была сделана та или иная правка.
Теперь в нашем репозитории хранится начальная версия нашего проекта. Все дальнейшие commit’ы выполняются аналогично после того, как мы решим, что пора бы сохранить текущую версию.
Сделанный commit можно «втолкнуть» в удаленный репозиторий командой:
hg push https://bitbucket.org/имя_вашей_учетки/remote_project
При этом также необходимо находиться в папке, соответствующей репозиторию. После ввода команды будет запрошено имя и пароль нашей учетки на bitbucket.org, чтобы не вводить их при каждом push’е команду можно заменить на следующую:
hg push hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Так как все команды мы забьем в *.bat файл, в этом случае пароль будет храниться в открытом виде, что представляет собой некоторую угрозу безопасности, однако для меня это приемлемо.
Итак, для удобства создаем в зоне прямой досягаемости файлы commit.bat, push.bat и commit&push.bat со следующим содержанием:
[содержание файла commit.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
Этот файл, вызванный с аргументами, выполнит commit проекта с занесением аргументов в комментарии к commit’у. Пример: выполняем “commit.bat my first commit” и получаем commit с комментарием «my first commit». В FAR’е для этого удобно использовать сочетание Ctrl+Enter.
[содержание файла push.bat]
cd C:\project
hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Этот файл произведет push в удаленный репозиторий.
[содержание файла commit&push.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
call ./push.bat
Этот файл, вызванный с аргументами, выполнит последовательный commit и push проекта с занесением аргументов в комментарии к commit’у.
Кроме того, для мелких промежуточных commit’ов я рекомендую создать файл commit_date_time.bat:
[содержание файла commit_date_time.bat]
cd C:\project
hg commit -A -m "%DATE% %TIME%"
Этот файл произведет commit с указанием текущей даты и времени в качестве комментария, что часто бывает удобно.
Вопрос о частоте commit’ов и push’ей каждый решает в индивидуальном порядке в зависимости от интенсивности и сложности вносимых правок. Хотя и рекомендуется руководствоваться правилом «чаще – лучше».
Правым кликом на файле/папке репозитория можно запустить Repository Explorer (TortoiseHg - Repository Explorer), в котором представлены все наши commit’ы с комментариями к ним. В этом окне отображается древовидная структура нашего репозитория, отсюда же можно производить commit’ы, push’и, откаты к предыдущим версиям (backout’ы) и другие операции.
По адресу bitbucket.org/имя_вашей_учетки/remote_project находится аналогичный набор changeset’ов, при этом можно скачать любую версию проекта одним архивом, что иногда также очень удобно.
В общем, первоначальное знакомство с Mercurial на этом считаю оконченным. За более подробной информацией можно обратиться по адресу: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Для кого эта статья

Закончу, пожалуй, тем, с чего следовало бы начать – для кого эта статья? Ответ прост – для тех, кто хочет научиться использовать СКВ. Мне удалось «подсадить» на СКВ нескольких дизайнеров, инженеров и даже писателя. Попробуйте и вы – этим вы, возможно, сильно облегчите себе работу.

P. S. Перенес в блог «Системы управления версиями».

Теги: Добавить метки

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

Естественно, поиски были начаты с изучения Хабра - и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет:).

Почему мы считаем, что работа с командной строкой неэффективна?

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

К сожалению, нам не удалось найти полноценного русскоязычного мануала по работе с современными системами контроля версий. Собрав информацию из разных статей и англоязычных видео на YouTube, мы решили сделать своё собственное руководство, которое:

1. Будет пошаговой инструкций (по ней же будут работать наши программисты).
2. Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат - работающую распределенную систему контроля версий).
3. Будет работать с использованием только графических интерфейсов (причины см. выше).

Вступление

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

Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.

Используемые программы и сервисы

Для развертывания VCS (системы контроля версий) мы будем использовать следующие программы и сервисы:

• Mercurial - кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
• TortoiseHg - графический фронтенд для системы контроля версий Mercurial.
• Bitbucket - веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.

Развертывание система контроля версий – пошаговая инструкция

1. Скачиваем и устанавливаем к себе на компьютер TortoiseHg с официального сайта: http://tortoisehg.bitbucket.org/

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

В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.

2. Регистрируемся в веб-сервисе Bitbucket: https://bitbucket.org/
Весь процесс регистрации сводится к заполнению контактных данных (Username, Email и т.д.) и подтверждения указанного при регистрации email-адреса нажатием на кнопку «Confirm this email address» в полученном после регистрации письме.

Регистрироваться в сервисе Bitbucket потребуется также всем участникам вашей команды разработчиков. К великому счастью стартапов в данном сервисе есть бесплатный аккаунт, который позволяет создавать приватные репозитории с 5-ю пользователями. Также есть возможность увеличения максимального числа членов команды, участвующей в разработке на бесплатном тарифе до 8 человек.

С полным списком тарифов вы можете ознакомиться, пройдя по ссылке: https://bitbucket.org/plans

3. Зайдя в ваш аккаунт в сервисе Bitbucket, вы можете сразу изменить язык интерфейса вашего аккаунта на русский.

Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса

4. Для создание репозитория для вашего проекта вам необходимо перейдите на главную страницу вашего аккаунта (https://bitbucket.org/dashboard/overview) и нажмите на кнопку «Создайте ваш первый репозиторий»

5. На странице создания нового репозитория укажите следующие настройки:

Имя – Укажите имя вашего нового репозитория. Данное имя используется для построения ссылки доступа к вашему репозиторию.
Важно! Лучше указывать имя латинскими буквами, иначе ссылка на репозитрий будет заканчиваться дефисами и иметь сложный к пониманию вид: httрs://вашлогин@bitbucket.org/вашлогин/--------

Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
- Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
- Создание форков – Поставьте «Разрешить только приватные форки»
- Тип репозитория – Выберите «Mercurial»
- Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
- Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.

По завершению указания всех настроек страница будет выгладить приблизительно так:

Еще раз проверьте введенные данные и если все введено корректно, жмем кнопку «Создать репозиторий».

6. После создания нового репозитория вы попадете на страницу «Начало работы»:

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

Важно! Папка должна быть пустой. Мне, например, для подключения папки с уже существующим проектом (кучей программного кода) пришлось временно перенести все файлы в другой каталог (сделать резервную копию - backup). Позже мы вернем все файлы на место, а пока нужно полностью очистить папку для подключения.

8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6

И нажать кнопку «Клонировать».

9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.

10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.

11. Теперь можно смело возвращать файлы (программный код) вашего проекта в папку, предназначенную для хранения файлов проекта, подключенных к системе контроля версий Mercurial

Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.

12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»

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

Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».

Система попросит подтвердить добавление, жмите «Добавить».

14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:

Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.

Учитывая вышесказанное, на практике следует писать более развернутый, чем «Версия 1.00», комментарий к каждой из фиксаций.

16. В открывшемся окне вы можете видеть всю историю сохраненных (зафиксированных) изменений в коде, можете откатить к нужной фиксации, а также отправить изменения в созданный вами ранее репозиторий.

Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».

После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.

Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.

17. Теперь копия файлов вашего проекта храниться в вашем репозитории на серверах Bitbucket. В вашем аккаунте Bitbucket вы можете видеть всю историю работы с вашим проектом.

Промежуточные итоги подключения системы контроля версий (VCS)

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

Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.

Подключение сотрудников к вашему репозиторию.

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

Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.

Подключение сотрудника к нашему репозиторию

18. Все сотрудники, которые будут иметь доступ к вашему репозиторию, должны быть зарегистрированы на сервисе Bitbucket. А также у них на компьютерах должен быть установлен TortoiseHg.

Как зарегистрироваться на сервисе и установить TortoiseHg, я рассказывал чуть ранее в данной инструкции. Поэтому данный процесс не должен вызвать у вас и ваших коллег никаких трудностей.

19. Зайдите в ваш аккаунт на сервисе Bitbucket:

Нажмите на кнопку «Отправить приглашение», расположенную в разделе «Пригласить участника на этот репозиторий».

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

После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».

21. Приглашенный участник получит на свой email письмо со ссылкой на приглашение. Ему будет необходимо пройти по данной ссылке и принять приглашение на доступ к вашему репозиторию.

Еще раз повторю, все участники вашего репозитория должны быть зарегистрированы в сервисе Bitbucket.

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

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

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

Данный подход мы применили для разработки проекта.

У вас появилась новая замечательная бизнес-идея, связанная с разработкой ПО? Вам нужно разработать технологически сложное решение? Или у вас большая команда программистов, работающих над одной задачей? Тогда запомните эти три слова: система контроля версий .

Система контроля версий (cvs), 2017 — Сравниваем: Git, SVN, Mercurial

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

Если вы еще не знакомы с концепцией системы контроля версий , то вот все очень наглядно показано.

Или посмотрите видео от GitHub.

Итак, какая система контроля версий подойдет для вашего проекта?

Мы сравнили несколько популярных решений, чтобы вам было проще сделать выбор.

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

Системы контроля версий , в том числе широко известные SVN (Subversion) и Git, изначально создавались, чтобы команды разработчиков могли работать над совместными проектами, не создавая путаницы. В системе контроля не надо самостоятельно отслеживать ветви кода и изучать примечания к ним. Вместо этого используется центральный репозиторий, где всё упорядочено, структурировано. Здесь удобно обновлять файлы, добавлять комментарии и даже проводить слияние веток проекта.

Мнения в отношении того, какая система контроля версий самая лучшая, сильно разнятся, и это приводит к бурным спорам в среде программистов. Подбирая и изучая системы контроля версий для вашего проекта, не забывайте, что преимущества того или иного решения часто субъективны. Например, личные предпочтения программиста или, скажем, такие показатели как быстродействие, возможности плагинов IDE и т.д.

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

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

Система одновременных версий (CVS )

CVS появилась в 1980-х и до сих пор популярна как у разработчиков коммерческих продуктов, так и у open-source разработчиков.

CVS распространяется на условиях Открытого лицензионного соглашения GNU и позволяет получать с сервера нужную версию проекта - « check-out» (извлечение) , а затем пересылать обратно на сервер, « check-in» (возврат), с внесенными изменениями.

Изначально CVS была создана, чтобы избежать конфликта версий. Всем участникам для работы предоставлялась только самая последняя версия кода. Это была первая система контроля версий. Пользователю нужно было быстро фиксировать изменения в репозитории, пока другие не опередили его.

Сейчас CVS имеет поддержку работы над проектами с ветками кода. Получается несколько вариантов продукта с разными характеристиками, которые можно будет объединить позднее.

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

При этом CVSNT, - выделившаяся в отдельный проект версия CVS для серверов Windows, - сейчас достаточно активно расширяет функционал.

Преимущества:

• Испытанная временем технология, которая удерживается на рынке десятки лет.

Недостатки:

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

Apache Subversion (SVN)

SVN создавалась как альтернатива CVS с целью исправить недостатки CVS и в то же время обеспечить высокую совместимость с ней.

Как и CVS , SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.

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

Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.

В то время как в CVS операции с ветками кода дорогостоящие и не предусмотрены архитектурой системы, SVN создана как раз для этого. То есть, для более крупных проектов с ветвлением кода и многими направлениями разработки.

В качестве недостатков SVN упоминаются сравнительно низкая скорость и нехватка распределенного управления версиями. Распределенный контроль версий использует пиринговую модель, а не централизованный сервер для хранения обновлений программного кода. И хотя пиринговая модель работает лучше в open source проектах, она не идеальна в других случаях. Недостаток серверного подхода в том, что когда сервер падает, то у клиентов нет доступа к коду.

Преимущества:

• Система на основе CVS
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель

Недостатки:

• Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с репозиторием
• Сравнительно небольшая скорость

Git

Эта система была создана для управления разработкой ядра Linux и использует подход, который в корне отличается от CVS и SVN.

В основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий , в противовес правилам и решениям, использованным в CVS . Так как Git разрабатывалась главным образом под Linux, то именно в этой ОС она работает быстрее всего.

Git также работает на Unix-подобных системах (как MacOS), а для работы на платформе Windows используется пакет mSysGit.

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

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

Преимущества:

• Прекрасно подходит для тех, кто ненавидит CVS /SVN
• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная оффлайн
• Распределенная, пиринговая модель

Недостатки:

• Высокий порог вхождения (обучения) для тех, кто ранее использовал SVN
• Ограниченная поддержка Windows (по сравнению с Linux)

Mercurial

Mercurial была выпущена одновременно с Git. Это также распределенная система контроля версий .

Mercurial создавалась в качестве альтернативы Git для разработки модулей ядра Linux. Но так как выбрали все-таки Git, то Mercurial используется меньше. Тем не менее, многие ведущие разработчики работают именно с этой системой, например OpenOffice.org .

Система контроля версий Mercurial отличается от других систем контроля версий тем, что главным образом она написана на Python (а не С). Однако, некоторые части выполнены в качестве модулей-расширений на C.

Поскольку система децентрализованная и написана на Python, многие Python-программисты склоняются к переходу на Mercurial.

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

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

Преимущества:

• По сравнению с Git легче в освоении
• Подробная документация
• Распределенная модель системы контроля версий

Недостатки:

• Нет возможности слияния двух родительских веток
• Использование плагинов, а не скриптов
• Меньше возможностей для нестандартных решений

Какая система контроля версий мне подходит ?

В большинстве случаев разработчики используют CVS потому что это им привычнее. Если команда уже работает над проектом, то перспектива переноса всех наработок в другую систему контроля как-то не вдохновляет. Если бы им все-таки пришлось менять систему, то, скорее всего, они переключились бы на SVN.

CVS уже достигла статуса “зрелой технологии”, а это значит, что в ней уже не появится радикально новых функций и решений. Инерция привычки теряется, так как люди переходят на SVN. А значит CVS постепенно уходит в прошлое.

Сегодня SVN удерживает пальму первенства среди серверных систем контроля версий . Она включает в себя преимущества CVS и превосходит их. Если же говорить о распространенности, то вы, скорее всего, будете чаще сталкиваться с CVS или SVN, чем с Git или Mercurial. Таким образом, знание одной серверной технологии, хотя и не является необходимым, облегчит вам переход.

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

У Git явно выше быстродействие по сравнению с конкурентами. Для проектов, которые создаются под распределенные системы контроля версий , это очевидное улучшение.

Существенным недостатком Git является то, что порой трудно объяснить нюансы работы данной системы контроля , и это тормозит рабочий процесс, пока программисты привыкают к ней. Однако, как только «порог вхождения» преодолен, продуктивность возрастает и удобство управления ветками кода сполна окупит потраченное время.

Для тех, кто терпеть не может Git (а у этой системы есть свои противники в среде разработчиков), Mercurial - это компромисс между SVN и Git. Эта система используется во многих известных проектах, а также у нее хорошая документация.

Совместимая с Windows версия Git также прогрессирует, приближаясь по своему быстродействию к Linux-версии, так что эта система может быть для вас актуальна, даже если вы не ведете разработку в Linux.

Чтобы понять, какая же лучше для вас, учитывайте особенности проекта и вашей команды. Поговорите с разработчиками!

Если для проекта требуется единое дерево исходного кода, над которым будет работать небольшая группа программистов, то SVN – это ваш вариант. Она надежна и предназначена как раз для таких случаев.

Если же вы запускаете open-source проект, над которым в разное время будут трудиться несколько программистов или, если предполагается постоянное обновление кода, то выбирайте Git. Скорость и управление деревом исходного кода здесь намного лучше, чем в SVN.

Если вы на распутье или вам просто не нравится, как работают SVN или Git, тогда к вашим услугам Mercurial.

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

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

Приступая к работе с SVN

Если вы никогда не работали с SVN или Git, и понятия не имеете, как начать, то хостинговое решение в сочетании с графическим интерфейсом помогут вам быстро освоиться.

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

ПРИМЕЧАНИЕ: Есть множество хостинговых решений для системы контроля версий , в том числе с бесплатным пробным периодом. Вы можете создать на их базе свой первый репозиторий (место для совместной работы с файлами кода) совершенно бесплатно. Вот некоторые из этих сервисов:

Хостинг SVN & GIT

Создание первого репозитория

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

• Войдите в свой аккаунт, кликните по вашим проектам.
• Создание проекта:

• В строке «Create a New Project» введите имя вашего проекта
• Кликните по кнопке «Create Project»

• Подключение SVN:

• После создания проекта, выберите вкладку «Source Control» (версиями исходного кода)
• Кликните по ссылке «Enable Source Control»
• Присвойте репозиторию имя
• Нажмите «Save»

Графические клиенты SVN и GIT

Итак, репозиторий создан. Теперь нужно, чтобы в нем все отображалось просто и наглядно. Для этого вам понадобится графический интерфейс.

— удобная программа для работы с системами контроля версий в Microsoft Windows и, возможно, лучший из представленных Apache Subversion клиент. TortoiseSVN реализован как расширение оболочки Windows, что позволяет легко интегрировать его в браузер. Кроме того, это программа с открытым исходным кодом, для которой доступны 34 языковых пакета

SmartGit

– графический клиент Git (Open Source распределенная система контроля версий ). Работает в Windows, Mac OS X и Linux. Стоимость лицензии - $39

«Извлечение» репозитория (“Checkout”)

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

URL-адрес обычно выглядит так: https://svn.hostname.com/svn/ > (вы можете использовать https:// (SSL), если у вас платный аккаунт)

1. Перейдите в корневую папку, нажмите кнопку «Check Out» («Извлечение») и создайте рабочую папку для клиента. Теперь вы можете добавлять в нее файлы.
2. После извлечения файлов проекта вы сможете редактировать их в локальной директории на вашем компьютере.

После внесения изменений в файлы для их сохранения нажмите кнопку «Check-in» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии - это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.

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