Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы 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\”), в которой и должны храниться все файлы нашего будущего проекта. Разумеется, никто не запрещает иметь несколько репозиториев на одном компьютере.
Чтобы система «поняла», что мы хотим создать репозиторий, выполняем команду:
после которой будет создана папка “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’у. Выполняется он следующей командой:
Разберем все по порядку. Команда должна вводиться тогда, когда мы находимся в репозитории (то есть предварительно необходимо выполнить “cd c:\project”). Опция “-A” необходима для того, чтобы Mercurial «подхватил» свежесозданные файлы (см. выше), опция “-m” позволяет добавить к commit’у комментарий. Эти комментарии будут отображаться при просмотре версий (или changeset’ов – списков изменений) в TortoiseHg и на странице проекта в bitbucket.org. Очень важно давать осмысленные комментарии, чтобы потом не мучаться, вспоминая, когда же была сделана та или иная правка.
Теперь в нашем репозитории хранится начальная версия нашего проекта. Все дальнейшие commit’ы выполняются аналогично после того, как мы решим, что пора бы сохранить текущую версию.
Сделанный commit можно «втолкнуть» в удаленный репозиторий командой:
При этом также необходимо находиться в папке, соответствующей репозиторию. После ввода команды будет запрошено имя и пароль нашей учетки на bitbucket.org, чтобы не вводить их при каждом push’е команду можно заменить на следующую:
Так как все команды мы забьем в *.bat файл, в этом случае пароль будет храниться в открытом виде, что представляет собой некоторую угрозу безопасности, однако для меня это приемлемо.
Итак, для удобства создаем в зоне прямой досягаемости файлы commit.bat, push.bat и commit&push.bat со следующим содержанием:
[содержание файла commit.bat]
Этот файл, вызванный с аргументами, выполнит commit проекта с занесением аргументов в комментарии к commit’у. Пример: выполняем “commit.bat my first commit” и получаем commit с комментарием «my first commit». В FAR’е для этого удобно использовать сочетание Ctrl+Enter.
[содержание файла push.bat]
Этот файл произведет push в удаленный репозиторий.
[содержание файла commit&push.bat]
Этот файл, вызванный с аргументами, выполнит последовательный commit и push проекта с занесением аргументов в комментарии к commit’у.
Кроме того, для мелких промежуточных commit’ов я рекомендую создать файл commit_date_time.bat:
[содержание файла commit_date_time.bat]
Этот файл произведет 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. Перенес в блог «Системы управления версиями».
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.
Зачем это нужно
Сам я являюсь студентом технического ВУЗа и практически постоянно работаю с документами (текстами, рисунками, чертежами), изменяя их по три (десять, сто) раз на дню. Порой получается так, что правки, сделанные в течение последней недели, необходимо отменить и вернуться к документам в состоянии недельной давности. Хорошо, если правок было сделано немного, в этом случае могут помочь полсотни ударов по 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:\projecthg 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. Перенес в блог «Системы управления версиями».