diff --git a/C-git-commands.asc b/C-git-commands.asc index 3c056113..d2341117 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -34,6 +34,44 @@ Git має типовий спосіб, як робити сотні речей. Нарешті, фактично весь <> присвячено цій команді. +[[ch_core_editor]] +==== Команди git config core.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 для кожної команди. diff --git a/TRANSLATION_NOTES.asc b/TRANSLATION_NOTES.asc index c9fa6aa6..c52f5526 100644 --- a/TRANSLATION_NOTES.asc +++ b/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*:: графічний інтерфейс diff --git a/book/01-introduction/sections/about-version-control.asc b/book/01-introduction/sections/about-version-control.asc index 631f3cfe..f7a9c4bd 100755 --- a/book/01-introduction/sections/about-version-control.asc +++ b/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] -Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими репозиторіями, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проекту одночасно. +Більш того, багато з цих систем дуже добре взаємодіють з декількома віддаленими сховищами, так що ви можете співпрацювати з різними групами людей, застосовуючи різні підходи в межах одного проєкту одночасно. Це дозволяє налаштувати декілька типів робочих процесів, таких як ієрархічні моделі, які неможливі в централізованих системах. diff --git a/book/01-introduction/sections/command-line.asc b/book/01-introduction/sections/command-line.asc index 83c82783..50d6b09d 100755 --- a/book/01-introduction/sections/command-line.asc +++ b/book/01-introduction/sections/command-line.asc @@ -1,11 +1,11 @@ === Командний рядок Є багато різних варіантів використання Git. -Крім оригінальних клієнтів командного рядка, є безліч клієнтів з графічним інтерфейсом користувача з різними можливостями. +Крім оригінальних клієнтів командного рядка, є безліч клієнтів з графічним інтерфейсом користувача із різними можливостями. Для цієї книги ми будемо використовувати Git в командному рядку. -З одного боку, командний рядок -- єдине місце, де можна виконувати _всі_ команди Git - більшість графічних інтерфейсів для простоти реалізують тільки деяку підмножину функціональності Git. -Якщо ви знаєте, як виконати щось з командного рядка, ви, ймовірно, також можете з'ясувати, як виконати це і графічному інтерфейсі, у той час як зворотне не завжди вірно. +З одного боку, командний рядок -- єдине місце, де можна виконувати _всі_ команди Git -- більшість графічних інтерфейсів для простоти реалізують тільки деяку підмножину функціональності Git. +Якщо ви знаєте, як виконати щось з командного рядка, ви, ймовірно, також можете з'ясувати, як виконати це і у графічному інтерфейсі, у той час як зворотне не завжди вірно. Крім того, в той час, як вибір графічного клієнта справа особистого смаку, інструменти командного рядка мають _усі_ користувачі одразу ж після інсталяції. -Таким чином, ми очікуємо, що ви знаєте, як відкрити термінал в Mac або командний рядок, або Powershell в Windows. +Таким чином, ми очікуємо, що ви знаєте, як відкрити термінал в macOS або командний рядок чи PowerShell у Windows. Якщо ви не розумієте, про що ми тут говоримо, можливо, вам потрібно буде зупинитися та швидко дізнатися це, щоб ви були в змозі розуміти інші приклади і описи в цій книзі. diff --git a/book/01-introduction/sections/first-time-setup.asc b/book/01-introduction/sections/first-time-setup.asc index 90471255..050a2f1b 100755 --- a/book/01-introduction/sections/first-time-setup.asc +++ b/book/01-introduction/sections/first-time-setup.asc @@ -1,32 +1,40 @@ [[_first_time]] === Початкове налаштування Git -Зараз, коли у ви вже маєте Git у системі, можливо, ви захочете зробити декілька речей, щоб налаштувати ваше Git середовище. +Зараз, коли ви вже маєте Git у системі, можливо, ви захочете зробити декілька речей, щоб налаштувати ваше середовище Git. Це потрібно виконати лише один раз - налаштування залишаються між оновленнями. Ви також можете змінити їх у будь-який час, знову виконавши декілька команд. -До Git входить утиліта що має назву `git config`, яка дозволяє отримати чи встановити параметри, що контролюють усіма аспектами того, як Git виглядає чи працює. +До Git входить утиліта що має назву `git config`, яка дозволяє отримати чи встановити параметри, що контролюють усіма аспектами того, як Git виглядає чи працює.(((git commands, config))) Ці параметри можуть бути збережені в трьох різних місцях: -1. Файл `/etc/gitconfig` містить значення для кожного користувача в системі і всіх їхніх репозиторіїв. +1. Файл `[path]/etc/gitconfig` містить значення для кожного користувача в системі та всіх їхніх сховищ. Якщо ви передаєте опцію `--system` при виконанні `git config`, параметри читаються та пишуться з цього файлу. - (Це системний файл конфігурації, відповідно, вам потрібен був доступ адміністратора чи суперкористувача, щоб змінювати його.) + Оскільки це системний файл конфігурації, відповідно, вам знадобяться права адміністратора чи суперкористувача, щоб змінювати його. 2. Файл `~/.gitconfig` або `~/.config/git/config` зберігає значення саме для вас -- користувача. - Ви можете налаштувати Git читати і писати в цей файл, вказуючи опцію `--global.` -3. Файл `config` у каталозі Git (тобто `.git/config`) у тому репозиторії, який ви використовуєте в даний момент, зберігає налаштування конкретного репозиторія. + Ви можете спрямувати Git читати і писати в цей файл, передавши опцію `--global`, що вплине на _всі_ сховища з якими ви працюєте у вашій системі. +3. Файл `config` у теці Git (тобто `.git/config`) у тому сховищі, яке ви використовуєте в даний момент, зберігає налаштування цього конкретного сховища. + Ви можете змусити Git читати і писати в цей файл, вказавши опцію `--local`, але типово використовується саме вона. + Звісно, ви маєте бути десь у сховищі Git аби ця опція працювала правильно. -Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в `.git/config` перевизначають параметри в `/etc/gitconfig`. +Кожен рівень має пріоритет над налаштуваннями в попередньому рівні, тобто параметри в `.git/config` перевизначають параметри в `[path]/etc/gitconfig`. -У системах Windows, Git шукає файл `.gitconfig` в каталозі `$HOME` (`C:\Users\$USER` для більшості користувачів). -Він також все одно шукає файл `/etc/gitconfig`, хоча відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. -Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл -`C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, і `C:\ProgramData\Git\config` під Windows Vista й новіші. +У системах Windows, Git шукає файл `.gitconfig` у теці `$HOME` (`C:\Users\$USER` для більшості користувачів). +Також, він все одно шукає файл `[path]/etc/gitconfig`, хоча й відносно кореня MSys, котрий знаходиться там, де ви вирішили встановити Git у вашій Windows системі, коли ви запускали інсталяцію. +Якщо ви використовуєте Git для Windows версії 2.x або новішу, то є також системний конфігураційний файл `C:\Documents and Settings\All Users\Application Data\Git\config` під Windows XP, а починаючи з Windows Vista -- `C:\ProgramData\Git\config`. Цей файл може бути зміненим лише за допомогою `git config -f <файл>` адміністратором. +Ви можете переглянути усі ваші налаштування та звідки вони надходять виконавши: + +[source,console] +---- +$ git config --list --show-origin +---- + ==== Ім'я користувача -Перше, що ви повинні зробити, коли ви інсталюєте Git - це встановити ім'я користувача та адресу електронної пошти. -Це важливо, тому що кожен коміт в Git використовує цю інформацію, і вона незмінно включена у комміти, які ви робите: +Перше, що ви повинні зробити, коли ви інсталюєте Git -- це встановити ім'я користувача та адресу електронної пошти. +Це важливо, тому що кожен коміт в Git використовує цю інформацію, і вона незмінно включена у коміти, які ви робите: [source,console] ---- @@ -34,15 +42,16 @@ $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com ---- -Знову ж таки, якщо ви передаєте опцію `--global`, ці налаштування потрібно зробити тільки один раз, тоді Git завжди буде використовувати цю інформацію для всього, що ви робите у цій системі. -Якщо ви хочете, перевизначити ім'я або адресу електронної пошти для конкретних проектів, ви можете виконати цю ж команду без опції `--global` в каталозі необхідного проекту. +Знову ж таки, якщо ви передаєте опцію `--global`, ці налаштування потрібно зробити тільки один раз, бо тоді Git завжди буде використовувати цю інформацію для всього, що ви робите у цій системі. +Якщо ви хочете перевизначити ім'я або адресу електронної пошти для конкретних проєктів, ви можете виконати цю ж команду без опції `--global` в теці необхідного проєкту. Багато з графічних інструментів допомагають зробити це при першому запуску. +[[_editor]] ==== Редактор -Зараз, коли ваше ім'я вже вказано, ви можете налаштувати текстовий редактор за замовчуванням, який буде використовуватися Git при необхідності ввести повідомлення. -Якщо це не налаштовано, Git використовує типовий системний редактор. +Зараз, коли ваше ім'я вже вказано, ви можете налаштувати типовий текстовий редактор, який буде використовуватися Git при необхідності ввести повідомлення. +Якщо це не налаштовано, Git буде використовувати типовий системний редактор. Якщо ви бажаєте використовувати інший текстовий редактор, наприклад Emacs, необхідно зробити наступне: @@ -51,28 +60,21 @@ $ git config --global user.email johndoe@example.com $ git config --global core.editor emacs ---- -Під Windows, якщо ви бажаєте використати інший текстовий редактор, то маєте вказати повний шлях до відповідної програми. -Це залежить від того, як ваш редактор поставляється. +Під Windows, якщо ви бажаєте використати інший текстовий редактор, то маєте вказати повний шлях до його виконуваного файлу. +Він може різнитися залежно від того, як ваш редактор поставляється. У випадку Notepad++ -- популярного редактору коду -- ви напевно надасте перевагу 32-бітовій версії, адже на час написання цього тексу 64-бітова версія не підтримувала всіх додатків. Якщо у вас 32-бітова система, чи у вас 64-бітова система і ви хочете використовувати 64-бітовий редактор, варто спробувати щось таке: [source,console] ---- -$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession" ----- - -Якщо у вас 32-бітовий редактор під 64-бітовою системою, програму буде встановлено до `C:\Program Files (x86)`: - -[source,console] ----- -$ git config --global core.editor "'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -nosession" +$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" ---- [NOTE] ==== Vim, Emacs і Notepad++ -- це популярні текстові редактори, що їх часто використовують розробники на Unix-похідних системах (на кшталт Linux та macOS) та на Windows. -Якщо ви не знайомі з цими редакторами, можливо, вам потрібно буде знайти інструкції з налаштуванню вашого улюбленого редактора з Git. +Якщо ви використовуєте інші редактори або 32-бітові версії, ласкаво просимо знайти інструкції з налаштуванню вашого улюбленого редактора з Git у <>. ==== [WARNING] @@ -81,6 +83,19 @@ Vim, Emacs і Notepad++ -- це популярні текстові редакт Наприклад, під Windows операція Git може бути завчасно припинена під час запуску редактора. ==== +[[_new_default_branch]] +==== Типова назва гілки + +Типово, Git буде створювати гілку з назвою _master_ коли ви створюєте нове сховище із `git init`. +Із версії Git 2.28 і вище, ви можете налаштувати іншу назву для початкової гілки. + +Аби налаштувати _main_ як типову назву гілки, виконайте: + +[source,console] +---- +$ git config --global init.defaultBranch main +---- + ==== Перевірка налаштувань Якщо ви хочете подивитися на свої налаштування, можете скористатися командою `git config --list`, щоб переглянути всі налаштування, які Git може знайти: @@ -97,7 +112,7 @@ color.diff=auto ... ---- -Ви можете побачити ключі більш ніж один раз, тому що Git читає однакові ключі з різних файлів (наприклад `/etc/gitconfig` або `~/.gitconfig`). +Ви можете побачити ключі більш ніж один раз, тому що Git читає однакові ключі з різних файлів (наприклад, `[path]/etc/gitconfig` або `~/.gitconfig`). У цьому випадку, Git використовує останнє значення для кожного ключа. Ви також можете перевірити значення конкретного ключа виконавши `git config `:(((git commands, config))) diff --git a/update-plan/files.adoc b/update-plan/files.adoc index 0628b8c4..1312d7f4 100644 --- a/update-plan/files.adoc +++ b/update-plan/files.adoc @@ -4,19 +4,19 @@ |=== | Назва файлу |Статус (+ означає зроблено, * означає в процесі) -| book/01-introduction/sections/about-version-control.asc | -| book/01-introduction/sections/command-line.asc | -| book/01-introduction/sections/first-time-setup.asc | -| book/01-introduction/sections/help.asc | -| book/01-introduction/sections/history.asc | -| book/01-introduction/sections/installing.asc | -| book/01-introduction/sections/what-is-git.asc | +| book/01-introduction/sections/about-version-control.asc | + +| book/01-introduction/sections/command-line.asc | + +| book/01-introduction/sections/first-time-setup.asc | + +| book/01-introduction/sections/help.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/history.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/installing.asc | * by Oleh (burlakvo) +| book/01-introduction/sections/what-is-git.asc | * by Oleh (burlakvo) | book/02-git-basics/sections/aliases.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/getting-a-repository.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/recording-changes.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/remotes.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/tagging.asc | * by Eugene (dev99problems) -| book/02-git-basics/sections/undoing.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/getting-a-repository.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/recording-changes.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/remotes.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/tagging.asc | * by Eugene (dev99problems) +| book/02-git-basics/sections/undoing.asc | * by Eugene (dev99problems) | book/02-git-basics/sections/viewing-history.asc | * by Eugene (dev99problems) | book/03-git-branching/sections/basic-branching-and-merging.asc | | book/03-git-branching/sections/branch-management.asc | diff --git a/update-plan/plan.adoc b/update-plan/plan.adoc index 20a0335d..f0ca616c 100644 --- a/update-plan/plan.adoc +++ b/update-plan/plan.adoc @@ -7,17 +7,27 @@ Спробував залити `2.1.434` до `master`, список файлів з конфліктами у `files.adoc`. +Перевірте, чи у вас налаштовано `merge.conflictstyle` як `diff3`. +Якщо ні, то не забудьте додати опцію `--diff3` до команди `merge-file` у скрипті нижче, або виконайте наступну команду: + +```bash +git config --global merge.conflictstyle diff3 +``` + // Пропонований порядок роботи (продемонстрований на `book/01-introduction/sections/about-version-control.asc`): // // Спершу отримаємо всі версії цього файлу: -// +// // ---- // f=book/01-introduction/sections/about-version-control.asc // # Дивимося конфлікти // git show origin/english-version:$f > $f-old-english // git show 2.1.434:$f > $f-cur-english -// git show HEAD:$f > $f-ukrainian -// git merge-file -p $f-ukrainian $f-old-english $f-cur-english > $f +// git merge-file $f $f-old-english $f-cur-english +// rm $f-old-english $f-cur-english // ---- -// +// // Виправляємо файл і робимо PR. + +.Примітка +Якщо працюєте з власним відсадком, то не забудьте стягнути гілку `english-version` з оригінального репозиторію.