Skip to content
This repository
Browse code

повністю перекладено uk/intro.txt

  • Loading branch information...
commit 177c97a9c27e1bca4e4d6f011144c12bf569d55a 1 parent b4fc2b5
Volodymyr Bodenchuk VBoden authored

Showing 1 changed file with 57 additions and 0 deletions. Show diff stats Hide diff stats

  1. +57 0 uk/intro.txt
57 uk/intro.txt
... ... @@ -0,0 +1,57 @@
  1 +== Вступне слово ==
  2 +
  3 +Щоб пояснити, що таке управління версіями, я буду використовувати аналогії. Якщо потрібно більш точне пояснення, зверніться до http://uk.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%96%D0%BD%D0%BD%D1%8F_%D0%B2%D0%B5%D1%80%D1%81%D1%96%D1%8F%D0%BC%D0%B8[статті вікіпедії].
  4 +
  5 +=== Робота - це гра ===
  6 +
  7 +Я грав в комп’ютерні ігри майже все своє життя. А ось використовувати системи управління версіями почав вже будучи дорослим. Вважаю, я такий не один, і порівняння цих двох занять може допомогти поясненню і розумінню концепції.
  8 +
  9 +Уявіть, що редагування коду або документа - гра. Далеко просунувшись, ви захочете зберегтися. Для цього ви натиснете на кнопку „Зберегти“ у вашому улюбленому редакторі.
  10 +
  11 +Але це перезапише стару версію. Це як в стародавніх іграх, де був тільки один слот для збереження: звичайно, ви можете зберегтися, але ви більше ніколи не зможете повернутися до попереднього стану. Це прикро, оскільки колишнє збереження могло вказувати на одне з дуже цікавих місць у грі, і може бути, одного разу ви захочете повернутися до нього. Або, що ще гірше, ви зараз перебуваєте в безвиграшному становищі і змушені починати заново.
  12 +
  13 +=== Керування версіями ===
  14 +
  15 +Під час редагування ви можете «Зберегти як ...» в інший файл, або скопіювати файл абикуди перед збереженням, щоб уберегти більш старі версії. Можливо, заархівувавши їх для економії місця на диску. Це найпримітивніший вид керування версіями, до того ж він вимагає інтенсивної ручної роботи. Комп'ютерні ігри пройшли цей етап давно, у більшості з них є безліч слотів для збереження з автоматичними тимчасовими мітками.
  16 +
  17 +Давайте трохи ускладнимо умови. Нехай у вас є кілька файлів, використовуваних разом, наприклад, вихідний код проекту або файли для вебсайту. Тепер, щоб зберегти стару версію, ви повинні скопіювати весь каталог. Підтримка безлічі таких версій вручну незручна і швидко стає дорогим задоволенням.
  18 +
  19 +У деяких іграх збереження - це і є каталог з купою файлів всередині. Ігри приховують деталі від гравця і надають зручний інтерфейс для управління різними версіями цього каталогу.
  20 +
  21 +У системах управління версіями все точно так само. У них у всіх є приємний інтерфейс для управління каталогом з вашим скарбом. Можете зберігати стан каталога так часто, як забажаєте, а потім відновити будь-яку з попередніх збережених версій. Але, на відміну від комп'ютерних ігор, вони істотно економлять дисковий простір. Зазвичай від версії до версії змінюється тільки кілька файлів, і то ненабагато. Зберігання лише відмінностей замість повних копій вимагає менше місця.
  22 +
  23 +=== Розподілене керування ===
  24 +
  25 +А тепер уявіть дуже складну комп’ютерну гру. Її настільки складно пройти, що безліч досвідчених гравців по всьому світу вирішили об'єднатися і використовувати загальні збереження, щоб спробувати виграти. Проходження на швидкість — живий приклад. Гравці, що спеціалізуються на різних рівнях гри, об’єднуються, щоб в результаті отримати приголомшливий результат.
  26 +
  27 +Як би ви організували таку систему, щоб гравці змогли легко отримувати збереження інших? А завантажувати свої?
  28 +
  29 +У минулі часи кожен проект використовував централізоване управління версіями. Який-небудь сервер зберігав всі збережені ігри. І ніхто більше. Кожен тримав лише кілька збережень на своїй машині. Коли гравець хотів пройти трохи далі, він викачував найостанніше збереження з головного сервера, грав небагато, зберігався і закачував вже своє збереження назад на сервер, щоб інші могли ним скористатися.
  30 +
  31 +А що якщо гравець з якоїсь причини захотів використовувати більш стару збережену гру? Можливо, нинішнє збереження безвиграшне, бо хтось забув взяти якийсь ігровий предмет ще на третьому рівні, і потрібно знайти останнє збереження, де гру все ще можна закінчити. Або, можливо, хочеться порівняти дві більш старі збережені гри, щоб встановити внесок конкретного гравця.
  32 +
  33 +Може бути багато причин повернутися до більш старої версії, але вихід один: потрібно запросити ту стару збережену гру у центрального сервера. Чим більше збережених ігор потрібно, тим більше знадобиться зв’язуватися з сервером.
  34 +
  35 +Системи управління версіями нового покоління, до яких відноситься Git, відомі як розподілені системи, їх можна розуміти як узагальнення централізованих систем. Коли гравці завантажуються з головного сервера, вони отримують кожну збережену гру, а не тільки останню. Вони як би дзеркалюють центральний сервер.
  36 +
  37 +Ці початкові операції клонування можуть бути ресурсоємними, особливо при довгій історії, але сповна окупаються при тривалій роботі. Найбільш очевидна пряма вигода полягає в тому, що якщо вам навіщось потрібна більш стара версія, взаємодія з сервером не знадобиться.
  38 +
  39 +=== Дурні забобони ===
  40 +
  41 +Широко поширена помилка полягає в тому, що розподілені системи непридатні для проектів, які потребують офіційного централізованого сховища. Ніщо не може бути більш далеким від істини. Отримання фотознімку не призводить до того, що ми крадемо чиюсь душу. Точно так само клонування головного сховища не зменшує його важливість.
  42 +
  43 +У першому наближенні можна сказати, що все, що робить централізована система керування версіями, добре сконструйована розподілена система може зробити краще. Мережеві ресурси просто дорожчі локальних. Хоча далі ми побачимо, що в розподіленому підході є свої недоліки, ви навряд чи помилитеся у виборі, керуючись цим наближеним правилом.
  44 +
  45 +Невеликому проектом може знадобитися лише частинка функціоналу, пропонованого такою системою. Але використання погано масштабованої системи для маленьких проектів подібно використанню римських цифр в розрахунках з невеликими числами.
  46 +
  47 +Крім того, проект може вирости понад початкові очікування. Використовувати Git з самого початку — це як тримати напоготові швейцарський ніж, навіть якщо ви всього лише відкриваєте ним пляшки. Одного разу вам шалено знадобиться викрутка і ви будете раді, що під рукою є щось більше, ніж проста відкривачка.
  48 +
  49 +=== Конфлікти при злитті ===
  50 +
  51 +Для цієї теми аналогія з комп'ютерною грою стає занадто натягнутою. Замість цього, давайте повернемося до редагування документа.
  52 +
  53 +Отже, припустимо, що Галя вставила рядок на початку файлу, а Тарас — в кінці. Обоє вони закачують свої зміни. Більшість систем автоматично зробить розумний висновок: прийняти і з'єднати їх зміни так, щоб обидві правки — і Галі, і Тараса — були застосовані.
  54 +
  55 +Тепер припустимо, що і Галя, і Тарас внесли різні зміни в один і той же рядок. У цьому випадку неможливо продовжити без втручання людини. Той із них, хто другим закачає на сервер зміни, буде поінформований про _конфлікте злиття_ (_merge conflict_), і повинен або віддати перевагу однієї змінни іншій, або скорегувати увесь рядок.
  56 +
  57 +Можуть траплятися і більш складні ситуації. Системи управління версіями вирішують прості ситуації самі і залишають складні для людини. Зазвичай таку їхню поведінку можна налаштовувати.

0 comments on commit 177c97a

Please sign in to comment.
Something went wrong with that request. Please try again.