Fix Ukrainian translation

This commit is contained in:
Andriy Moroz 2016-07-05 14:47:48 +03:00
parent 09e228b45d
commit a5ae25fc3c
24 changed files with 113 additions and 113 deletions

View file

@ -909,7 +909,7 @@ exports.level = {
"",
"Так само як модифікатор `~`, модифікатор `^` також приймає необов’язкове число після нього.",
"",
"Замість того щоб вказувати кількість генерацій щоб переміститись назад (те що робить `~`), число після `^` вказує на яке батьківське посилання мерджу потрібно перейти. Зауважте що так як мерджевий коміт має декілька батьків, використання '^' без числа є неоднозначним.",
"Замість того, щоб вказувати кількість генерацій щоб переміститись назад (те що робить `~`), число після `^` вказує на яке батьківське посилання мерджу потрібно перейти. Зауважте що так як мерджевий коміт має декілька батьків, використання '^' без числа є неоднозначним.",
"",
"Git зазвичай перейде на \"першого\" з батьків вверх з мерджевого коміту, але вказання числа після `^` змінює цю поведінку. ",
"",
@ -924,7 +924,7 @@ exports.level = {
"beforeMarkdowns": [
"Ось ми маємо мерджевий коміт. Якщо зробимо checkout `master^` без числа, ми потрапимо на першого з предків ",
"",
"(*В нашій візуалізації, перший предок знаходиться прямо над мержевим комітом*)"
"(*В нашій візуалізації перший предок знаходиться прямо над мерджевим комітом*)"
],
"afterMarkdowns": [
"Легко -- те до чого ми всі звикли."
@ -953,7 +953,7 @@ exports.level = {
"Модифікатори `^` та `~` дозволяють легко переміщатись по дереву комітів:"
],
"afterMarkdowns": [
"Суперово швидко!"
"Супер швидко!"
],
"command": "git checkout HEAD~; git checkout HEAD^2; git checkout HEAD~2",
"beforeCommand": "git commit; git checkout C0; git commit; git commit; git commit; git checkout master; git merge C5; git commit"
@ -966,7 +966,7 @@ exports.level = {
"Більше того, ці модифікатори можна використовувати разом! Заціни:"
],
"afterMarkdowns": [
"Теж саме, що й перед цим, але одною командою."
"Те саме, що й перед цим, але одною командою."
],
"command": "git checkout HEAD~^2~2",
"beforeCommand": "git commit; git checkout C0; git commit; git commit; git commit; git checkout master; git merge C5; git commit"
@ -980,7 +980,7 @@ exports.level = {
"",
"Щоб завершити цей рівень, створи нову гілку на вказаному місці.",
"",
"Очевидно що в данному випадку досить легко вказати коміт напряму (щось на зразок checkout `C6`), але для закріплення матеріалу, використай модифікатори про які ми щойно говорили!"
"Очевидно, що в данному випадку досить легко вказати коміт напряму (щось на зразок checkout `C6`), але для закріплення матеріалу, використай модифікатори про які ми щойно говорили!"
]
}
}

View file

@ -221,7 +221,7 @@ var sequenceInfo = exports.sequenceInfo = {
'zh_CN': 'Git 技术、技巧与贴士杂烩',
'zh_TW': 'git 的技術,招數與技巧',
'ru_RU': 'Ассорти из приёмов работы с Git, хитростей и советов',
'uk' : 'Різні прийоми роботи з Git, хитрості та поради'
'uk' : 'Різні прийоми роботи з Git, хитрощі та поради'
}
},
advanced: {

View file

@ -475,7 +475,7 @@ exports.level = {
"",
"Git намагається зберігати коміти якнайпростіше й ефективніше, тому він не просто копіює всю директорію при кожному коміті. Він може стиснути коміт в набір правок чи \"дельту\" між двома версіями репозиторію.",
"",
"Git також зберігає історію коли і ким був створений той чи інший коміт. Тому більшість комітів мають комітів-предків, що знаходяться вище в ієрархії \u2014 ми це зоображуємо стрілочками в нашій візуалізації. Історія \u2014 це необхідна річ для кожного, хто працює з конкретним проектом.",
"Git також зберігає історію коли і ким був створений той чи інший коміт. Тому більшість комітів мають комітів-предків, що знаходяться вище в ієрархії \u2014 ми це зображуємо стрілочками в нашій візуалізації. Історія \u2014 це необхідна річ для кожного, хто працює з конкретним проектом.",
"",
"Тут є багато над чим подумати, але наразі ти можеш уявляти коміти як моментальні знімки проекту. Коміти майже невагомі й перемикання між ними дуже швидке."
]
@ -485,7 +485,7 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Давай подивимось, як це виглядає на практиці. Справа зоображена візуалізація маленького Git-репозиторію. Наразі ми бачимо два коміти: початковий коміт `C0`, та наступний коміт `C1`, який містить якісь змістовні зміни.",
"Давай подивимось, як це виглядає на практиці. Справа зображена візуалізація маленького Git-репозиторію. Наразі ми бачимо два коміти: початковий коміт `C0`, та наступний коміт `C1`, який містить якісь змістовні зміни.",
"",
"Натисни кнопку нижче, щоб створити новий коміт."
],

View file

