From 9b7bf6f227592675cf5802ad28c17d0cf58b35c5 Mon Sep 17 00:00:00 2001 From: Taras Date: Tue, 10 May 2016 01:38:08 -0400 Subject: [PATCH 1/3] workflows catchup; 01-02 --- book/01-introduction/sections/basics.asc | 2 +- book/02-git-basics/sections/recording-changes.asc | 2 +- book/02-git-basics/sections/remotes.asc | 2 +- book/introduction.asc | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 958013dc..cae9782a 100644 --- 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 index 76dbcac9..48c3e6c2 100644 --- 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 index 263cb28e..0143f3f9 100644 --- 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/introduction.asc b/book/introduction.asc index f7c93d38..1ab2e612 100644 --- 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. From 09f42a65653403b2639c8f6ceeea2c1f03e3e63a Mon Sep 17 00:00:00 2001 From: Taras Date: Tue, 10 May 2016 01:46:36 -0400 Subject: [PATCH 2/3] trans notes for wf --- TRANSLATION_NOTES.asc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index c9fa6aa6..e2e678d7 100644 --- 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]*:: процес роботи, робочий процес, схема роботи From 178a68da730787c12ada250eb8325832b1e8c14f Mon Sep 17 00:00:00 2001 From: Taras Date: Sat, 14 May 2016 11:46:52 -0400 Subject: [PATCH 3/3] workflows catchup; 03-05 --- book/03-git-branching/1-git-branching.asc | 2 +- .../sections/basic-branching-and-merging.asc | 2 +- book/03-git-branching/sections/workflows.asc | 4 ++-- book/05-distributed-git/sections/contributing.asc | 2 +- .../05-distributed-git/sections/distributed-workflows.asc | 8 ++++---- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/book/03-git-branching/1-git-branching.asc b/book/03-git-branching/1-git-branching.asc index 5153f5bd..94ab2ed5 100644 --- 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 index 4830af63..07c3ead9 100644 --- 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 index 9ab06e43..3ee52d1b 100644 --- a/book/03-git-branching/sections/workflows.asc +++ b/book/03-git-branching/sections/workflows.asc @@ -1,7 +1,7 @@ === Процеси роботи з гілками Тепер, коли ви навчилися основам роботи з гілками, що ж з ними можна чи потрібно робити далі? -В цьому розділі ми розкажемо про найбільш вживані підходи до роботи з гілками, які дозволяє така легка система галуження Git, а ви можете вирішити чи втілювати вам їх у свій робочий цикл. +В цьому розділі ми розкажемо про найбільш вживані схеми роботи з гілками, які дозволяє така легка система галуження Git, а ви можете вирішити чи втілювати вам їх у свій робочий цикл. ==== Довго-триваючі гілки @@ -9,7 +9,7 @@ Оскільки 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 index f6bba702..e813629e 100644 --- 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 index 1e136db4..a2cbb7d0 100644 --- 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[Централізований процес роботи.] Це означає, що, якщо два розробники зроблять клон з розподілювача та обидвоє щось змінять, перший, хто надішле свої зміни назад, зможе це зробити без проблем. Другий розробник змушений зливати роботу першого до надсилання змін, щоб не переписати зміни першого розробника.