finished translations of some files
authorВолодимир Боденчук <Bodenchuk@bigmir.net>
Sun, 16 Dec 2012 14:09:31 +0000 (16 16:09 +0200)
committerВолодимир Боденчук <Bodenchuk@bigmir.net>
Sun, 16 Dec 2012 14:09:31 +0000 (16 16:09 +0200)
uk/basic.txt
uk/branch.txt
uk/clone.txt
uk/intro.txt
uk/preface.txt
uk/translate.txt

index 5852c98..81aec72 100644 (file)
@@ -31,7 +31,7 @@
 
 Git видалить ці файли, якщо ви не видалили їх самі.
 
-Перейменування файлу - це те ж саме, що й видалення старого імені та додавання нового. Для цього є *git mv*, яка має той же синтаксис, що і команда *mv*. наприклад:
+Перейменування файлу — це те ж саме, що й видалення старого імені та додавання нового. Для цього є *git mv*, яка має той же синтаксис, що і команда *mv*. Наприклад:
 
  $ git mv bug.c feature.c
 
@@ -41,23 +41,23 @@ Git видалить ці файли, якщо ви не видалили їх 
 
  $ git log
 
-покаже список останніх коммітов і їх хеші SHA1:
+покаже список останніх коммітів і їхні хеші SHA1:
 
 ----------------------------------
 commit 766f9881690d240ba334153047649b8b8f11c664
-Author: Bob <bob@example.com>
+Author: Іван <ivan@example.com>
 Date:   Tue Mar 14 01:59:26 2000 -0800
 
     Замінив printf() на write().
 
 commit 82f5ea346a2e651544956a8653c0f58dc151275c
-Author: Alice <alice@example.com>
+Author: Марічка <marichka@example.com>
 Date:   Thu Jan 1 00:00:00 1970 +0000
 
     Початковий комміт.
 ----------------------------------
 
-Для вказівки комміта достатньо перших декількох символів його хешу, але можете скопіювати і весь хеш. Наберіть:
+Щоб вказати комміт, достатньо перших декількох символів його хешу, але можете скопіювати і весь хеш. Наберіть:
 
  $ git reset --hard 766f
 
@@ -69,7 +69,7 @@ Date:   Thu Jan 1 00:00:00 1970 +0000
 
 Ця команда перенесе вас назад у часі, зберігши при цьому більш нові комміти. Однак, як і у фантастичних фільмах про подорожі в часі, якщо тепер ви відредагуєте і закоммітите код, то потрапите в альтернативну реальність, тому що ваші дії відрізняються від тих, що були минулого разу.
 
-Ця альтернативна реальність називається «гілкою» (branch, прим. пер.) і <<branch,трохи пізніше ми поговоримо про це докладніше>>. А зараз просто запам'ятайте, що команда
+Ця альтернативна реальність називається «гілкою» (branch) і <<branch,трохи пізніше ми поговоримо про це докладніше>>. А зараз просто запам'ятайте, що команда
 
  $ git checkout master
 
@@ -108,11 +108,11 @@ Date:   Thu Jan 1 00:00:00 1970 +0000
 
 === Створення списку змін ===
 
-Деяким проектам потрібен http://en.wikipedia.org/wiki/Changelog[списку змін] (changelog, прим. пер.). Створіть його такою командою:
+Деяким проектам потрібен http://en.wikipedia.org/wiki/Changelog[спискок змін (changelog)]. Створіть його такою командою:
 
  $ git log > ChangeLog
 
-=== Скачування файлів ===
+=== Завантаження файлів ===
 
 Отримати копію проекту під управлінням Git можна, набравши
 
@@ -180,11 +180,11 @@ Date:   Thu Jan 1 00:00:00 1970 +0000
 
 === Вправа ===
 
-Нехай A, B, C, D - чотири послідовні комміти, де В відрізняється від A лише кількома видаленими файлами. Ми хочемо повернути ці файли в D. Як ми можемо це зробити?
+Нехай A, B, C, D  чотири послідовні комміти, де В відрізняється від A лише кількома видаленими файлами. Ми хочемо повернути ці файли в D. Як ми можемо це зробити?
 
 Існує як мінімум три розв’язки. Припустимо, що ми знаходимося на D.
 
-  1. Різниця між A і B - видалені файли. Ми можемо створити патч, що відображає ці зміни, і застосувати його:
+  1. Різниця між A і B  видалені файли. Ми можемо створити патч, що відображає ці зміни, і застосувати його:
 
    $ git diff B A | git apply
 
index 46afd66..4b42df4 100644 (file)
@@ -1,16 +1,16 @@
 == Чудеса розгалуження == 
 
-Можливості миттєвого розгалуження і злиття - найкращі особливості Git.
+Можливості миттєвого розгалуження і злиття  найкращі особливості Git.
 
-*Завдання*: зовнішні фактори неминуче тягнуть переключення уваги. Серйозна помилка в уже випущеній версії виявляється без попередження. Термін здачі певної функціональності наближається. Розробник, допомога якого потрібна вам в роботі над ключовою частиною проекту, збирається у відпустку. Одним словом, вам потрібно терміново кинути все, над чим ви працюєте в даний момент, і переключитися на зовсім інші завдання.
+*Завдання*: зовнішні фактори неминуче потребують переключення уваги. Серйозна помилка в уже випущеній версії виявляється без попередження. Термін здачі певної функціональності наближається. Розробник, допомога якого потрібна вам в роботі над ключовою частиною проекту, збирається у відпустку. Одним словом, вам потрібно терміново кинути все, над чим ви працюєте в даний момент, і переключитися на зовсім інші завдання.
 
-Переривання ходу ваших думок може серйозно знизити ефективність роботи, і чим складніше перемикання між процесами, тим більшою буде втрата. При централізованому управлінні версіями ми змушені завантажувати свіжу робочу копію з центрального сервера. Розподілена система краще: ми можемо клонувати потрібну версію локально.
+Переривання ходу ваших думок може серйозно знизити ефективність роботи, і чим складніше перемикання між процесами, тим більшою буде втрата. При централізованому керуванні версіями ми змушені завантажувати свіжу робочу копію з центрального сервера. Розподілена система краще: ми можемо клонувати потрібну версію локально.
 
-Проте клонування все ж передбачає копіювання всього робочого каталогу, як і всієї історії змін до теперішнього моменту. Хоча Git і знижує витратність цієї дії за рахунок можливості спільного використання файлів і жорстких посилань, але всі файли проекту доведеться повністю відтворити в новому робочому каталозі.
+Проте клонування все ж передбачає копіювання всього робочого каталогу, як і всієї історії змін до теперішнього моменту. Хоча Git і знижує затратність цієї дії за рахунок можливості спільного використання файлів і жорстких посилань, але всі файли проекту доведеться повністю відтворити в новому робочому каталозі.
 
-*Розв'язання*: у Git є більш зручний інструмент для таких випадків, який заощадить і час, і дисковий простір в порівнянні з клонуванням - це *git branch* (branch - гілка, прим. пер.).
+*Розв'язання*: у Git є більш зручний інструмент для таких випадків, який заощадить і час, і дисковий простір в порівнянні з клонуванням — це *git branch* (branch — гілка, прим. пер.).
 
-Цим чарівним словом файли в вашому каталозі миттєво перетворяться від однієї версії до іншої. Ця зміна дозволяє зробити набагато більше, ніж просто повернутися назад або просунутися вперед в історії. Ваші файли можуть зміниться з останньої випущеної версії на експериментальну, з експериментальної - на поточну версію у розробці, з неї - на версію вашого друга і так далі.
+Цим чарівним словом файли в вашому каталозі миттєво перетворяться від однієї версії до іншої. Ця зміна дозволяє зробити набагато більше, ніж просто повернутися назад або просунутися вперед в історії. Ваші файли можуть зміниться з останньої випущеної версії на експериментальну, з експериментальної — на поточну версію у розробці, з неї — на версію вашого друга і так далі.
 
 === Кнопка боса ===
 
 
  $ git checkout -b part2 # частина2
 
-Потім працюйте над другою частиною, попутно вносячи комміти ваших змін. Людині властиво помилятися, і часто ви хочете повернутися і поправити щось в першій частині. Якщо ви везучі або дуже вправні, можете пропустити ці рядки.
+Потім працюйте над другою частиною, попутно вносячи комміти ваших змін. Людині властиво помилятися, і часто ви схочете повернутися і поправити щось в першій частині. Якщо ви везучі або дуже вправні, можете пропустити ці рядки.
 
  $ git checkout master  # Повертаємося до першої частини.
  $ вносимо_зміни
  $ git merge part2      # Вливаємо другу частину.
  $ git branch -d part2  # Видаляємо гілку part2.
 
-Тепер ви знову в гілці master, а друга частина - у вашому робочому каталозі.
+Тепер ви знову в гілці master, а друга частина  у вашому робочому каталозі.
 
-Цей прийом легко розширити на будь-яку кількість частин. Настільки ж легко змінити гілку заднім числом. Припустимо, ви надто пізно виявили, що повинні були створити гілку сім коммітов назад. Тоді введіть:
+Цей прийом легко розширити на будь-яку кількість частин. Настільки ж легко змінити гілку заднім числом. Припустимо, ви надто пізно виявили, що повинні були створити гілку сім коммітів назад. Тоді введіть:
 
  $ git branch -m master part2 # Перейменовуємо гілку master в part2.
  $ git branch master HEAD~7   # Створюємо нову гілку master сімома коммітами вище.
 
-Тепер гілка master містить тільки першу частину, а гілка part2 - все інше. В останній ми і знаходимося. Ми створили гілку master, не перемикаючись на неї, тому що хочемо продовжити роботу над part2. Це незвично: досі ми переключалися на гілки відразу ж після їх створення, ось так:
+Тепер гілка master містить тільки першу частину, а гілка part2  все інше. В останній ми і знаходимося. Ми створили гілку master, не перемикаючись на неї, тому що хочемо продовжити роботу над part2. Це незвично: досі ми переключалися на гілки відразу ж після їх створення, ось так:
 
  $ git checkout HEAD~7 -b master  # Створюємо гілку і переключаємося на неї.
 
 
 Опції *-d* і *-m* дозволяють видаляти і переміщати (перейменовувати) гілки. Дивіться *git help branch*.
 
-Гілка ``master'' - це зручна традиція. Інші можуть припускати, що у вашому сховищі є гілка з таким ім'ям і що вона містить офіційну версію проекту. Хоча ви можете перейменувати або знищити гілку ``master'', краще дотриматися загальної угоди.
+Гілка ``master''  це зручна традиція. Інші можуть припускати, що у вашому сховищі є гілка з таким ім'ям і що вона містить офіційну версію проекту. Хоча ви можете перейменувати або знищити гілку ``master'', краще дотриматися загальної угоди.
 
 === Тимчасові гілки ===
 
-Через якийсь час ви можете виявити, що створюєте безліч тимчасових віток для однієї і тієї ж короткострокової мети: кожна така гілка всього лише зберігає поточний стан, щоб ви могли повернутися назад і виправити серйозну помилку або зробити щось ще.
+Через якийсь час ви можете виявити, що створюєте безліч тимчасових гілок для однієї і тієї ж короткострокової мети: кожна така гілка лише зберігає поточний стан, щоб ви могли повернутися назад і виправити серйозну помилку або зробити щось ще.
 
 Це схоже на те, як ви перемикаєте телевізійні канали, щоб подивитися що показують по іншим. Але замість того, щоб натиснути на пару кнопок, вам потрібно створювати, вибирати (checkout), зливати (merge) а потім видаляти тимчасові гілки. На щастя, в Git є скорочена команда, настільки ж зручна, як пульт дистанційного керування.
 
 
 Поглянемо на веб-браузери. Навіщо потрібна підтримка вкладок на додаток до вікон? Підтримка і тих, і інших дозволяє пристосуватися до широкої різноманітності стилів роботи. Деяким користувачам подобається тримати відкритим єдине вікно і використовувати вкладки для безлічі веб-сторінок. Інші можуть впасти в іншу крайність: безліч вікон без вкладок взагалі. Треті віддадуть перевагу чомусь середньому.
 
-Гілки схожі на вкладки для робочого каталогу, а клони - на нові вікна браузера. Ці операції швидкі і виконуються локально, так чому б не поекспериментувати і не знайти найбільш зручну для себе комбінацію? Git дозволяє працювати в точності так, як вам подобається.
+Гілки схожі на вкладки для робочого каталогу, а клони — на нові вікна браузера. Ці операції швидкі і виконуються локально, так чому б не поекспериментувати і не знайти найбільш зручну для себе комбінацію? Git дозволяє працювати в так, як вам подобається.
index bd25911..1e1bb71 100644 (file)
@@ -1,12 +1,12 @@
 == Все про клонування ==
 
-У старих системах управління версіями стандартна операція для отримання файлів – це checkout. Ви отримуєте набір файлів в конкретному збереженому стані.
+У старих системах керування версіями стандартна операція для отримання файлів — це checkout. Ви отримуєте набір файлів в конкретному збереженому стані.
 
-У Git та інших розподілених системах керування версіями стандартний спосіб  клонування. Для отримання файлів ви створюєте „клон“ всього сховища. Іншими словами, ви фактично створюєте дзеркало центрального сервера. При цьому все, що можна робити з основним сховищем, можна робити і з локальним.
+У Git та інших розподілених системах керування версіями стандартний спосіб  клонування. Для отримання файлів ви створюєте „клон“ всього сховища. Іншими словами, ви фактично створюєте дзеркало центрального сервера. При цьому все, що можна робити з основним сховищем, можна робити і з локальним.
 
 === Синхронізація комп'ютерів ===
 
-Я цілком приймаю створення архівів або використання *rsync* для резервного копіювання і найпростішої синхронізації. Але я працюю то на ноутбуці, то на стаціонарному комп’ютері, які можуть ніяк між собою не взаємодіяти.
+Я терпимий до створення архівів або використання *rsync* для резервного копіювання і найпростішої синхронізації. Але я працюю то на ноутбуці, то на стаціонарному комп’ютері, які можуть ніяк між собою не взаємодіяти.
 
 Створіть сховище Git і закоммітьте файли на одному комп'ютері. А потім виконайте на іншому
 
@@ -19,7 +19,7 @@
 
 будуть „втягувати“ („pull“) стан файлів з іншого комп'ютера на той, де ви працюєте. Якщо ви нещодавно внесли конфліктуючі зміни в один і той же файл, Git дасть вам знати, і потрібно буде зробити комміт заново після вирішення ситуації.
 
-=== Класичне управління вихідним кодом ===
+=== Класичне керування вихідним кодом ===
 
 Створіть сховище Git для ваших файлів:
 