@ -729,9 +729,9 @@ exports.level = {
"markdowns": [
"## Гілки та їх Злиття",
"",
"Чудово! Ми знаємо як комітити та створювати гілки. Тепер потрібно навчитися в якийсь спосіб поєднувати інфу з двох чи більше гілок. Це дозволить нам відгілкуватись, зробити нову фічу, й потім інтегрувати її взад.",
"Чудово! Ми знаємо як комітити та створювати гілки. Тепер потрібно навчитися в якийсь спосіб поєднувати інфу з двох чи більше гілок. Це дозволить нам відгілкуватись, зробити нову фічу, й потім інтегрувати її назад.",
"",
"Перший спосіб об’єднувати робочу інфу з яким ми розберемось це `git merge`. Команда merge (злити) в Git створює спеціяльний коміт який має двох унікальних батьків. Здорова сім’я прям. Коміт з двома батьками в приниципі просто значить що в нього включена інфа з обох батьків і всіх їх попередників.",
"Перший спосіб об’єднувати робочу інфу з яким ми розберемось це `git merge`. Команда merge (злити) в Git створює спеціальний коміт який має двох унікальних батьків. Коміт з двома батьками в приниципі просто значить що в нього включена інфа з обох батьків і всіх їх попередників.",
"",
"Це простіше сприймається візуально, тому розберемо це в наступному слайді"
]
@ -741,12 +741,12 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Тут ми маємо дві гілки; кожна з них містить унікальний коміт. Це означає що жодна з них не містить повного набору \"робочої інфи\" в цьому репозиторії. Давайте зіллємо всю інфу до купи за допомогою merge.",
"Тут ми маємо дві гілки; кожна з них містить унікальний коміт. Це означає що жодна з них не містить повного набору \"робочої інфи\" в цьому репозиторії. Давайте зіллємо всю інфу докупи за допомогою merge.",
"",
"Ми `змержимо` гілку `bugFix` в `master`"
],
"afterMarkdowns": [
"Нічосі! Ви то виділи? По-перше, `master` тепер вказує на коміт з двома батьками. Якщо ти піднімешся вверх з цього коміту по дереву, починаючи з `master`, на шляху ти зустрінеш кожен коміт аж до кореневого. Це означає що гілка `master` тепер містить всю інфу в цьому репозиторії.",
"Нічого собі! Ви це бачили? По-перше, `master` тепер вказує на коміт з двома батьками. Якщо ти піднімешся вверх з цього коміту по дереву, починаючи з `master`, на шляху ти зустрінеш кожен коміт аж до кореневого. Це означає що гілка `master` тепер містить всю інфу в цьому репозиторії.",
"",
"А ти помітив як змінилися кольори комітів? Для кращого розуміння процесу я додав певну кольорову диференціацію. Кожен бранч виділено окремим кольором. Колір кожного коміту це суміш кольорів всіх гілок що місять цей коміт.",
"",
@ -763,7 +763,7 @@ exports.level = {
"Давай змержимо `master` в `bugFix`:"
],
"afterMarkdowns": [
"Так як `bugFix` є нащадком `master`, git'у непотрібно нічого робити; він просто пересунув `bugFix` на тей самий коміт, на якому знаходиться `master`.",
"Так як `bugFix` є нащадком `master`, git'у не потрібно нічого робити; він просто пересунув `bugFix` на тей самий коміт, на якому знаходиться `master`.",
"",
"Тепер всі коміти одного кольору, що означає що кожен бранч включає в собі всю корисну інфу яка є в цьому репозиторії! Ура!"
],

View file

@ -721,12 +721,12 @@ exports.level = {
"beforeMarkdowns": [
"Ми знову маємо дві гілки; зауваж, що наразі вибрана гілка bugFix (вважай зірочку)",
"",
"Ми хочемо перемістити наші зміни з гілки bugFix прямо до змін з гілки master. Тоді це буде виглядати наче ці зміни були додані одна за одною, коли насправді вони були додані одночасно.",
"Ми хочемо перемістити наші зміни з гілки bugFix прямо до змін з гілки master. Тоді це буде виглядати наче ці зміни були додані одна за одною, хоча насправді вони були додані одночасно.",
"",
"Давайте зробимо це за допомогою команди `git rebase`"
],
"afterMarkdowns": [
"Файно! Тепер зміни з гілки bugFix знаходяться прямо попереду змін з master й ми отримали зручну лінійну послідовність комітів.",
"Добре! Тепер зміни з гілки bugFix знаходяться прямо попереду змін з master й ми отримали зручну лінійну послідовність комітів.",
"",
"Вважай що коміт C3 досі десь існує (в дереві він тьмяніший за решту), й C3' це \"копія\" яку ми заребейсили в master.",
"",

View file

@ -669,7 +669,7 @@
"",
"Через те що таги є такими чудовими \"орієнтирами\" по коду, git також має команду *описати* (describe) де ти є відносно найближчого \"орієнтира\" (тобто тага). Й ця команда називається `git describe`!",
"",
"Git describe допоможе тобі знайти себе після того як ти перепригнеш на кілька комітів по історії вперед чи назад; це може статися після того як ти закінчив git bisect (пошук-дебаггер) чи коли тебе попросили підійти до колеги котрий щойно прийшов з відпустки."
"Git describe допоможе тобі знайти себе після того як ти перестрибнеш на кілька комітів по історії вперед чи назад; це може статися після того як ти закінчив git bisect (пошук-дебаггер) чи коли тебе попросили підійти до колеги, котрий щойно прийшов з відпустки."
]
}
},

View file

@ -442,9 +442,9 @@ exports.level = {
"",
"Ось ситуація з життя рядового програміста: я намагаюся відслідкувати баг але це не завжди вдається. Щоб допомогти собі, я додаю кілька дебаг команд та ще кілька println'ів.",
"",
"Всі ці команди для відладки та виводу данних знаходяться в своїх власних комітах. Врешті-решт я знаходжу баг, фікшу її та щиро радію!",
"Всі ці команди для відлагодження та виводу данних знаходяться в своїх власних комітах. Врешті-решт я знаходжу баг, фікшу його та щиро радію!",
"",
"От тіки лишається проблема що потрібно мій фікс перенести з `bugFix` назад в гілку `master`. Якщо я просто зроблю фастфорвард (fast-forwarded) в `master`, тоді в `master` попадуть всі мої println'и що є зайвим. Має бути інший шлях..."
"От тільки лишається проблема що потрібно мій фікс перенести з `bugFix` назад в гілку `master`. Якщо я просто зроблю фастфорвард (fast-forwarded) в `master`, тоді в `master` попадуть всі мої println'и, що є зайвим. Має бути інший шлях..."
]
}
},

View file

@ -393,9 +393,9 @@ exports.level = {
"markdowns": [
"## Жонглюємо комітами",
"",
"Ось інакша ситуація що доволі часто трапляється. В тебе є якісь зміни (`newImage`) та ще якийсь набір комітів (`caption`) що є зв’язані між собою, тому вони знаходяться один над одним в твоєму репозиториї (або один за одним).",
"Ось інша ситуація, що доволі часто трапляється. В тебе є якісь зміни (`newImage`) та ще якийсь набір комітів (`caption`), які зв’язані між собою, тому вони знаходяться один над одним в твоєму репозиторії (або один за одним).",
"",
"Штука в тому що іноді потрібно зробити невелику модифікацію до попереднього коміту. В цьому випадку, дизайнери хочуть щоб ми трохи змінили розміри `newImage`, не дивлячись на те що цей коміт знаходиться досить глибоко в історії!!"
"Штука в тому що іноді потрібно зробити невелику модифікацію до попереднього коміту. В цьому випадку, дизайнери хочуть щоб ми трохи змінили розміри `newImage`, не зважаючи на те, що цей коміт знаходиться досить глибоко в історії!!"
]
}
},
@ -405,15 +405,15 @@ exports.level = {
"markdowns": [
"Ми поборимо цю складність наступним чином:",
"",
"* Ми відсортуємо коміти таким чином, щоб той який ми хочемо змінити був останнім за допомогою `git rebase -i`",
"* Ми відсортуємо коміти таким чином, щоб той, який ми хочемо змінити, був останнім за допомогою `git rebase -i`",
"* Ми виконаємо `commit --amend` щоб внести невелику правку до останнього коміту",
"* Тоді ми відсортуємо коміти в попередньому порядку, за допомогою `git rebase -i`",
"* І на останок, ми пересунемо master на змінену частину дерева щоб закінчити цей рівень(ти можеш вибрати метод)",
"",
"Насправді є кілька способів як виконати поставлену задачу (Я бачу ти поглядаєш на cherry-pick), й ми розберемося з ними всіма трохи пізніше, але зараз, давай, скористаємося цим методом.",
"Насправді є кілька способів як виконати поставлену задачу (Я бачу ти поглядаєш на cherry-pick), і ми розберемося з ними всіма трохи пізніше, але зараз, давай, скористаємося цим методом.",
"Зверни увагу на фінальний стан в цьому рівні -- так як ми перемістили коміти двічі, кожен з них отримає по апострофу. Ще один апостроф додастся коли ми виконаємо commit --amend.",
"",
"Враховуючи вищесказане, я буду порівнювати дерево як по назві коміта так і за кількістю апострофів. Як тільки дерево цілей та master співпадуть, ти пройдеш цей рівень."
"Враховуючи сказане вище, я буду порівнювати дерево як по назві коміта так і за кількістю апострофів. Як тільки дерево цілей та master співпадуть, ти пройдеш цей рівень."
]
}
}

View file

