Системи управління версіями

Я дивуюся, скільки електронників не використовує системи управління версіями в своїх розробках. Я сам був таким, поки не спробував. Тепер кожен проект я починаю зі створення сховища.

Що це таке?

Отже, системи управління версіями (СУВ) - це така програма, яка дозволяє зберігати всю історію розробки проекту.

Навіщо це потрібно?

Це - дуже, прямо мега-зручний інструмент для розробки. Буває так, що ви писали-писали програму і, нарешті, щось зламали. Якщо програма перебувала в системі управління версіями, можна легко відкотитися до минулій версії проекту і подивитися, що змінювалося, мене це багато раз рятувало.

Наприклад, недавно у мене почали падати обмеження по швидкості в проекті на FPGA. Я буквально за 5 хвилин знайшов версію, в якій вони ще не падали і знайшов в чому причина

Якщо над проектом працює кілька людей, без СУВ працювати взагалі практично неможливо - починається хаос, кожен робить щось своє і не зрозуміло, хто і що наробив. З СУВ можна зручно подивитися хто і що зробив, зміни внесені іншими стають набагато менш несподіваними.

Крім того, є більш екзотичні застосування. Наприклад, зміни цього сайту я передаю на сервер за допомогою системи контролю версій.

Яку вибрати?

Систем контролю версій існує величезна безліч. Особисто я для себе вибрав Mercurial. Відмінна система, яку всім рекомендую - швидка, кросплатформенних, з відмінним графічним клієнтом. Дуже вагомим аргументом на її користь виявилося існування сайту bitbucket. Я жодного разу не пошкодував про вибір.

Крім Mercurial, зараз досить поширені git і svn. Git більше поширений в близько linux'овской тусовці, svn - в корпоративному середовищі. Я їх спробував використовувати (правда, дуже недовго), але нічого такого, через що варто було б кидати mercurial я не побачив.

Є такий сайт bitbucket.org. на ньому можна зберігати ваші проекти. Він примітний тим, що там, на відміну від github можна безкоштовно створювати закриті репозиторії (репозиторій - місце, де зберігається проекти). Платити потрібно тільки за ті проекти, які закриті і над якими працює більше, ніж 5 осіб. При цьому, ліміт можна розширити до 8ми, розсилаючи запрошення. Я, поки, не перевищував цього ліміту. Крім цього, є wiki і багтрекер, взагалі, все, що потрібно для розробки проектів.

Коли я починав з ним працювати, сайт підтримував тільки Mercurial (частково через це, я і вибрав mercurial), але зараз там можна створювати і git-репозиторії. Крім того, до bitbucket можна прив'язати свій домен. Ось, наприклад, мій варіант: hg.bsvi.ru

Як почати?

Спочатку потрібно завантажити клієнт. Я використовую tortoiseHg. Думаю, з установкою проблем не виникне.

Після установки, непогано б поставити ім'я користувача за замовчуванням. Для цього, потрібно відредагувати файл С: /Users/BSVi/mercurial.ini туди потрібно додати рядок

Природно, bsvi потрібно замінити на ваше ім'я.

Тепер ми готові створити проект і почати щось робити. Для цього на bitbucket.org тиснемо «Create repository»:

Там заповнюємо назва, опис, вибираємо мову. Можна додати wiki і багтрекер.

Тепер тиснемо на кнопку «clone» і копіюємо те, що там з'явилося:

Подальші операції залежать від того, який файловий менеджер ви використовуєте. Особисто я використовую far. Я просто вставляю скопійоване рядок в командного рядка:

Якщо ви іспольуете провідник (ем), total commander або щось в такому дусі, то потрібно натиснути правою кнопкою мишки і вибрати:

Там, в поле source потрібно вставляти шлях, природно, без hg clone:

Вас запитають про ваш пароль, і з'явиться директорія test-repo, в якій, власне і буде перебувати проект.

Додамо трохи файлів

Якщо у вас вже є напрацювання за проектом, їх можна просто скопіювати в директорію. Ми-ж, для навчальних цілей, створимо файл main.c з ось таким вмістом:

Тепер зробимо Ком. Комміт - це внесення змін до проекту. Для цього запускаємо hg workbench. Я просто пишу в командному рядку thg, для експлорерообразних файлових менеджерів потрібно натиснути ПКМ-> Hg Workbench.

Навпаки нашого файлу буде знак питання (це означає, він не доданий в проект). Поставимо біля нього галочку і напишемо опис того, що було зроблено:

Природно, після цього, тиснемо кнопку «commit».

Все, зміни в проект внесено. Тут потрібно звернути увагу, що зміни внечени тільки на локальному комп'ютері (тобто, їх ще немає на сервері). Для того, щоб перенести зміни на сервер, потрібно натиснути кнопку «push», ось вона:

Природно, для проштовхування змін на сервер, потрібно пароль.

змінимо файл

Тепер давайте подивимося, одну з дуже важливих фішок систем контролю версій - відстеження версій файлів. Додамо до нашої програми висновок на екран:

Перейдемо в hg workbench. Я коли працюю над проектом його навіть не закриваю (про це-далі), натискаємо f5 щоб оновити список файлів. Тепер видно, що змінилося з часу останнього коммітов:

І це - дуже сильний інструмент. Зазвичай, під час налагодження в файлах з'являється купа різного сміття. Дак от, переглядаючи те, що ви збираєтеся закоммітіть дуже непогано очищає від сміття проект.

А що робити зі сміттям?

При роботі над проектом з'являється дуже багато сміття - наприклад, об'єктні файли, файли, які генерує IDE, якісь тимчасові файли, ітп. Все, то, що не відноситься до самого проекту, непогано б прибрати з сховища. Для цього існує файл .hgignore (так, з точкою на початку назви).

Додамо сміттєвий файл до проекту. Я, наприклад, створив main.obj:

Якщо зараз оновити список файлів, то, природно, hg workbench запропонує додати цей файл в проект:

Тепер, створимо файл .hgigonre і напишемо там, що ми хочемо ігнорувати всі файли з розширенням obj:

Якщо оновити список файлів, то obj файли пропадуть, зате з'явиться файл .hgignore, який можна закоммітіть:

А як відкотити зміни?

Відновимо нашу програму до того стану, який був до виведення на екран. Для цього достатньо вибрати Комміт, до якого хочеться відкотитися і натиснути ось цю кнопку:

Точно практично так-же можна відкотити окремий файл.

висновок

Ось і все, це - мінімум знань про системи контролю версій, який дозволить вам зберігати історію розробки проекту. Природно, є дуже багато інших можливостей, про які я розповім пізніше.

Багато хто думає, що системи контролю версій потрібно використовувати тільки якщо розробляєш щось великим натовпом, але це - не так :) Навіть коли працюєш над проектом поодинці, системи контролю версій сильно виручають.

Для прикладу, ось скріншот мого UTC (який я розробляю сам) в найскладнішому місці в hg workbench: