progit · tbudurovych · May 10, 2016 · May 10, 2016 · May 14, 2016
diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc
@@ -106,4 +106,4 @@
 *to track, tracked, untracked http://github.com/progit/progit2-uk/issues/160[#160]*:: стежити, відстежуваний, невідстежуваний
 *to unstage http://github.com/progit/progit2-uk/issues/145[#145]*:: скасувати споряджання
 *VCS*:: Системи контролю версій (СКВ)
-*workflow*:: процес роботи
+*workflow http://github.com/progit/progit2-uk/issues/176[#176]*:: процес роботи, робочий процес, схема роботи
diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc
@@ -95,7 +95,7 @@ image::images/areas.png["Робоча директорія, індекс та д
 Індекс -- це файл, що зазвичай знаходиться в директорії Git і містить інформацію про те, що буде збережено у наступному коміті.
 Також цей файл називають ``областю додавання'' (staging area), проте ми переважно будемо користуватись терміном ``індекс''.
 
-Найпростіший процес взаємодії з Git виглядає приблизно так:
+Найпростіший процес роботи з Git виглядає приблизно так:
 
 1. Ви редагуєте файли у своїй робочій директорії.
 2. Надсилаєте файли до індексу, що зберігає їхній поточний стан.

diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc
@@ -456,7 +456,7 @@ $ git commit -m "Story 182: Fix benchmarks for speed"
 ==== Обходимо індекс
 
 (((staging area, skipping)))
-Хоч індекс може бути неперевершено корисним для підготовки комітів саме до потрібного вам вигляду, іноді він може буди надто складним для ваших потреб.
+Хоч індекс може бути неперевершено корисним для підготовки комітів саме до потрібного вам вигляду, іноді він може буди надто складним для ваших потреб та вашого робочого процесу.
 Якщо ви бажаєте обійти індекс, Git надає вам простий короткий шлях.
 Додавання опції `-a` до команди `git commit`, змушує Git автоматично додати кожен файл, що вже контролюється, до коміту, що дозволяє вам пропустити команди `git add`:
 

diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc
@@ -116,7 +116,7 @@ $ git fetch [remote-name]
 Вам буде потрібно вручну її злити, коли ви будете готові.
 
 Якщо ваша поточна гілка налаштована слідкувати за віддаленою гілкою (докладніше в наступній секції та <<_git_branching>>), ви можете виконати команду `git pull` щоб автоматично отримати зміни та злити віддалену гілку до вашої поточної гілки.(((git commands, pull)))
-Це може бути легшим та зручнішим методом для вас. Та команда `git clone` автоматично налаштовує вашу локальну гілку master слідкувати за віддаленою гілкою master (хоча вона може називатись і по іншому) на віддаленому сервері, з якого ви зробили клон.
+Це може бути для вас легшим та зручнішим процесом роботи. Та команда `git clone` автоматично налаштовує вашу локальну гілку master слідкувати за віддаленою гілкою master (хоча вона може називатись і по іншому) на віддаленому сервері, з якого ви зробили клон.
 Виконання `git pull` зазвичай дістає дані з серверу, з якого ви зробили клон, та намагається злити її з кодом, над яким ви зараз працюєте.
 
 [[_pushing_remotes]]

diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc
@@ -9,7 +9,7 @@
 Дехто вважає гілки Git вбивчою особливістю, що вирізняє Git від інших систем.
 Що ж в них такого особливого?
 Гілки Git надзвичайно легкі, операції галуження майже миттєві, перехід між гілками зазвичай теж.
-На відміну від інших систем, Git заохочує схеми, де гілки часто створюються та зливаються, навіть кілька разів на день.
+На відміну від інших систем, Git заохочує схеми роботи, де гілки часто створюються та зливаються, навіть кілька разів на день.
 Розуміння та вміння працювати з цією "фішкою" дає вам потужний та унікальний інструмент, що може кардинально змінити ваш процес розробки.
 
 include::sections/nutshell.asc[]

diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc
@@ -1,6 +1,6 @@
 === Основи галуження та зливання
 
-Розглянемо простий приклад галуження та зливання на схемі, котра трапляється в реальності:
+Розглянемо простий приклад галуження та зливання на схемі роботи, котра трапляється в реальності:
 
 . Вам потрібно внести зміни до веб сайту.
 . Створюєте гілку для своєї задачі.

diff --git a/book/03-git-branching/sections/workflows.asc b/book/03-git-branching/sections/workflows.asc
@@ -1,15 +1,15 @@
 === Процеси роботи з гілками
 
 Тепер, коли ви навчилися основам роботи з гілками, що ж з ними можна чи потрібно робити далі?
-В цьому розділі ми розкажемо про найбільш вживані підходи до роботи з гілками, які дозволяє така легка система галуження Git, а ви можете вирішити чи втілювати вам їх у свій робочий цикл.
+В цьому розділі ми розкажемо про найбільш вживані схеми роботи з гілками, які дозволяє така легка система галуження Git, а ви можете вирішити чи втілювати вам їх у свій робочий цикл.
 
 ==== Довго-триваючі гілки
 
 (((branches, long-running)))
 Оскільки Git використовує просте трьох-точкове злиття, то зливання одної гілки в іншу протягом тривалого часу зазвичай не є складною задачею.
 Це означає, що ви можете мати кілька активних гілок та використовувати їх для різних стадій вашого робочого циклу; можете періодично зливати з одної гілки в іншу.
 
-Багато розробників підтримують з Git такий процес, коли тільки в `master` є стабільна версія коду - найімовірніше того, що був чи буде запроваджений у виробництво.
+Багато розробників підтримують з Git такий робочий процес, коли тільки в `master` є стабільна версія коду - найімовірніше того, що був чи буде запроваджений у виробництво.
 Також вони мають паралельні гілки `develop` чи `next`, які використовуються для тестування стабільності - це не обов'язково постійно стабільні гілки, але, як тільки вони стабілізовуються, їх можна зливати з `master`.
 Також практикується мати тематичні гілки (коротко-термінові, як `iss53`, що ви створили раніше) та зливати їх, коли вони готові, проходять всі тести, та не привнесуть нових помилок.
 

diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc
@@ -769,6 +769,6 @@ Result: OK
 
 ==== Підсумок
 
-У цій секції розглянуто декілька поширених процесів роботи, які працюють з декількома дуже різними типами проектів Git, які ви можете зустріти, та представлено декілька нових інструментів, які допомагають з керуванням цим процесом.
+У цій секції розглянуто низку поширених процесів роботи, які працюють з декількома дуже різними типами проектів Git, які ви можете зустріти, та представлено декілька нових інструментів, які допомагають з керуванням цим процесом.
 Далі, ви побачите як працювати з іншого боку: супроводжувати проект Git.
 Ви дізнаєтесь як бути доброзичливим диктатором або менеджером інтеграції.
diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc
@@ -4,18 +4,18 @@
 На відміну від Централізованих Систем Керування Версіями (ЦСКВ), розподілена сутність Git дозволяє вам бути набагато більш гнучким щодо того, як розробники співпрацюють над проектами.
 У централізованих системах кожен розробник є одним з вузлів, які працюють більш менш на рівних над централізованим розподілювачем (hub).
 У Git, втім, кожен розробник є потенційно і вузлом, і сервером – тобто, кожен розробник може як надсилати код до інших репозиторіїв, як і супроводжувати публічний репозиторій, на якому інші можуть базувати свою роботу, та до якого вони можуть надсилати зміни.
-Це відкриває безмежні можливості процесу роботи для вашого проекту та/або вашої команди, отже розглянемо декілька поширених парадигм, щоб скористатись цією гнучкістю.
+Це відкриває безмежні можливості робочого процесу для вашого проекту та/або вашої команди, отже розглянемо декілька поширених парадигм, щоб скористатись цією гнучкістю.
 Ми дізнаємось про переваги та можливі недоліки кожного методу; ви можете вибрати якийсь один, або змішати та сумістити елементи кожного.
 
 ==== Централізований процес роботи
 
 (((workflows, centralized)))
-У централізованих системах, взагалі існує єдина модель співпраці -- централізований процес роботи.
+У централізованих системах взагалі існує єдина модель співпраці -- централізований процес роботи.
 Один центральний розподілювач, або репозиторій, може приймати код, і всі синхронізують свою роботу з ним.
 Усі розробники є вузлами – споживачами цього розподілювача – та синхронізуються виключно з ним.
 
-.Централізований порядок роботи.
-image::images/centralized_workflow.png[Централізований порядок роботи.]
+.Централізований процес роботи.
+image::images/centralized_workflow.png[Централізований процес роботи.]
 
 Це означає, що, якщо два розробники зроблять клон з розподілювача та обидвоє щось змінять, перший, хто надішле свої зміни назад, зможе це зробити без проблем.
 Другий розробник змушений зливати роботу першого до надсилання змін, щоб не переписати зміни першого розробника.

diff --git a/book/introduction.asc b/book/introduction.asc
@@ -13,7 +13,7 @@
 
 *Розділ 5* детально пройдеться по різних розподілених процесах роботи та як їх досягнути за допомогою Git. Як розквитаєтеся з цим розділом, то зможете, з вправністю експерта, працювати з кількома сховищами, користуватися Git-ом через електронну пошту та хвацько жонглювати низкою віддалених гілок та латками зі змінами.
 
-*Розділ 6* покриває деталі розміщення в GitHub та його інструментарій. Ми розглянемо реєстрацію облікового запису, управління ним, створення та використання Git репозиторіїв, типові схеми долучання до чиїхось проектів, та приймання наробків у свої, програмний інтерфейс GitHub та багато дрібних порад, які мали б спростити ваші життя.
+*Розділ 6* покриває деталі розміщення в GitHub та його інструментарій. Ми розглянемо реєстрацію облікового запису, управління ним, створення та використання Git репозиторіїв, типові схеми роботи для долучання до чиїхось проектів, та приймання наробків у свої, програмний інтерфейс GitHub та багато дрібних порад, які мали б спростити ваші життя.
 
 *Розділ 7* про складніші команди Git. Тут дізнаєтесь про такі теми як опановування страшної команди 'reset', залучення двійкового пошуку для виявлення вад, зміну історії, докладно про вибір ревізій, та багато іншого. Цей розділ доповнить ваші знання про Git, щоб ви були дійсно майстром Git.