@ -473,9 +473,9 @@ exports.level = {
"markdowns": [
"## Жонглюємо комітами #2",
"",
"*Якщо ти ще не пройшов Жонглюємо комітами #1 (попередній рівень), будь-ласка, зроби це перед тим як продовжити*",
"*Якщо ти ще не пройшов Жонглюємо комітами #1 (попередній рівень), будь ласка, зроби це перед тим як продовжити*",
"",
"Як ти бачив в попередньому рівні, ми використали `rebase -i` щоб впорядкувати набір комітів. Як тільки потрібний коміт опиняється на горі його досить легко змінити його за допомогою --amend й потім відсортувати коміти в попередньому порядку.",
"Як ти бачив в попередньому рівні, ми використали `rebase -i` щоб впорядкувати набір комітів. Як тільки потрібний коміт опиняється на горі його досить легко змінити за допомогою --amend й потім відсортувати коміти в попередньому порядку.",
"",
"Єдина проблема з таким підходом, що виконується досить багато перестановок комітів, що може призвести до конфліктів при виконанні rebase. Давайте спробуємо інший підхід який використовує `git cherry-pick`"
]
@ -485,12 +485,12 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Не забувай що git cherry-pick втицьне коміт з будь якого місця в HEAD (якщо це не коміт-предок HEAD).",
"Не забувай, що git cherry-pick вставить коміт з будь-якого місця в HEAD (якщо це не коміт-предок HEAD).",
"",
"Ось невелике демо, щоб пригадати:"
],
"afterMarkdowns": [
"Файно! Продовжуємо"
"Добре! Продовжуємо"
],
"command": "git cherry-pick C2",
"beforeCommand": "git checkout -b bugFix; git commit; git checkout master; git commit"
@ -502,7 +502,7 @@ exports.level = {
"markdowns": [
"Отже в цьому рівні, давайте досягнемо тієї ж мети модифікації `C2` але не використовуючи `rebase -i`. Я думаю ти розберешся як це зробити! :D",
"",
"Зверни увагу що точне число апострофів (') в коміті не важливе, важлива тільки відносна різниця. Наприклад, якщо кожен коміт буде містити додатковий апостроф, я все одно зарахую такий розв’язок."
"Зверни увагу, що точне число апострофів (') в коміті не важливе, важлива тільки відносна різниця. Наприклад, якщо кожен коміт буде містити додатковий апостроф, я все одно зарахую такий розв’язок."
]
}
}

View file

@ -557,7 +557,7 @@
"markdowns": [
"## Таги в Git",
"",
"Як ти вже знаєш з попередніх уроків, гілки досить просто переносити в інші місця й вони постійно вказують на різні коміти в процесі того як ті в них додаються. Гілки легко модифікувати, часто тимчасово, й вони постійно змінюються.",
"Як ти вже знаєш з попередніх уроків, гілки досить просто переносити в інші місця і вони постійно вказують на різні коміти в процесі того як ті в них додаються. Гілки легко модифікувати, часто тимчасово, й вони постійно змінюються.",
"",
"В такому разі, де взяти *постійне* посилання на момент в історії твого проекту? Для таких речей як релізи чи великі мерджі потрібно щось більш стале ніж гілка.",
""
@ -568,7 +568,7 @@
"type": "ModalAlert",
"options": {
"markdowns": [
сть один спосіб! Таги в гіт якраз для цього й були створені -- вони (більш-менш) постійно вказують на певні коміти, й відмічають певні \"віхи\" в житті проекту, на які ти можеш потім посилатись так само як на гілки.",
один спосіб! Таги в гіт якраз для цього й були створені -- вони (більш-менш) постійно вказують на певні коміти, й відмічають певні \"віхи\" в житті проекту, на які ти можеш потім посилатись так само як на гілки.",
"",
"Але що важливіше, вони ніколи не переміщуються коли створюються нові коміти. Ти не зможеш \"зачекаутити\" таг а потім закомітити якісь зміни в цей таг -- таги просто відмічають корисні чи символічні місця в дереві комітів.",
"",

View file

@ -609,7 +609,7 @@
"markdowns": [
"## Переміщуємо зміни",
"",
"Поки що ми розrлядали основи git -- як працювати з комітами та гілками й переміщення по дереву комітів. Цього вже достатньо щоб використовувати 90% фунцкій гіт та мати змогу ефективно працювати з гіт як розробник.",
"Поки що ми розглядали основи git -- як працювати з комітами та гілками й переміщення по дереву комітів. Цього вже достатньо щоб використовувати 90% фунцкій гіт та мати змогу ефективно працювати з гіт як розробник.",
"",
"Решта 10%, тим не менш, можуть бути надзвичайно корисними при роботі зі складними робочими процесами (workflow), чи коли ти чи ще хтось щось зробили не так і ти хочеш це виправити. Наступна концепція з якою ми познайомимось це \"перенесення змін\" -- іншими словами, це можливість розробника переміщувати коміти між гілками в простий та зручний спосіб.",
"",
@ -641,7 +641,7 @@
"Ми бачимо репозиторій де є певні зміни в гілці `side` які ми хочемо скопіювати в `master`. Для цього можна використати rebase (який ми вже вивчили), але подивимось як з цим впорається cherry-pick."
],
"afterMarkdowns": [
"Оба-на! Ми хотіли коміти `C2` та `C4` й git вязв і додав їх до поточного розташування. Просто й доступно!"
"Оба-на! Ми хотіли коміти `C2` та `C4` і git додав їх до поточного розташування. Просто й доступно!"
],
"command": "git cherry-pick C2 C4",
"beforeCommand": "git checkout -b side; git commit; git commit; git commit; git checkout master; git commit;"

View file

@ -809,9 +809,9 @@ exports.level = {
"markdowns": [
"## Прогулянка по Git",
"",
"Перед тим як ми перейдемо до більш продвинутих фіч гіта, важливо розуміти різни способи переміщення по дереву комітів твого проекту.",
"Перед тим як ми перейдемо до складніших можливостей гіта, важливо розуміти різні способи переміщення по дереву комітів твого проекту.",
"",
"Дуже важливо щоб тобі було комфортно переміщатись по репозиторію, так як цей скіл тобі знадобиться для використання в більшості команд git!",
"Дуже важливо щоб тобі було комфортно переміщатись по репозиторію, так як цей навик тобі знадобиться для використання в більшості команд git!",
"",
"",
"",
@ -859,7 +859,7 @@ exports.level = {
""
],
"afterMarkdowns": [
"Й в стані detached head",
"А в стані detached head:",
"",
"HEAD -> C1"
],
@ -873,7 +873,7 @@ exports.level = {
"markdowns": [
"Щоб пройти цей рівень, давайте відокремимо голову від гілки `bugFix` й натомість спрямуємо її на якийсь коміт.",
"",
"Вкажи цей коміт за його hash (хеш, ідентифікатором). Хеш кожного коміту відображений в кружочку що символізує коміт."
"Вкажи цей коміт за його hash (хеш, ідентифікатором). Хеш кожного коміту відображений в кружечку що символізує коміт."
]
}
}

View file

@ -707,7 +707,7 @@
"",
"Якщо додати цю опцію, git відкриє діалог в якому покаже які коміти будуть скопійовані до кінцевого призначення. Він також покаже хеші комітів та їхні повідомлення, що допоможе розібратися що й до чого.",
"",
"В \"справжньому\" git, замість UI вікна відкриється файл в зконфігурованому текстовому редакторі, можливо `vim`. Для цього туторіалу я створив невеличке діалогове вікно що поводиться приблизно так само."
"В \"справжньому\" git, замість UI вікна відкриється файл в сконфігурованому текстовому редакторі, можливо `vim`. Для цього туторіалу я створив невеличке діалогове вікно що поводиться приблизно так само."
]
}
},
@ -715,13 +715,13 @@
"type": "ModalAlert",
"options": {
"markdowns": [
"Коли відкриється вікно інтерактивного rebase ти можеш зробити 3 речі:",
"Коли відкриється вікно інтерактивного rebase ти можеш зробити три речі:",
"",
"* Ти можеш переставити коміти між собою просто змінивши їх порядок в діалозі (в нашому вікні ти зможеш перетягнути їх мишкою).",
"* Ти можеш повністю пропустити якісь коміти. В туторіалі потрібно вимкнути опцію `pick`, але в справжньому гіт потрібно просто видалити відповідний рядок.",
"* Також можна розчавити (squash) якісь коміти. На жаль наш туторіал не підтримує цю фічу (так як ми не підтримуєм роботу з файлами), але це дуже зручна опція в справжньому гіт. За допомогою неї можна декілька різніх комітів об’єднати в один",
"* Також можна розчавити (squash) якісь коміти. На жаль наш туторіал не підтримує цю фічу (так як ми не підтримуємо роботу з файлами), але це дуже зручна опція в справжньому гіт. За її допомогою можна декілька різніх комітів об’єднати в один",
"",
"Чудово! Давайте розбиремо це на прикладі"
"Чудово! Давайте розберемо це на прикладі"
]
}
},
@ -732,7 +732,7 @@
"Коли ти натиснеш кнопку відкриється вікно інтерактивного rebase. Перестав якісь коміти (можеш пропустити якісь якщо хочеш) і подивись що вийде!"
],
"afterMarkdowns": [
"Ка-бум! Git зкопіював коміти відповідно до того що було вказано в UI"
"Ка-бум! Git cкопіював коміти відповідно до того що було вказано в UI"
],
"command": "git rebase -i HEAD~4 --aboveAll",
"beforeCommand": "git commit; git commit; git commit; git commit"

