Часткове оновлення І секції

C-git-commands.asc

@@ -34,6 +34,44 @@ Git має типовий спосіб, як робити сотні речей.
 
 Нарешті, фактично весь <<ch08-customizing-git#_git_config>> присвячено цій команді.
 
+[[ch_core_editor]]
+==== Команди git config core.editor
+
+На додаток до інструкції з налаштування у <<ch01-getting-started#_editor>>, багато редакторів можуть бути встановлені наступним чином:
+
+.Вичерпний перелік команд налаштування `core.editor`
+[cols="1,2",options="header"]
+|==============================
+|Редактор | Команда налаштування
+|Atom |`git config --global core.editor "atom --wait"`
+|BBEdit (macOS з інструментами командного рядка) |`git config --global core.editor "bbedit -w"`
+|Emacs |`git config --global core.editor emacs`
+|Gedit (Linux) |`git config --global core.editor "gedit --wait --new-window"`
+|Gvim (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Vim\vim72\gvim.exe' --nofork '%*'"` (дивіться примітку нижче)
+|Helix |`git config --global core.editor "hx"`
+|Kate (Linux) |`git config --global core.editor "kate --block"`
+|nano |`git config --global core.editor "nano -w"`
+|Notepad (64-бітовій Windows) |`git config core.editor notepad`
+|Notepad++ (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Notepad+\+\notepad++.exe' -multiInst -notabbar -nosession -noPlugin"` (дивіться примітку нижче)
+|Scratch (Linux)|`git config --global core.editor "scratch-text-editor"`
+|Sublime Text (macOS) |`git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl --new-window --wait"`
+|Sublime Text (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\Sublime Text 3\sublime_text.exe' -w"` (дивіться примітку нижче)
+|TextEdit (macOS)|`git config --global core.editor "open --wait-apps --new -e"`
+|Textmate |`git config --global core.editor "mate -w"`
+|Textpad (64-бітовій Windows) |`git config --global core.editor "'C:\Program Files\TextPad 5\TextPad.exe' -m"` (дивіться примітку нижче)
+|UltraEdit (64-бітовій Windows) | `git config --global core.editor Uedit32`
+|Vim |`git config --global core.editor "vim --nofork"`
+|Visual Studio Code |`git config --global core.editor "code --wait"`
+|VSCodium (Free/Libre Open Source Software Binaries of VSCode) | `git config --global core.editor "codium --wait"`
+|WordPad |`git config --global core.editor "'C:\Program Files\Windows NT\Accessories\wordpad.exe'"`
+|Xi | `git config --global core.editor "xi --wait"`
+|==============================
+
+[NOTE]
+====
+Якщо ви маєте 32-бітовий редактор у 64-бітовій системі Windows, його буде інстальовано радше до `C:\Program Files (x86)\` аніж `C:\Program Files\`, попри те, що вказано у таблиці вище.
+====
+
 ==== git help
 
 Команда `git help` призначена для відображення документації, що постачається разом з Git для кожної команди.

TRANSLATION_NOTES.asc

@@ -37,7 +37,7 @@
 *checkout, to (file) http://github.com/progit/progit2-uk/issues/136[#136]*:: отримати (файл)
 *cherry-pick, to cherry-pick http://github.com/progit/progit2-uk/issues/134[#134]*:: висмикування, висмикнути
 *command line*:: командний рядок
-*commit, to commit, comitted, commiter http://github.com/progit/progit2-uk/issues/135[#135]*:: коміт, створювати коміт, збережене в коміті, творець коміту
+*commit, to commit, committed, commiter http://github.com/progit/progit2-uk/issues/135[#135]*:: коміт, створювати коміт, збережене в коміті, творець коміту
 *community*:: спільнота
 *continuous integration*:: безперервна інтеграція (http://uk.wikipedia.org/wiki/Безперервна_інтеграція[вікі])
 *dashboard*:: дошка керування
@@ -57,7 +57,7 @@
 *fetch http://github.com/progit/progit2-uk/issues/140[#140]*:: здобути зміни
 *filter-branch http://github.com/progit/progit2-uk/issues/141[#141]*:: фільтрація гілки
 *folder http://github.com/progit/progit2-uk/issues/138[#138]*:: тека
-*force (push) http://github.com/progit/progit2-uk/issues/142[#142]*::: примусове (надсилання змін)
+*force (push) http://github.com/progit/progit2-uk/issues/142[#142]*:: примусове (надсилання змін)
 *fork, to fork, forking http://github.com/progit/progit2-uk/issues/143[#143]*:: відсадок, відсаджувати, відсадження
 *Git*:: Git (не транслітерується)
 *GUI*:: графічний інтерфейс

book/01-introduction/sections/about-version-control.asc

@@ -1,61 +1,61 @@
 === Про систему контролю версій
 
 (((version control)))
-Що таке ``система контролю версій'', і чому це важливо?
+Що таке "`система контролю версій`", і чому це важливо?
 Система контролю версій - це система, що записує зміни у файл або набір файлів протягом деякого часу, так що ви зможете повернутися до певної версії пізніше.
-Як приклад, в цій книзі, для файлів, що знаходяться під контролем версій, буде використовуватися код програмного забезпечення, хоча насправді ви можете використовувати контроль версій практично для будь-яких типів файлів.
+Для прикладів в цій книзі, як файли, що знаходяться під контролем версій, буде використано код програмного забезпечення, хоча, насправді, ви можете використовувати контроль версій практично для будь-яких типів файлів.
 
 Якщо ви графічний або веб-дизайнер і хочете зберегти кожну версію зображення або макета (швидше за все, захочете), система контролю версій (далі СКВ) якраз те, що потрібно.
-Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проект до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого.
+Вона дозволяє повернути вибрані файли до попереднього стану, повернути весь проєкт до попереднього стану, побачити зміни, побачити, хто останній міняв щось і спровокував проблему, хто вказав на проблему і коли, та багато іншого.
 Використання СКВ також в цілому означає, що, якщо ви зламали щось або втратили файли, ви просто можете все виправити.
 Крім того, ви отримаєте все це за дуже невеликі накладні витрати.
 
 ==== Локальні системи контролю версій
 
 (((version control,local)))
-Багато людей в якості одного з методів контролю версій застосовують копіювання файлів в окрему директорію (можливо навіть директорію з відміткою за часом, якщо вони достатньо розумні).
+Багато людей в якості одного з методів контролю версій застосовують копіювання файлів в окрему теку (можливо, навіть теку з відміткою за часом, якщо вони достатньо розумні).
 Даний підхід є дуже поширеним завдяки його простоті, проте він, неймовірним чином, схильний до появи помилок.
-Можна легко забути в якій директорії ви знаходитеся і випадково змінити не той файл або скопіювати не ті файли, які ви хотіли.
+Можна легко забути в якій теці ви знаходитеся і випадково змінити не той файл або скопіювати не ті файли, які ви хотіли.
 
 Щоб справитися з цією проблемою, програмісти давно розробили локальні СКВ, що мають просту базу даних, яка зберігає всі зміни в файлах під контролем версій.
 
-.Локальні системи контролю версій.
+.Діаграма локальних систем контролю версій.
 image::images/local.png[Local version control diagram]
 
 Одним з найбільш поширених інструментів СКВ була система під назвою RCS, яка досі поширюється з багатьма комп'ютерами сьогодні.
-RCS зберігає набори латок (тобто, відмінності між файлами) в спеціальному форматі на диску; він може заново відтворити будь-який файл, як він виглядав, в будь-який момент часу, шляхом додавання всіх латок.
+https://www.gnu.org/software/rcs/[RCS^] зберігає набори латок (тобто, різницю між файлами) в спеціальному форматі на диску; вона може заново відтворити стан будь-якого файлу у будь-який момент часу, шляхом додавання всіх латок.
 
 ==== Централізовані системи контролю версій
 
 (((version control,centralized)))
 Наступним важливим питанням, з яким стикаються люди, є необхідність співпрацювати з іншими розробниками.
 Щоб справитися з цією проблемою, були розроблені централізовані системи контролю версій (ЦСКВ).
-Такі системи як CVS, Subversion і Perforce, мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця.
+Ці системи (такі як CVS, Subversion і Perforce) мають єдиний сервер, який містить всі версії файлів, та деяке число клієнтів, які отримують файли з центрального місця.(((CVS)))(((Subversion)))(((Perforce)))
 Протягом багатьох років, це було стандартом для систем контролю версій.
 
-.Централізовані системи контролю версій.
+.Діаграма централізованих систем контролю версій.
 image::images/centralized.png[Centralized version control diagram]
 
 Такий підхід має безліч переваг, особливо над локальними СКВ.
-Наприклад, кожному учаснику проекту відомо, певною мірою, чим займаються інші.
+Наприклад, кожному учаснику проєкту відомо, певною мірою, чим займаються інші.
 Адміністратори мають повний контроль над тим, хто і що може робити. Набагато легше адмініструвати ЦСКВ, ніж мати справу з локальними базами даних для кожного клієнта.
 
 Але цей підхід також має деякі серйозні недоліки.
 Найбільш очевидним є єдина точка відмови, яким є централізований сервер.
 Якщо сервер виходить з ладу протягом години, то протягом цієї години ніхто не може співпрацювати або зберігати зміни над якими вони працюють під версійним контролем.
-Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проекту, крім одиночних знімків проекту, що збереглися на локальних машинах людей.
-Локальні СКВ страждають тією ж проблемою -- щоразу, коли вся історія проекту зберігається в одному місці, ви ризикуєте втратити все.
+Якщо жорсткий диск центральної бази даних на сервері пошкоджено, і своєчасні резервні копії не були зроблені, ви втрачаєте абсолютно все -- всю історію проєкту, крім поодиноких відбитків проєкту, що збереглися на локальних машинах людей.
+Локальні СКВ страждають тією ж проблемою -- щоразу, коли вся історія проєкту зберігається в одному місці, ви ризикуєте втратити все.
 
-==== Децентралізовані системи контролю версій
+==== Розподілені системи контролю версій
 
 (((version control,distributed)))
-Долучаються до гри децентралізовані системи контролю версій (ДСКВ).
-В ДСКВ (таких як, Git, Mercurial, Bazaar або Darcs), клієнти не просто отримують останній знімок файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією.
-Таким чином, якщо вмирає який-небудь сервер, через який співпрацюють розробники, будь-який з клієнтських репозиторіїв може бути скопійований назад до серверу, щоб відновити його.
-Кожна копія дійсно є повною резервною копією всіх даних.
+Ось тут до гри долучаються розподілені системи контролю версій (РСКВ).
+В РСКВ (таких як, Git, Mercurial або Darcs), клієнти не просто отримують останній відбиток файлів репозиторія: натомість вони є повною копією сховища разом з усією його історією.
+Таким чином, якщо вмирає який-небудь сервер, через який співпрацюють розробники, будь-яке з клієнтських сховищ може бути скопійований назад до серверу, щоб відновити його.
+Кожна копія являє собою повну резервну копію всіх даних.
 
-.Децентралізовані системи контролю версій.
+.Діаграма децентралізованих систем контролю версій.
 image::images/distributed.png[Distributed version control diagram]
 
-Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими репозиторіями, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проекту одночасно.
+Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими сховищами, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проєкту одночасно.
 Це дозволяє налаштувати декілька типів робочих процесів, таких як ієрархічні моделі, які неможливі в централізованих системах.