@@ -38,7 +38,7 @@
 
  $ git daemon --detach # можливо вже запущений
 
-Для створення нового порожнього сховища Git на публічних серверах виконуйте їхні інструкції. Зазвичай, потрібно заповнити форму на веб-сторінці.
+Для створення нового порожнього сховища Git на публічних серверах виконуйте їх інструкції. Зазвичай, потрібно заповнити форму на веб-сторінці.
 
 Відправте ваші зміни в центральне сховище ось так:
 
 Для проектів із закритим вихідним кодом опустіть команди доступу і переконайтеся, що ви ніколи не
 створювали файл з ім'ям `git-daemon-export-ok`. Сховище вже не може бути
 доступним через протокол Git; тільки ті, хто має доступ SSH можуть побачити його. Якщо всі
-ваша репозиторії закриті, немає необхідності запускати демон Git оскільки всі
+ваші репозиторії закриті, немає необхідності запускати демон Git оскільки всі
 зв’язки відбувається через SSH.
 
 === Голі сховища (Bare repositories) ===
 
-Голе сховище називаються так тому, що у нього немає робочого каталогу. Воно містить лише файли, які зазвичай приховані в підкаталозі `.git`. Іншими словами, голе сховище містить історію змін, але не містить знімка якоїсь певної версії.
+Голе сховище називається так тому, що у нього немає робочого каталогу. Воно містить лише файли, які зазвичай приховані в підкаталозі `.git`. Іншими словами, голе сховище містить історію змін, але не містить знімка якоїсь певної версії.
 
-Голе сховище грає роль, схожу на роль основного сервера в централізованій системі управління версіями: це дім вашого проекту. Розробники клонують з нього проект і закачують в нього свіжі офіційні зміни. Як правило, воно розташовується на сервері, який не робить майже нічого окрім роздачі даних. Розробка йде в клонах, тому домашнє сховище може обійтися і без робочого каталогу.
+Голе сховище грає роль, схожу на роль основного сервера в централізованій системі керування версіями: це дім вашого проекту. Розробники клонують з нього проект і закачують в нього свіжі офіційні зміни. Як правило, воно розташовується на сервері, який не робить майже нічого окрім роздачі даних. Розробка йде в клонах, тому домашнє сховище може обійтися і без робочого каталогу.
 
 Багато команд Git не працюють в голих сховищах, якщо змінна середовища `GIT_DIR` не містить шлях до сховища та не зазначений параметр `--bare`.
 
@@ -93,7 +93,7 @@
 
 Навіщо вводиться команда push, замість використання вже знайомої pull? Перш за все, pull не працює в голих сховищах, замість неї потрібно використовувати команду 'fetch', яка буде розглянута пізніше. Але навіть якщо тримати на центральному сервері нормальне сховище, використання команди pull в ньому буде складним . Потрібно буде спочатку увійти на сервер інтерактивно і повідомити команді pull адресу машини, з якої ми хочемо забрати зміни. Цьому можуть заважати мережеві брандмауери (firewall), але в першу чергу: що якщо в нас немає інтерактивного доступу до сервера?
 
-Тим не менш, не рекомендутся push-ити в сховище крім цього випадку  через плутанину, яка може виникнути, якщо у цільового сховища є робочий каталог.
+Тим не менш, не рекомендутся push-ити в сховище крім цього випадку  через плутанину, яка може виникнути, якщо у цільового сховища є робочий каталог.
 
 Коротше кажучи, поки вивчаєте Git, push-те лише в голі сховища. В інших випадках pull-те.
 
 
 === Максимальні бекапи ===
 
-Хочете мати безліч захищених, географічно відокремлених запасних архівів? Якщо у вашому проекті багато розробників, нічого робити не потрібно! Кожен клон - це і є резервна копія, не тільки поточного стану, але і всієї історії змін проекту. Завдяки криптографічному хешування, пошкодження якого-небудь з клонів буде виявлено при першій же спробі взаємодії з іншими клонами.
+Хочете мати безліч захищених, географічно відокремлених запасних архівів? Якщо у вашому проекті багато розробників, нічого робити не потрібно! Кожен клон  це і є резервна копія, не тільки поточного стану, але і всієї історії змін проекту. Завдяки криптографічному хешування, пошкодження якого-небудь з клонів буде виявлено при першій же спробі взаємодії з іншими клонами.
 
 Якщо ваш проект не такий популярний, знайдіть якомога більше серверів для розміщення клонів.
 
-Тим, що особливо турбуються, рекомендується завжди записувати останній 20-байтний SHA1 хеш HEAD у якомусь безпечному місці. Воно має бути безпечним, а не таємним. Наприклад, хороший варіант – публікація в газеті, тому що атакуючому складно змінити кожен примірник газети.
+Тим, хто особливо турбується, рекомендується завжди записувати останній 20-байтний SHA1 хеш HEAD у якомусь безпечному місці. Воно має бути безпечним, а не таємним. Наприклад, хороший варіант — публікація в газеті, тому що атакуючому складно змінити кожен примірник газети.
 
 === Багатозадачність зі швидкістю світла ===
 
 
  $ git pull /другий/клон HEAD
 