View file

@ -789,9 +789,9 @@ exports.level = {
"",
"Пересуватися по гіту використовуючи хеш комітів може бути трохи напряжно. В справжньому гіті в тебе не буде візуалізації дерева комітів в терміналі, тому доведеться використовувати `git log` щоб подивится хеші комітів.",
"",
"Більше того, хеші як правило набагато довші в справньому гіті. Типовий хеш виглядає як `fed2da64c0efc5293610bdd892f82a58e8cbc5d8`. Без мнемонік не обійтися)...",
"Більше того, хеші як правило набагато довші в справжньому гіті. Типовий хеш виглядає як `fed2da64c0efc5293610bdd892f82a58e8cbc5d8`. Без мнемонік не обійтися)...",
"",
"З іншого боку git дуже інтілігентсько працює з хешами. Він просить вказати рівно стільки літер, скільки потрібно щоб відрізнити один коміт від іншого. Отже, замість довгого хеша зверху можна просто набрати `fed2`."
"З іншого боку git дуже розумно працює з хешами. Він просить вказати рівно стільки літер, скільки потрібно щоб відрізнити один коміт від іншого. Отже, замість довгого хеша зверху можна просто набрати `fed2`."
]
}
},

View file

@ -668,9 +668,9 @@ exports.level = {
"markdowns": [
"## Відміна змін в Git",
"",
"Є декілька шляхів відмини змін в Git. Й так само як і коміти, зміни в гіт можна відміняти використовуючи або низькорівневі методи (додавання в коміт окремих файлів) так і високорівневі. Ми зосередемось на останніх.",
"Є декілька шляхів відмини змін в Git. І так само як і коміти, зміни в гіт можна відміняти використовуючи або низькорівневі методи (додавання в коміт окремих файлів) так і високорівневі. Ми зосередемось на останніх.",
"",
"Є два основні шляхи відмін змін в Git -- перший це використовувати `git reset` й інший це `git revert`. В наступному слайді ми подивимося на кожний з них",
"Є два основні шляхи відміни змін в Git -- перший це використовувати `git reset` й інший це `git revert`. В наступному слайді ми подивимося на кожний з них",
""
]
}

View file

@ -224,9 +224,9 @@ exports.level = {
"",
"В нас тут до біса гілок! Давай перенесемо всі зміни з різних гілок в master.",
"",
"Але вищостояще начальство нам не полегшує життя -- вони хочуть щоб всі коміти були по порядку. Це означає що в реузультаті коміт `C7'` має бути з самого низу, `C6'` трохи вище, і так далі, все по порядку.",
"Але вище керівництво нам не полегшує життя -- вони хочуть щоб всі коміти були по порядку. Це означає що в реузультаті коміт `C7'` має бути з самого низу, `C6'` трохи вище, і так далі, все по порядку.",
"",
"Якщо ти щось зробиш не так, сміливо використовуй `reset` щоб почати спочатку. Подивись на наш розв’язок й подумай чи ти можеш обійтись меншою кількістю команд!"
"Якщо ти щось зробиш не так, сміливо використовуй `reset` щоб почати спочатку. Подивись на наш розв’язок і подумай чи ти можеш обійтись меншою кількістю команд!"
]
}
}

View file

@ -243,11 +243,11 @@ exports.level = {
"",
"Ооо Неля! Ну й завданнячко.",
"",
"Ми маємо гілку `master` яка на кілька комітів попереду гілок `one` `two` та `three`. З незрозумілих причин, нам потрібно оновити ці гілки більш пізніми змінами з мастеру.",
"Ми маємо гілку `master`, яка на кілька комітів попереду гілок `one`, `two` та `three`. З незрозумілих причин, нам потрібно оновити ці гілки більш пізніми змінами з мастеру.",
"",
"Гілку `one` портрібно відсортувати по порядоку й видалити `C5`. Гілку `two` потрібно відсортувати, а в гілку `three` потрібно додати ще один коміт!",
"Гілку `one` портрібно відсортувати по порядку і видалити `C5`. Гілку `two` потрібно відсортувати, а в гілку `three` потрібно додати ще один коміт!",
"",
"Ми повністю покладаємось на тебе -- порівняй свій розв’зкок з нашим, який можна подивитись командою `show solution`. "
"Ми повністю покладаємось на тебе -- порівняй свій розв’зок з нашим, який можна подивитись командою `show solution`. "
]
}
}

View file

