Ваше местоположение в сети:
Рубрика:

Системы контроля версий

Разделы сайта:

Большинство из читателей этого блога, скорей всего, никогда с системами контроля версий не сталкивались и в ближайшее время не столкнутся. А жалко. Это чрезвычайно удобное изобретение достаточно широко используется программистами, но, на мой взгляд, могло бы очень пригодиться и тем, кто активно работает с текстами. Но, наверное, сейчас нет ни одной системы контроля версий, которую было бы легко начать использовать для "офисной" (Microsoft Office) работы. Тем не менее, мне думается, что материал, изложенный в статье, может быть интересным для всех читателей.

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

Основы контроля версий

Допустим, я пишу программу, и в понедельник утром с бодуна мне приходит "блестящая" идея, как ускорить ее работу. Но терзают смутные сомнения - а вдруг "не сработает", вдруг станет только хуже? Мне ведь как-то надо будет вернуться потом к той версии, что я использовал до этого! Как бы я поступил без системы контроля версий? Правильно, сделал бы копию программы, а потом начал бы работать над своими идеями. И вот, к середине для я заканчиваю, после чего тестирую. Если дело пошло плохо, то новая версия удаляется (или кладется в архив с какой-то пометкой), если хорошо, то она становится основной. Вроде бы, все отлично?

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

Как это бы могло сработать, используй вы систему контроля версий? Утром в понедельник вы бы ничего не копировали. Зато после работы кратко просуммировали бы суть сегодняшней работы. Для этого просто вызывается одна команда, и вам нужно написать пояснительное сообщение. Одно, для себя, просто чтобы, если что, позже иметь возможность вспомнить, что делалось в тот день. И все, "за кадром" создается новая версия (на самом деле, конечно же, не сохраняется новая копия вашего документа - система хранит список изменений, которые вы сделали). То же самое повторяется во вторник, и появляется третья версия, и опять-таки, сохраняется список изменений, сделанных во вторник. И теперь, если вы понимаете, что все сделанное в понедельник нужно забыть как страшный сон, то вам всего лишь надо вызвать команду, которая применит набор изменений вторника к версии, которая существовала после той недели.

Я, конечно, описал идиллическую картину. Могут и проблемы возникнуть при таком слиянии, если одни изменения накладываются на другие. Но плюсов у системы контроля версий больше, чем минусов. Главное, приучить себя после каждого изменения писать кратенькую сопроводительную заметку. И вот бывает, что мне, например, становится очень важно посмотреть список изменений, которые я внес в программу в среду три недели тому назад. И у меня эта возможность есть.

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

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

Что собой представляет собой такая система? Грубо говоря, имеется некоторый сервер в интернете или локальной сети, на котором хранится вся история разработки. Начиная утром работать с проектом, вы получаете последние исправления (операция pull). Когда же вы что-то сделали, вы закидываете это в проект (операция push). Тем самым, другие участники разработки смогут позже получить то, что сделали вы.

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

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

Хранилище в 1с

Одно из тех мест, где программист встречается с системой контроля версий, это хранилище в . Хоть кое-чего там не хватает (например, веток), но оно вполне себе представляет систему контроля версий.

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

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

net films

Система контроля версий git

Для своих программ, написанных на C++ и Wolfram Mathematica я использую систему контроля версий git. Есть еще одна конкурирующая система, mercurial, и проведено множество "священных войн" на эту тему, но поскольку mercurial я в глаза не видел, то ничего добавить не могу. git меня устраивает полностью, хоть я и единственный разработчик своих программ. Сначала потребовалась некоторая самодисциплина для того чтобы писать сопроводительное сообщение к каждому изменению, но теперь мне уже сложно без git, и я подумываю чтобы перевести все включая свои сайты на эту систему. Попробую перечислить те плюсы, что мне дает git

  • Четкое знание того, что и когда я делал. Возможность вернуть полезный кусок кода, который был удален, а теперь пригодился по прошествии нескольких месяцев;
  • Понимание изменений, которые я сделал. При подготовке новой версии к релизу, мне очень просто перечислить список новшеств;
  • Удобный перенос программы с одного компьютера на другой и на сервера. Возможность легко делиться последними разработками с теми, кто ждет их (им подключается режим чтения на репозиторий, и они отслеживают ветку для разработок);
  • Поиск ошибки. Иногда обнаруживаешь, что ошибка закралась где-то среди последней сотни коммитов (изменение). Поиск бисекцией позволяет быстро найти ее;
  • Разные ветки разработки для разных версий, при этом имеется возможность копировать полезные коммиты из одной в другую (cherry-pick).
  • На этом, мне кажется, пора заканчивать. Надеюсь, что статья была интересной и познавательной не только для тех, кто уже бы когда-то связан с системами контроля версий.

    ← Видео по сетиСмена android телефона →
    comments powered by Disqus