-=== Партизанське управління версіями ===
+=== Партизанське керування версіями ===
 
-Ви працюєте над проектом, який використовує іншу систему управління версіями, і вам дуже не вистачає Git? Тоді створіть сховище Git у своєму робочому каталозі:
+Ви працюєте над проектом, який використовує іншу систему керування версіями, і вам дуже не вистачає Git? Тоді створіть сховище Git у своєму робочому каталозі:
 
  $ git init
  $ git add .
 
  $ git clone . /якийсь/новий/каталог
 
-Тепер перейдіть в цей новий каталог і працюйте в ньому замість основного, використовуючи Git в своє задоволення. У якийсь момент вам знадобитися синхронізувати зміни з усіма іншими – тоді перейдіть в початковий каталог, синхронізуйте його за допомогою іншої системи управління версіями і наберіть
+Тепер перейдіть в цей новий каталог і працюйте в ньому замість основного, використовуючи Git в своє задоволення. У якийсь момент вам знадобитися синхронізувати зміни з усіма іншими — тоді перейдіть в початковий каталог, синхронізуйте його за допомогою іншої системи керування версіями і наберіть
 
  $ git add .
  $ git commit -m "Синхронізація з рештою"
  $ git commit -a -m "Опис моїх змін"
  $ git pull
 
-Процедура передачі змін іншим залежить від іншої системи управління версіями. Новий каталог містить файли з вашими змінами. Запустіть команди іншої системи управління версіями, необхідні для завантаження файлів в центральне сховище.
+Процедура передачі змін іншим залежить від іншої системи керування версіями. Новий каталог містить файли з вашими змінами. Запустіть команди іншої системи керування версіями, необхідні для завантаження файлів в центральне сховище.
 
 Subversion (імовірно, найкраща централізована система керування версіями) використовується незліченною кількістю проектів. Команда *git svn* автоматизує описаний процес для сховищ Subversion, а також може бути використана для http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html[експорту проекту Git в сховище Subversion].
 
 === Mercurial ===
 
-Mercurial  схожа система керування версіями, яка може працювати в парі з Git практично без накладок. З розширенням `hg-git` користувач Mercurial може без будь-яких втрат push-ити і pull-ити зі сховища Git.
+Mercurial  схожа система керування версіями, яка може працювати в парі з Git практично без накладок. З розширенням `hg-git` користувач Mercurial може без будь-яких втрат push-ити і pull-ити зі сховища Git.
 
 Отримати `hg-git` можна за допомогою Git:
 
index 0b999ef..7d4cbe6 100644 (file)
@@ -1,24 +1,24 @@
 == Вступне слово ==
 
-Щоб пояснити, що таке управління версіями, я буду використовувати аналогії. Якщо потрібно більш точне пояснення, зверніться до 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[статті вікіпедії].
+Щоб пояснити, що таке керування версіями, я буду використовувати аналогії. Якщо потрібно більш точне пояснення, зверніться до http://uk.wikipedia.org/wiki/Система_керування_версіями[статті вікіпедії].
 
-=== Робота - це гра ===
+=== Робота  це гра ===
 
-Я грав в комп’ютерні ігри майже все своє життя. А ось використовувати системи управління версіями почав вже будучи дорослим. Вважаю, я такий не один, і порівняння цих двох занять може допомогти поясненню і розумінню концепції.
+Я грав в комп’ютерні ігри майже все своє життя. А ось використовувати системи керування версіями почав вже будучи дорослим. Вважаю, я такий не один, і порівняння цих двох занять може допомогти поясненню і розумінню концепції.
 
-Уявіть, що редагування коду або документа - гра. Далеко просунувшись, ви захочете зберегтися. Для цього ви натиснете на кнопку „Зберегти“ у вашому улюбленому редакторі.
+Уявіть, що редагування коду або документа – гра. Просунувшись далеко, ви захочете зберегтися. Для цього ви натиснете на кнопку „Зберегти“ у вашому улюбленому редакторі.
 
-Але це перезапише стару версію. Це як в стародавніх іграх, де був тільки один слот для збереження: звичайно, ви можете зберегтися, але ви більше ніколи не зможете повернутися до попереднього стану. Це прикро, оскільки колишнє збереження могло вказувати на одне з дуже цікавих місць у грі, і може бути, одного разу ви захочете повернутися до нього. Або, що ще гірше, ви зараз перебуваєте в безвиграшному становищі і змушені починати заново.
+Але це перезапише стару версію. Це як в стародавніх іграх, де був тільки один слот для збереження: звичайно, ви можете зберегтися, але ви більше ніколи не зможете повернутися до попереднього стану. Це прикро, оскільки попереднє збереження могло вказувати на одне з дуже цікавих місць у грі і, можливо, одного разу ви захочете повернутися до нього. Або, що ще гірше, ви зараз перебуваєте у безвиграшному становищі і змушені починати заново.
 
 === Керування версіями  ===
 