@ -607,13 +607,13 @@ exports.level = {
"",
"Віддалені репозиторії не є дуже складними. В сучасному світі де на кожному кроці можна зустріти \"хмарні обчислення\" може видатися що концепція віддалених репозиторіїв є дуже складною, але насправді вони просто звичайні копії твого репозиторію на віддаленому комп’ютері. Зазвичай з цим віддаленим комп’ютером можна зв’язатися через інтернет, що дозволяє обмінюватись комітами.",
"",
"Приймаючи до уваги все вищесказане, віддалені репозиторії мають купу гарних властивостей:",
"Приймаючи до уваги все сказане вище, віддалені репозиторії мають купу гарних властивостей:",
"",
"- В першу чергу віддалені сервери це завжди чудова резевна копія (бекап)! Локальний репозиторій дає чудову можливість відкотитися до попереднього стану, але вся інформація зберігається локально. Маючи копії твого репозиторію на віддалених машинах, ти можеш пережити втрату жорсткого диску чи пошкодження данних і продовжити працювати з того місця на якому закінчив",
"- В першу чергу, віддалені сервери це завжди чудова резевна копія (бекап)! Локальний репозиторій дає можливість відкотитися до попереднього стану, але вся інформація зберігається локально. Маючи копії свого репозиторію на віддалених машинах, ти можеш пережити втрату жорсткого диску чи пошкодження данних і продовжити працювати з того місця на якому закінчив.",
"",
"- Що не менш важливо, віддалені репозиториї роблять кодинг соціальним! Коли копія твого проекту розміщена в мережі, твої друзі мають змогу допомогти твому проекту (чи зпулити останні зміни) без зайвих зусиль.",
"- Що не менш важливо, віддалені репозиторії роблять програмування соціальним! Коли копія твого проекту розміщена в мережі, твої друзі мають змогу допомогти твоєму проекту (чи стягнути останні зміни) без зайвих зусиль.",
"",
"Стало дуже популярним користуватися веб сайтами що візуалізують активність на віддалених репозиторіях. (наприклад [Github](https://github.com/) чи [Phabricator](http://phabricator.org/)), але віддалені репозиториї _завжди_ слугують як основа цих сервісів. Тому важливо розуміти їх!"
"Стало дуже популярним користуватися веб сайтами, що візуалізують активність на віддалених репозиторіях (наприклад [Github](https://github.com/) чи [Phabricator](http://phabricator.org/)), але віддалені репозиторії _завжди_ слугують як основа цих сервісів. Тому важливо розуміти їх!"
]
}
},
@ -621,11 +621,11 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"## Команда що створює віддалені репозиториї",
"## Команда що створює віддалені репозиторії",
"",
"До цього моменту, Вчимо Git Гілкування концентрувало увагу на основах роботи з _локальним_ репозиторієм (гілкування, злиття гілок, ребейс, тощо). Однак тепер коли ми вчимо віддалені репозиторії, нам потрібно налаштувати середовище для подальших уроків. `git clone` впорається з цим завданням",
"",
"В принципі, `git clone` в справжньому гіт це команда для створення окальної_ копії віддаленого репозиторію (наприклад з github). Але в Вчимо Git Гілкування ми використовуватимо цю команду по іншому -- `git clone` буде створювати віддалений репозиторій з локального. Я згодний шо це трохи навпаки, але це допоможе створити зв’язок в голові між клонуванням та роботою з віддаленми репо, тому поки що будемо використовувати її таким чином.",
"В принципі, `git clone` в справжньому гіт це команда для створенняокальної_ копії віддаленого репозиторію (наприклад з github). Але у Вчимо Git Гілкування ми використовуватимо цю команду по іншому -- `git clone` буде створювати віддалений репозиторій з локального. Я згодний шо це трохи навпаки, але це допоможе створити зв’язок в голові між клонуванням та роботою з віддаленми репо, тому поки що будемо використовувати її таким чином.",
""
]
}
@ -638,7 +638,7 @@ exports.level = {
""
],
"afterMarkdowns": [
"Ось і все! Тепер ми маємо віддалений репозиторій нашого проекту. Він виглядає досить схоже, хіба що деякі візуальні елементи інші щоб краще показати різницю -- в наступних рівнях ти навчишся як ділитися роботою між цими репозиторіями."
"Ось і все! Тепер ми маємо віддалений репозиторій нашого проекту. Він виглядає досить схоже, хіба що деякі візуальні елементи інші, щоб краще показати різницю -- в наступних рівнях ти навчишся ділитися роботою між цими репозиторіями."
],
"command": "git clone",
"beforeCommand": ""

View file

@ -525,11 +525,11 @@ exports.level = {
"markdowns": [
"## Симулюємо коллаборацію",
"",
"Зараз ми знаходимось в незручному становищі -- в деяких з наступних уроків, нам потрібно пояснити як витягнути зміни з віддаленого репозиторія що були туди додані іншим учасником.",
"Зараз ми знаходимось в незручному становищі -- в деяких з наступних уроків, нам потрібно пояснити як витягнути зміни з віддаленого репозиторію, що були туди додані іншим учасником.",
"",
"Це означає, що нам треба \"вдавати\" що віддалений репозиторій був модифікований твоїм колегою / друзями / небайдужими, іноді на специфічній гілці чи коміті.",
"Це означає, що нам треба \"вдавати\", що віддалений репозиторій був модифікований твоїм колегою / друзями / небайдужими, іноді на специфічній гілці чи коміті.",
"",
"Щоб зробити це, ми додали влучно названу команду `git fakeTeamwork` (симуляціяКолективноїРоботи)! Насправді з симуляцією колективної роботи стикався майбуть кожен хто працював в колективі, тому перейдемо до прикладів..."
"Щоб зробити це, ми додали влучно названу команду `git fakeTeamwork` (симуляціяКолективноїРоботи)! Насправді, з симуляцією колективної роботи стикався мабуть кожен, хто працював в колективі, тому перейдемо до прикладів..."
]
}
},
@ -537,10 +537,10 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"По замовчуванню `fakeTeamwork` просто додасть коміт в мастер"
"За замовчуванням `fakeTeamwork` просто додасть коміт в гілку `master`"
],
"afterMarkdowns": [
"Зробили -- до віддаленого репозиторію додався ще один коміт, проте ми ще його не завантажили, так як не виконали `git fetch`."
"Зробили -- до віддаленого репозиторію додався ще один коміт, проте ми ще його не завантажили, оскільки ще не виконали `git fetch`."
],
"command": "git fakeTeamwork",
"beforeCommand": "git clone"
@ -563,7 +563,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Наступні рівні мають бути досить складними, тому щоб підготуватись, на цьому рівні теж доведеться не солодко.",
"Наступні рівні будуть доволі складними, тому, щоб підготуватись, на цьому рівні теж доведеться не солодко.",
"",
"Зроби віддалений репозиторій (за допомогою `git clone`), зроби кілька фіктивних змін, зроби кілька комітів локально, й підвантаж віддалені зміни. Це як кілька уроків в одному!"
]

View file

