Контроль версій: Чому не можна без неї жити

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

Для окремих розробників вже є завдання відстежувати різні версії програми, не кажучи вже про всі різні резервні копії, які ви можете зробити.

А тепер уявіть, що ви працюєте як команда над проектом, що включає текст, мультимедіа та кодування – коротше кажучи, різноманітну інформацію в роботах.

Уявіть далі: скажімо, кожен файл даних чи програм працює над декількома людьми (“паралельність”) – кожен додає, зберігає, редагує та зберігає знову. Як на землі ви дізнаєтесь, хто робив що, коли і чому, і зможете відстежувати всі ці зміни?

Вам потрібен контроль версій (VC).

У цій статті ми розглянемо, що таке управління версіями та як воно розвивалося протягом багатьох років, починаючи з останнього покоління.

Зокрема, ми розглянемо Git, все більш популярну програму контролю версій від людей, які створили Linux, і побачимо кілька прикладів того, як ти використовуєш Git, щоб відновити контроль над усіма цими різними версіями своїх файлів..

Буквар для VC Jargon

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

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

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

Щоб поекспериментувати з репо, не ризикуючи проблемами чи пошкодженнями, ви можете створити гілку, тобто копію репо, потім можна паралельно змінювати. Якщо зміни у гілці задовільні, ви можете потім об’єднати гілку з основним репо (головним) або навіть іншою гілкою.

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

Еволюція систем управління версіями

Інструменти контролю версій з’явилися в трьох поколіннях, кожне покоління додало гнучкості та можливостей для одночасності.

Перше покоління

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

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

Друге покоління

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

CVS (система паралельних версій) – це один екземпляр і дозволяє взаємодія клієнт / сервер із використанням сховища. SVN (або Apache Subversion повністю), можливо, найпопулярніша з усіх систем управління версіями, що застосовуються сьогодні.

SVN можна розглядати як перероблення CVN із сучасним фундаментом та рішеннями колишніх обмежень CVS.

Третє покоління

Також відомий як DVCS (Системи управління розподіленими версіями), з можливістю розділяти операції злиття та здійснення, одним з найвідоміших прикладів є Git.

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

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

Як виглядають описані вище операції при використанні системи контролю реального життя версій?

Тут ми беремо приклад, використовуючи командний рядок Linux. По-перше, ми створюємо сховище Git для каталогу, в якому ми зараз перебуваємо. Ми використовуємо команду pwd, щоб побачити, де ми:

1
2

$ pwd

/ Користувачі / HJ / Настільний / репозиції / додатки

Потім ми використовуємо команду git init для створення сховища (“головного” сховища) і повернення підтвердження від Git:

1
2

$ git init

Ініціалізоване порожнє сховище Git у /Users/HJ/Desktop/repos/apps/.git

Припустимо, ми додамо новий файл main.c в наш робочий каталог. Використання команди git status надає нам таку інформацію:

1
2
3
4
5
6
7
8
9

$ git статус

# Про майстра відділення
#
# Початкова комісія
#
# Невизначені файли:
# (Використання "git add …" включити до того, що буде вчинено)
#
# Main.c

Ми використовуємо git add для відстеження файлу main.c

1 $ git додати main.c

Ми використовуємо git commit з повідомленням (опція -m) про те, що ми робимо для внесення змін у файл main.c.

1 $ git зобов’язати -м "додавання main.c до сховища"

Тепер ми можемо створити гілку (наприклад, “тест”) за допомогою команди гілки git:

1 $ git тест гілки

Знову використовуючи команду гілки git самостійно, просто перелічує сховища, які ми маємо:

1
2
3

$ git гілка

тест

* майстер

Нарешті, щоб почати працювати в гілці “тестування” над копією main.c зараз у цій гілці, ми використовуємо команду git checkout, щоб отримати підтвердження того, що зараз ми працюємо у гілці “test”..

1
2

$ git тест на замовлення

Переключився на гілку "тест"

Щоб повернутися до гілки “master”, просто знову скористайтеся командою git checkout:

1
2

$ git майстер оформлення замовлення

Переключився на гілку "майстер"

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me