-Під час редагування ви можете «Зберегти як ...» в інший файл, або скопіювати файл абикуди перед збереженням, щоб уберегти більш старі версії. Можливо, заархівувавши їх для економії місця на диску. Це найпримітивніший вид керування версіями, до того ж він вимагає інтенсивної ручної роботи. Комп'ютерні ігри пройшли цей етап давно, у більшості з них є безліч слотів для збереження з автоматичними тимчасовими мітками.
+Під час редагування ви можете „Зберегти як ...“ в інший файл або скопіювати файл куди-небудь перед збереженням, щоб уберегти більш старі версії. Можливо, заархівувавши їх для економії місця на диску. Це найпримітивніший вид керування версіями, до того ж він вимагає інтенсивної ручної роботи. Комп'ютерні ігри пройшли цей етап давно, у більшості з них є безліч слотів для збереження з автоматичними тимчасовими мітками.
 
 Давайте трохи ускладнимо умови. Нехай у вас є кілька файлів, використовуваних разом, наприклад, вихідний код проекту або файли для вебсайту. Тепер, щоб зберегти стару версію, ви повинні скопіювати весь каталог. Підтримка безлічі таких версій вручну незручна і швидко стає дорогим задоволенням.
 
-У деяких іграх збереження - це і є каталог з купою файлів всередині. Ігри приховують деталі від гравця і надають зручний інтерфейс для управління різними версіями цього каталогу.
+У деяких іграх збереження – це і є каталог з купою файлів всередині. Ігри приховують деталі від гравця і надають зручний інтерфейс для керування різними версіями цього каталогу.
 
-У системах управління версіями все точно так само. У них у всіх є приємний інтерфейс для управління каталогом з вашим скарбом. Можете зберігати стан каталога так часто, як забажаєте, а потім відновити будь-яку з попередніх збережених версій. Але, на відміну від комп'ютерних ігор, вони істотно економлять дисковий простір. Зазвичай від версії до версії змінюється тільки кілька файлів, і то ненабагато. Зберігання лише відмінностей замість повних копій вимагає менше місця.
+У системах керування версіями все точно так само. У всіх них є приємний інтерфейс для керування каталогом з вашим скарбом. Можете зберігати стан каталога так часто, як забажаєте, а потім відновити будь-яку з попередніх збережених версій. Але, на відміну від комп'ютерних ігор, вони істотно економлять дисковий простір. Зазвичай від версії до версії змінюється тільки кілька файлів і то ненабагато. Зберігання лише відмінностей замість повних копій потребує менше місця.
 
 === Розподілене керування  ===
 
 
 Як би ви організували таку систему, щоб гравці змогли легко отримувати збереження інших? А завантажувати свої?
 
-У минулі часи кожен проект використовував централізоване управління версіями. Який-небудь сервер зберігав всі збережені ігри. І ніхто більше. Кожен тримав лише кілька збережень на своїй машині. Коли гравець хотів пройти трохи далі, він викачував найостанніше збереження з головного сервера, грав небагато, зберігався і закачував вже своє збереження назад на сервер, щоб інші могли ним скористатися.
+У минулі часи кожен проект використовував централізоване керування версіями. Який-небудь сервер зберігав всі збережені ігри. І ніхто більше. Кожен тримав лише кілька збережень на своїй машині. Коли гравець хотів пройти трохи далі, він завантажував останнє збереження з головного сервера, грав небагато, зберігався і вивантажував вже своє збереження назад на сервер, щоб інші могли ним скористатися.
 
 А що якщо гравець з якоїсь причини захотів використовувати більш стару збережену гру? Можливо, нинішнє збереження безвиграшне, бо хтось забув взяти якийсь ігровий предмет ще на третьому рівні, і потрібно знайти останнє збереження, де гру все ще можна закінчити. Або, можливо, хочеться порівняти дві більш старі збережені гри, щоб встановити внесок конкретного гравця.
 
 Може бути багато причин повернутися до більш старої версії, але вихід один: потрібно запросити ту стару збережену гру у центрального сервера. Чим більше збережених ігор потрібно, тим більше знадобиться зв’язуватися з сервером.
 
-Системи управління версіями нового покоління, до яких відноситься Git, відомі як розподілені системи, їх можна розуміти як узагальнення централізованих систем. Коли гравці завантажуються з головного сервера, вони отримують кожну збережену гру, а не тільки останню. Вони як би дзеркалюють центральний сервер.
+Системи керування версіями нового покоління, до яких відноситься Git, відомі як розподілені системи, їх можна розуміти як узагальнення централізованих систем. Коли гравці завантажуються з головного сервера, вони отримують кожну збережену гру, а не тільки останню. Вони як би дзеркалюють центральний сервер.
 
 Ці початкові операції клонування можуть бути ресурсоємними, особливо при довгій історії, але сповна окупаються при тривалій роботі. Найбільш очевидна пряма вигода полягає в тому, що якщо вам навіщось потрібна більш стара версія, взаємодія з сервером не знадобиться.
 