@ -692,11 +692,11 @@ exports.level = {
"markdowns": [
"## Git Fetch",
"",
"Робота з віддаленими гіт репозиторіями зводиться до передачі данних _до_ й _з_ інших репозиторіїв. Змога передавати коміти автоматично дає нам можливість передавати будь-яку інформацію що відслідковується гіт. (а отже виконану роботу, нові файли, ідеї, листи, тощо).",
"Робота з віддаленими гіт репозиторіями зводиться до передачі данних _до_ й _з_ інших репозиторіїв. Можливість передавати коміти дозволяє нам ділитися будь-якою інформацією, що відслідковується гіт (а отже виконаною роботою, новими файлами, ідеями, листами, тощо).",
"",
"На цьому уроці ми навчимося витягати данні _з_ віддаленого репозиторію -- команда що відповідає за це зручно називається `git fetch` (fetch англ. витягнути чи дістати - примітка перекл.).",
"На цьому уроці ми навчимося витягати данні _з_ віддаленого репозиторію -- команда, що відповідає за це, зручно називається `git fetch` (fetch - англ. витягнути чи дістати).",
"",
"Зауваж, що коли ми оновлюємо наш віддалений репозиторій, наші _віддалені_ гілки теж оновляться. Про це ми говорили в попередньому уроці."
"Зауваж, що коли ми оновлюємо наш віддалений репозиторій, наші _віддалені_ гілки теж оновляться. Про це ми говорили на попередньому уроці."
]
}
},
@ -704,10 +704,10 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Перед тим як почати розбиратися з `git fetch`, давай спробуємо його в дії! Тут ми маємо віддалений репозиторій який містить два коміти яких не має в нашому локальному сховищі."
"Перед тим, як почати розбиратися з `git fetch`, давай спробуємо його в дії! Тут ми маємо віддалений репозиторій який містить два коміти яких немає в нашому локальному сховищі."
],
"afterMarkdowns": [
"Ось, маєш! Коміти `C2` та `C3` було завантажено до нашого локального сховища, й наша віддалена гілка `o/master` була відповідно оновлена."
"Ось, маєш! Коміти `C2` та `C3` було завантажено до нашого локального сховища й наша віддалена гілка `o/master` була відповідно оновлена."
],
"command": "git fetch",
"beforeCommand": "git clone; git fakeTeamwork 2"
@ -719,16 +719,16 @@ exports.level = {
"markdowns": [
"### Що робить fetch",
"",
"`git fetch` виконує дві основні дії, й тільки дві дії.Він:",
"`git fetch` виконує дві основні дії, й тільки дві дії. Він:",
"",
"* завантажує коміти які містить віддалене сховище але яких немає в локальному сховищі, та...",
"* завантажує коміти які містить віддалене сховище, але яких немає в локальному сховищі, та...",
"* оновлює посилання віддаленого бранчу (наприклад, `o/master`)",
"",
"Якщо коротко `git fetch` приводить репрезентацію віддаленого репозиторію в локальному сховищі до _актуального_ стану справжнього віддаленого репозиторію.",
"",
"Якщо ти пам’ятаєш з попереднього уроку, ми тоді зауважили що віддалені гілки відображають стан віддаленого репозиторію _від_ останнього разу коли ми синхронізувались з віддаленим репозиторієм. `git fetch` якраз і відповідає за синхронізацію з віддаленим сховищем! Сподіваюсь, що зв’язок між віддаленими гілками `git fetch` зараз є очевидним.",
"Якщо ти пам’ятаєш з попереднього уроку, ми тоді зауважили, що віддалені гілки відображають стан віддаленого репозиторію _від_ останнього разу коли ми синхронізувались з віддаленим репозиторієм. `git fetch` якраз і відповідає за синхронізацію з віддаленим сховищем! Сподіваюсь, що зв’язок між віддаленими гілками `git fetch` зараз є очевидним.",
"",
"Як правило `git fetch` працює з віддаленими сховищами через інтернет. (через протоколи `http://` чи `git://`).",
"Як правило, `git fetch` працює з віддаленими сховищами через інтернет (через протоколи `http://` чи `git://`).",
""
]
}
@ -737,13 +737,13 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"### Що не робить fetch",
"### Чого не робить fetch",
"",
"Тим не менш `git fetch` нічого не змінює в _твоєму_ локальному стані. Він не оновить твою гілку`master` й не змінить те як наразі виглядає локальна файлова система.",
"Тим не менш, `git fetch` нічого не змінює в _твоєму_ локальному стані. Він не оновить твою гілку`master` і не змінить того, як наразі виглядає локальна файлова система.",
"",
"Це важливо зрозуміти, тому що багато розробників думають що `git fetch` оновить їхні локальні данні до стану віддаленого репозиторію. Він дійсно завантажить всі потрібні данні, щоб це зробити, але він автоматично _не_ змінить ніяких локальних файлів. Ми вивчимо команди що це роблять в наступних уроках :D",
"Це важливо зрозуміти, тому, що багато розробників думають, що `git fetch` оновить їхні локальні данні до стану віддаленого репозиторію. Він дійсно завантажить всі потрібні данні, щоб це зробити, але він автоматично _не_ змінить ніяких локальних файлів. Ми вивчимо команди, які це роблять в наступних уроках :D",
"",
"Отже в кінці кінців, ти можеш вважати що `git fetch` просто завантажує нову інформацію з віддаленого сховища."
"Отже, зрештою, ти можеш вважати що `git fetch` просто завантажує нову інформацію з віддаленого сховища."
]
}
},
@ -751,7 +751,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Щоб пройти цей рівень просто виконай `git fetch` й завантаж всі коміти!"
"Щоб пройти цей рівень просто виконай `git fetch` і завантаж всі коміти!"
]
}
}

View file