@@ -50,8 +50,8 @@
 
 Для цієї теми аналогія з комп'ютерною грою стає занадто натягнутою. Замість цього, давайте повернемося до редагування документа.
 
-Отже, припустимо, що Галя вставила рядок на початку файлу, а Тарас — в кінці. Обоє вони закачують свої зміни. Більшість систем автоматично зробить розумний висновок: прийняти і з'єднати їх зміни так, щоб обидві правки — і Галі, і Тараса — були застосовані.
+Отже, припустимо, що Марічка вставила рядок на початку файлу, а Іван — в кінці. Обоє вони закачують свої зміни. Більшість систем автоматично зробить розумний висновок: прийняти і об'єднати їх зміни так, щоб обидві правки — і Марічки, і Івана — були застосовані.
 
-Тепер припустимо, що і Галя, і Тарас внесли різні зміни в один і той же рядок. У цьому випадку неможливо продовжити без втручання людини. Той із них, хто другим закачає на сервер зміни, буде поінформований про _конфлікте злиття_ (_merge conflict_), і повинен або віддати перевагу однієї змінни іншій, або скорегувати увесь рядок.
+Тепер припустимо, що і Марічка, і Іван внесли різні зміни в один і той же рядок. У цьому випадку неможливо продовжити без втручання людини. Той із них, хто другим закачає на сервер зміни, буде поінформований про _конфлікте злиття_ (_merge conflict_), і повинен або віддати перевагу одній змінні перед іншою, або скорегувати увесь рядок.
 
-Можуть траплятися і більш складні ситуації. Системи управління версіями вирішують прості ситуації самі і залишають складні для людини. Зазвичай таку їхню поведінку можна налаштовувати.
+Можуть траплятися і більш складні ситуації. Системи керування версіями вирішують прості ситуації самі і залишають складні для людини. Зазвичай таку їхню поведінку можна налаштовувати.
index 63f790c..8617080 100644 (file)
@@ -4,33 +4,35 @@ Ben Lynn
 
 == Передмова ==
 
-http://git.or.cz/[Git] це швейцарський ніж керування версіями – надійний універсальний багатоцільовий інструмент, чия надзвичайна гнучкість робить його складним у вивченні навіть для багатьох професіоналів.
+http://git.or.cz/[Git] — це швейцарський ніж керування версіями — надійний універсальний багатоцільовий інструмент, чия надзвичайна гнучкість робить його складним у вивченні навіть для багатьох професіоналів.
 
-Як говорив Артур Кларк, будь-яка досить розвинена технологія не відрізняється від чаклунства. Це відмінний підхід до Git: новачки можуть ігнорувати принципи його внутрішньої роботи і розглядати Git як щось, що захоплює друзів і приводить в сказ ворогів своїми чудовими здібностями.
+Як говорив Артур Кларк, будь-яка досить розвинена технологія не відрізняється від чаклунства. Це відмінний підхід до Git: новачки можуть ігнорувати принципи його внутрішньої роботи і розглядати Git як щось, що викликає захоплення у друзів і доводить до сказу ворогів своїми чудовими здібностями.
 
-Замість того, щоб вдаватися в подробиці, ми надамо приблизні інструкції для одержання конкретних результатів. При частому використанні ви поступово зрозумієте, як працює кожен трюк і як пристосовувати рецепти під ваші потреби.
+Замість того, щоб вдаватися в подробиці, ми дамо приблизні інструкції для одержання конкретних результатів. При частому використанні ви поступово зрозумієте, як працює кожен трюк і як пристосовувати рецепти під ваші потреби.
 
 .Переклади
 
- - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[        Китайська (спрощена)]: JunJie, Meng та JiangWei.
- - link:/~blynn/gitmagic/intl/es/[Іспанська]: Rodrigo Toledo.
- - link:/~blynn/gitmagic/intl/de/[Німецька]: Benjamin Bellee и Armin Stebich. Armin також розмістив http://gitmagic.lordofbikes.de/[німецький переклад на його сайті].
+ - link:/~blynn/gitmagic/intl/vi/[В'єтнамська]: Trần Ngọc Quân; також http://vnwildman.users.sourceforge.net/gitmagic/[розміщено на його вебсайті].
+ - link:/~blynn/gitmagic/intl/es/[Іспанська]: Rodrigo Toledo та Ariset Llerena Tapia.
+  - http://docs.google.com/View?id=dfwthj68_675gz3bw8kj[Китайська (спрощена)]: JunJie, Meng та JiangWei. Конвертовано у link:/~blynn/gitmagic/intl/zh_tw/[Традиційна китайська] via +cconv -f UTF8-CN -t UTF8-TW+.
+ - link:/~blynn/gitmagic/intl/de/[Німецька]: Benjamin Bellee і Armin Stebich. Armin також розмістив http://gitmagic.lordofbikes.de/[німецький переклад на своєму сайті].
+  - http://www.slideshare.net/slide_user/magia-git[Португальська]: Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[в форматі ODT]].
  - link:/~blynn/gitmagic/intl/ru/[Російська]: Тихон Тарнавский, Михаил Дымсков і інші.
  - link:/~blynn/gitmagic/intl/uk/[Українська]: Володимир Боденчук.
- - link:/~blynn/gitmagic/intl/fr/[Французька]: Alexandre Garel. Також розміщений на http://tutoriels.itaapy.com/[itaapy].
- - http://www.slideshare.net/slide_user/magia-git[Португальська]: Leonardo Siqueira Rodrigues [http://www.slideshare.net/slide_user/magia-git-verso-odt[в форматі ODT]].
+ - link:/~blynn/gitmagic/intl/fr/[Французька]: Alexandre Garel, Paul Gaborit, та Nicolas Deram. Також розміщений на http://tutoriels.itaapy.com/[itaapy].
 
 .Інші варіанти
 
  - link:book.html[HTML однією сторінкою]: чистий HTML без CSS.
  - link:book.pdf[PDF файл]: для друку.
  - http://packages.debian.org/gitmagic[пакунок Debian], http://packages.ubuntu.com/gitmagic[пакунок Ubuntu]: отримайте локальну копію цього сайту. Стане у нагоді, http://csdcf.stanford.edu/status/[якщо цей сервер буде недоступним].
+ - http://www.amazon.com/Git-Magic-Ben-Lynn/dp/1451523343/[друкована версія [Amazon.com]]: 64 сторінок, 15.24cm x 22.86cm, чорно-біле зображення. Стане у нагоді у випадку відсутності електроенергії.
 
 === Подяки ===
 
 Я дуже ціную, що так багато людей працювали над перекладами цих рядків. Я вдячний названим вище людям за їхні зусилля, які розширили мою аудиторію.
 
-Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin, Tyler Breisacher, Sonia Hamilton, Julian Haagsma, Romain Lespinasse, Sergey Litvinov, Oliver Ferrigni, David Toca, Сергей Сергеев та Joël Thieffry сприяли в правках і доробках.
+Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar, Frode Aannevik, Keith Rarick, Andy Somerville, Ralf Recker, Øyvind A. Holm, Miklos Vajna, Sébastien Hinderer, Thomas Miedema, Joe Malin, Tyler Breisacher, Sonia Hamilton, Julian Haagsma, Romain Lespinasse, Sergey Litvinov, Oliver Ferrigni, David Toca, Сергей Сергеев, Joël Thieffry та Baiju Muthukadan сприяли в правках і доробках.
 
 François Marier супроводжує пакунок Debian, спочатку створений Daniel Baumann.
 
@@ -40,17 +42,9 @@ John Hinnegan купив http://www.gitmagic.com/[gitmagic.com] домен.
 
 Якщо я випадково забув згадати вас, будь ласка, нагадайте мені або просто вишліть патч.
 
-.Безкоштовні хостинги Git
-
- - http://repo.or.cz/[http://repo.or.cz/] хостинг вільних проектів. Перший сайт Git-хостингу. Заснований і підтримується одним з перших розробників Git.
- - http://gitorious.org/[http://gitorious.org/] інший сайт Git-хостингу, націлений на проекти з відкритим кодом.
- - http://github.com/[http://github.com/] хостинг для проектів з відкритим кодом; а також для закритих проектів (на платній основі).
-
-Велике спасибі кожному з цих сайтів за розміщення цього керівництва.
-
 === Ліцензія ===
 
-Це керівництво випущено під http://www.gnu.org/licenses/gpl-3.0.html[GNU General Public License 3-ї версії]. Природньо, вихідний текст знаходиться в сховищі Git і може бути отриманий командою:
+Це керівництво випущено під http://www.gnu.org/licenses/gpl-3.0.html[GNU General Public License 3-ї версії]. Природньо, вихідний текст знаходиться в сховищі Git і може бути отриманий за допомогою команди:
 
  $ git clone git://repo.or.cz/gitmagic.git  # Створить каталог "gitmagic".
 
index 9ff0c8b..292b589 100644 (file)
@@ -5,7 +5,7 @@
 Клонуйте вихідні тексти, потім створіть каталог, що відповідає тегу IETF цільової мови: дивіться
 http://www.w3.org/International/articles/language-tags/Overview.en.php[статтю W3C по інтернаціоналізації]. Наприклад, англійська мова це „en“, а японська — „ja“. Скопіюйте в каталог файли +txt+ з каталогу „en“ і перекладіть їх.
 
-Наприклад, для перекладу посібника на http://uk.wikipedia.org/wiki/%D0%9A%D0%BB%D1%96%D0%BD%D0%B3%D0%BE%D0%BD%D1%81%D1%8C%D0%BA%D0%B0_%D0%BC%D0%BE%D0%B2%D0%B0[клінгонську мову], ви можете набрати:
+Наприклад, для перекладу посібника на http://uk.wikipedia.org/wiki/Клінгонська_мова[клінгонську мову], ви можете набрати:
 
  $ git clone git://repo.or.cz/gitmagic.git
  $ cd gitmagic