@ -1324,9 +1324,9 @@ exports.level = {
"markdowns": [
"## Diverged Work",
"",
"Ми розглянули як `витягувати` коміти інших та як `завантажувати` свої власні коміти. Це виявилось не надто складно, як же так що в людей дуже часто виникають з цим труднощі?",
"Ми розглянули як витягувати (`pull`) коміти інших та як завантажувати (`push`) свої власні коміти. Це виявилось не надто складно, то як же так, що в людей дуже часто виникають з цим труднощі?",
"",
"Основна складність полягає в тому що історія різних репозиториїв *розбігається* (diverges). Перед тим як вдатися в деталі, давайте подивимось як це виглядає на прикладі...",
"Основна складність полягає в тому що історія різних репозиторіїв *розбігається*. Перед тим як вдатися в деталі, давайте подивимось як це виглядає на прикладі...",
""
]
}
@ -1335,9 +1335,9 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Уяви що ти склонував репозиторій в Понеділок й почав напрацьовувати на якусь фічу. В пятницю фіча готова й ти хочеш повернути її назад (в апстрім) -- але що це? Твої колеги, грець їм, вже встигли вкомітити купу коду що робить твою фічу застарілою (і не дуже доречною). Вони вже запушили ці коміти в публічний репозиторій, й тепер *твоя* робота базується на *старій* версії продукту що вже не актуальна.",
"Уяви, що ти склонував репозиторій в понеділок і почав працювати над якоюсь фічею. В пятницю фіча готова і ти хочеш повернути її назад (в апстрім) -- але що це? Твої колеги, грець їм, вже встигли вкомітити купу коду що робить твою фічу застарілою (і не дуже доречною). Вони вже запушили ці коміти в публічний репозиторій, й тепер *твоя* робота базується на *старій* версії продукту, що вже не актуальна.",
"",
"В цьому випадку команда `git push` неоднозначна. Коли ти виконаєш `git push`, гіт повинен змінити віддалений репозиторій до того стану, на якому він знаходився в Понеділок? Чи він має додати твій код й залишити код твоїх колег? Чи він має повністю проігнорувати твої зміни, так як вони застаріли?",
"В цьому випадку команда `git push` неоднозначна. Коли ти виконаєш `git push`, гіт повинен змінити віддалений репозиторій до того стану, на якому він знаходився в понеділок? Чи він має додати твій код і залишити код твоїх колег? Чи він має повністю проігнорувати твої зміни, оскільки вони застаріли?",
"",
"Через такі неоднозначності в цій ситуації (коли історія розійшлася), git не дозволить тобі запушити твої зміни. Він фактично змушує тебе інтегрувати останні зміни з віддаленого репозиторію перед тим як ти зможеш завантажити на нього свої напрацювання."
]
@ -1360,7 +1360,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Як вийти з цієї ситуації? Це просто, все що треба, це оновити свої напрацювання так щоб вони базувалися на останніх змінах з віддаленої гілки.",
"Як вийти з цієї ситуації? Це просто, все що треба, -- це оновити свої напрацювання так, щоб вони базувалися на останніх змінах з віддаленої гілки.",
"",
"Є кілька шляхів як цього досягнути, але найпростіший це перемістити твою роботу 'вперед' за допомогою rebase. Давай спробуємо, й подивимось як це виглядає"
]
@ -1385,9 +1385,9 @@ exports.level = {
"markdowns": [
"Чи є якийсь інший спосіб оновити свої напрацювання коли віддалений репозиторії пішов вперед? Звісно! Спробуємо зробити те ж саме, але натомість за допомогою `merge` (злиття).",
"",
"Хоча `git merge` й не переміщує твою роботу (а просто створює натомість коміт злиття чи merge commit), це ще один спосіб сказати гіт що ти інтегрував останній стан віддаленого репозиторію в свої зміни. Це працює тому що тепер віддалена гілка є *предком* твоєї гілки, а отже твої останні коміти інтегрують в собі всі коміти з віддаленої гілки.",
"Хоча `git merge` і не переміщує твою роботу (а просто створює натомість коміт злиття чи merge commit), це ще[M#6 один спосіб сказати гіт що ти інтегрував останній стан віддаленого репозиторію в свої зміни. Це працює тому, що тепер віддалена гілка є *предком* твоєї гілки, а отже твої останні коміти інтегрують в собі всі коміти з віддаленої гілки.",
"",
"Невелика демонстрація (шини не потрібні)..."
"Невелика демонстрація..."
]
}
},
@ -1395,10 +1395,10 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Тепер ми зробимо merge заміть rebase..."
"Тепер ми зробимо merge замість rebase..."
],
"afterMarkdowns": [
"Ка-бум! Ми оновили наш локальний образ віддаленої гілки за допомогою `git fetch`, *змерджили* нові напрацювання з власними напрацюваннями (щоб відобразити останні змінни в віддаленій гілці), й відіслали їх за допомогою `git push`"
"Ка-бум! Ми оновили наш локальний образ віддаленої гілки за допомогою `git fetch`, *змерджили* нові напрацювання з власними (щоб відобразити останні змінни в віддаленій гілці), й відіслали їх за допомогою `git push`"
],
"command": "git fetch; git merge o/master; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
@ -1408,9 +1408,9 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Чудово! Чи я можу це зробити використовуючи меншу кількість команд?",
"Чудово! Чи можу я це зробити, використовуючи меншу кількість команд?",
"",
"Звісно -- ти ж знаєш що `git pull` це просто коротша форма для git fetch а потім git merge. Достатньо зручно, `git pull --rebase` це коротка форма для git fetch а потім git rebase!",
"Звісно -- ти ж знаєш що `git pull` це просто коротша форма для git fetch а потім git merge. Доволі зручно, `git pull --rebase` це коротка форма для git fetch а потім git rebase!",
"",
"Давайте спробуємо використати ці коротші команди."
]
@ -1423,7 +1423,7 @@ exports.level = {
"Спочатку з `--rebase`..."
],
"afterMarkdowns": [
"Теж саме що й раніше! Просто трохи коротше."
"Те саме, що й раніше! Просто трохи коротше."
],
"command": "git pull --rebase; git push",
"beforeCommand": "git clone; git fakeTeamwork; git commit"
@ -1433,7 +1433,7 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Й тепер просто з `pull`"
"А тепер просто з `pull`"
],
"afterMarkdowns": [
"Знову, так як і було!"
@ -1446,11 +1446,11 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Робочий процес що складається з fetch, rebase/merge, й push є дуже широковживаним. В наступних уроках ми розглянемо складніші версії цього процесу, а наразі спробуємо його виконати.",
"Робочий процес, що складається з fetch, rebase/merge і push є дуже широковживаним. В наступних уроках ми розглянемо складніші версії цього процесу, а наразі спробуємо його виконати.",
"",
"Щоб пройти цей рівень виконай наступні кроки:",
"",
"* Зклонуй свій репозиторій",
"* Склонуй свій репозиторій",
"* Зроби симуляцію командної роботи (1 коміт)",
"* Зроби власний коміт (1 коміт)",
"* Опублікуй свої напрацювання за допомогою *rebasе*"

View file

@ -570,14 +570,14 @@ exports.level = {
"",
"Тепер, коли ми знаємо як витягувати данні з віддаленого репозиторію за допомогою `git fetch`, давай спробуємо оновити нашу робочу копію відповідно до цих данних!",
"",
"Насправді є кілька шляхів як це досягнути -- як тільки нові коміти з’явилися локально, ти можеш додавати їх в бранчі так само як звичайні коміти. Це означає що ти можеш виконувати команди:",
"Насправді, є кілька шляхів як цого досягнути -- як тільки нові коміти з’явилися локально, ти можеш додавати їх в бранчі так само, як звичайні коміти. Це означає що ти можеш виконувати команди:",
"",
"* `git cherry-pick o/master`",
"* `git rebase o/master`",
"* `git merge o/master`",
"* і так далі, й тому подібне.",
"* і так далі, і тому подібне.",
"",
"Насправді, процес *витягування* віддалених змін й подальший *мерджинг* їх є настільки популярним, що гіт пропонує спеціяльну команду що виконує ці дві дії за один раз! Ця команда називається `git pull`."
"Насправді, процес *витягування* віддалених змін й подальший *мерджинг* їх є настільки популярним, що гіт пропонує спеціальну команду, що виконує ці дві дії за один раз! Ця команда називається `git pull`."
]
}
},
@ -588,7 +588,7 @@ exports.level = {
"Давай спочатку виконаємо по черзі `fetch` а потім `merge`"
],
"afterMarkdowns": [
"Ка-бум -- ми завантажили `C3` за допомогою `fetch` й потім змерджили їх з `git merge o/master`. Тепер наша гілка `master` відповідає гілці з віддаленого сховища (в цьому випадку, з назвою `origin`)"
"Ка-бум -- ми завантажили `C3` за допомогою `fetch` й потім змерджили їх використавши `git merge o/master`. Тепер наша гілка `master` відповідає гілці з віддаленого сховища (в цьому випадку, з назвою `origin`)"
],
"command": "git fetch; git merge o/master",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
@ -598,10 +598,10 @@ exports.level = {
"type": "GitDemonstrationView",
"options": {
"beforeMarkdowns": [
"Що трапится якщо натомість використати `git pull` ?"
"Що трапится якщо натомість використати `git pull`?"
],
"afterMarkdowns": [
"Те ж саме! Тепер очевидно що `git pull` це просто швидкий спосіб зробити `git fetch` а потім змерджити завантажену гілку."
"Те саме! Тепер очевидно що `git pull` -- це просто швидкий спосіб зробити `git fetch` а потім змерджити завантажену гілку."
],
"command": "git pull",
"beforeCommand": "git clone; git commit; git fakeTeamwork"
@ -613,7 +613,7 @@ exports.level = {
"markdowns": [
"Ми розглянемо `git pull` більш детально пізніше (включаючи різні опції та аргументи), наразі просто спробуємо цю команду.",
"",
"Не забувай -- щоб пройти цей рівень достатньо використати `fetch` а потім `merge`, але це буде тобі коштувати одну зайву команду :P"
"Не забувай -- щоб пройти цей рівень, достатньо використати `fetch` а потім `merge`, але це буде тобі коштувати одну зайву команду :P"
]
}
}

View file

@ -416,13 +416,13 @@ exports.level = {
"markdowns": [
"## Git Push",
"",
"OK, я витягнув останні зміни й інтегрував їх в свої локальні напрацювання. Все добре... але як мені поділится _своїми_ змінами з рештою учасників?",
"OK, я витягнув останні зміни та інтегрував їх в свої локальні напрацювання. Все добре... але як мені поділится _своїми_ змінами з рештою учасників?",
"",
"Отже, надсилання данних є по суті протилежне завантажуванню данних. Й який є антонім до `git pull` (притягнути)? `git push` (відштовхнути)!",
"Отже, надсилання данних є по суті протилежне завантажуванню данних. І який є антонім до `git pull` (притягнути)? `git push` (відштовхнути)!",
"",
"`git push` використовується для надсилання _локальних_ змін на вказаний віддалений репозиторій й оновлює цей репозиторій, інтегруючи нові коміти. Після виконання `git push` всі твої друзі зможуть завантажити твої напрацювання з віддаленого сховища.",
"`git push` використовується для надсилання _локальних_ змін на вказаний віддалений репозиторій і оновлює цей репозиторій, інтегруючи нові коміти. Після виконання `git push` всі твої друзі зможуть завантажити твої напрацювання з віддаленого сховища.",
"",
"Ти можеш вважати що `git push` \"публікує\" твої напрацювання. В цій команді є кілька тонких моментів, які ми скоро розглянемо, але давайте почнемо з початку...",
"Ти можеш вважати що `git push` \"публікує\" твої напрацювання. В цій команді є кілька особливостей, які ми скоро розглянемо, але давайте почнемо з початку...",
"",
"*зауваження -- поведінка `git push` без параметрів різниться в залежності від налаштування git з назвою `push.default`. Значення по замовчуванню цього налаштування залежить від версії твого git, але в наших уроках ми будемо вважати що воно рівне `upstream`. Це не вкрай важливо, але буде корисно перевірити це налаштування перед тим як пушити свій проект.*"
]
@ -435,7 +435,7 @@ exports.level = {
"Ось ми маємо деякі зміни яких нема в віддаленому сховищі. Давайте надішлемо їх!"
],
"afterMarkdowns": [
"Ось, маєш -- віддалене сховище отримало `C2`, гілка`master` на ньому була оновлена й посилається на `C2`, й наше *власне* відображення віддаленого репо (`o/master`) було також оновлена. Все синхронізовано!"
"Ось, маєш -- віддалене сховище отримало `C2`, гілка`master` на ньому була оновлена й посилається на `C2`, й наше *власне* відображення віддаленого репо (`o/master`) було також оновлено. Все синхронізовано!"
],
"command": "git push",
"beforeCommand": "git clone; git commit"
@ -445,7 +445,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Щоб пройти цей рівень, просто надішли два коміти у віддалений репозиторій. Але пристібнись, скоро наші уроки стануть набагато важчі!"
"Щоб пройти цей рівень, просто надішли два коміти у віддалений репозиторій. Але пристібнись, скоро наші уроки стануть набагато важчими!"
]
}
}

View file

@ -647,13 +647,13 @@ exports.level = {
"markdowns": [
"## Віддалені гілки",
"",
"Тепер, коли ти познайомився з `git clone` в дії, давайте розглянемо деталі, й подивимось, що дійсно змінилось.",
"Тепер, коли ти познайомився з `git clone` в дії, давай розглянемо деталі й подивимось, що дійсно змінилося.",
"",
"Перше що ти міг помітити, це те що з’явився новий бранч з назвою `o/master`. Такі гілки називаються _віддаленими_ (remote); віддалені гілки в гіт відіграють в певному сенсі унікальну роль, тому в них є деякі спеціяльні властивості, непритаманні іншим гілкам.",
"Перше, що ти міг помітити, це те, що з’явився новий бранч з назвою `o/master`. Такі гілки називаються _віддаленими_ (remote); віддалені гілки в гіт відіграють в певному сенсі унікальну роль, тому в них є деякі спеціальні властивості, непритаманні іншим гілкам.",
"",
"Віддалені гілки відображають _стан_ віддалених репозиториїв (точніше стан віддаленого репо на момент останньої синхронізації). Вони дозволяють відрізняти та відслідковувати локальні зміни та зміни інших учасників -- що є дуже важливим для успішної синхронізації роботи між різними репозиторіями.",
"",
"Важливою властивістю віддалених гілок є те що коли перейти на них ти перейдеш в стан detached `HEAD`. Git робить це спеціяльно, так як неможливо працювати з ними напряму; ти маєш працювати в локальній гілці й по необхідності синхронізуватися з віддаленим репозиторієм (після чого віддалену гілку буде оновлено)."
"Важливою властивістю віддалених гілок є те, що коли перейти на них ти опинишся в стані detached `HEAD`. Git робить це спеціально, так як неможливо працювати з ними напряму; ти маєш працювати в локальній гілці й по необхідності синхронізуватися з віддаленим репозиторієм (після чого віддалену гілку буде оновлено)."
]
}
},
@ -663,15 +663,15 @@ exports.level = {
"markdowns": [
"### Що за `o/`? Або Римський салют",
"",
"Ти можливо здогадуєшся для чого потрібен префікс `o/` на віддалених гілках. Так, є (примусове) правило іменування віддалених гілок -- вони відображаються в форматі:",
"Ти, можливо, здогадуєшся для чого потрібен префікс `o/` на віддалених гілках. Так, є (примусове) правило іменування віддалених гілок -- вони відображаються в форматі:",
"",
"* `<ім’я віддаленого репо>/<ім’я гілки>`",
"",
"Отже, якщо розглянути гілку з назвою `o/master`, то ім’я гілки це `master` а ім’я віддаленого репозиторію це `o`.",
"",
"Більшість розробників насправді називають ім’я головного віддаленого репозиторію `origin` (початок), not `o`. Це настільки поширена практика, що гіт автоматично називає віддалений репозиторій `origin` коли ти його клонуєш.",
"Більшість розробників насправді називають ім’я головного віддаленого репозиторію `origin` (початок), а не `o`. Це настільки поширена практика, що гіт автоматично називає віддалений репозиторій `origin` коли ти його клонуєш.",
"",
"На жаль повністю ім’я `origin` не влізає в наш UI, натомість ми будемо використовувати коротше `o` :( Просто не забудь, коли будеш використовувати звичайний гіт, що твій віддалений репо скоріш за все називається `origin`!",
"На жаль повністю ім’я `origin` не влазить в наш UI, натомість ми будемо використовувати коротше `o` :( Просто не забудь, коли будеш використовувати звичайний гіт, що твій віддалений репо скоріш за все називається `origin`!",
"",
"Це багато інформації, подивимось як це працює на прикладі."
]
@ -684,7 +684,7 @@ exports.level = {
"Давайте зробимо checkout віддаленої гілки й подивимось що буде"
],
"afterMarkdowns": [
"Як бачиш, git перейшов в стан detached `HEAD` й не оновив `o/master` коли ми зробили новий коміт. Це тому, що `o/master` буде оновлено лише тоді коли буде оновлено віддалений репозиторій."
"Як бачиш, git перейшов в стан detached `HEAD` і не оновив `o/master` коли ми зробили новий коміт. Це тому, що `o/master` буде оновлено лише тоді коли буде оновлено віддалений репозиторій."
],
"command": "git checkout o/master; git commit",
"beforeCommand": "git clone"
@ -694,7 +694,7 @@ exports.level = {
"type": "ModalAlert",
"options": {
"markdowns": [
"Щоб пройти цей рівень, зроби один коміт в `master` а потім переключись в `o/master` й закомітся ще раз. Це наглядно продемонструє поведінку віддалених гілок, а також покаже як зміни впливають на стан віддаленого репозиторію."
"Щоб пройти цей рівень, зроби один коміт в `master`, а потім переключись в `o/master` і закомітся ще раз. Це наглядно продемонструє поведінку віддалених гілок, а також покаже як зміни впливають на стан віддаленого репозиторію."
]
}
}