From a236ea91caf0bf697c7e53cb476142b9a4183e00 Mon Sep 17 00:00:00 2001 From: Joel Nitta Date: Sat, 13 Jan 2024 22:50:01 +0900 Subject: [PATCH] New translations 05-history.md (Ukrainian) --- locale/uk/episodes/05-history.md | 185 ++++++++++++------------------- 1 file changed, 68 insertions(+), 117 deletions(-) diff --git a/locale/uk/episodes/05-history.md b/locale/uk/episodes/05-history.md index f8d2bccca..b86a67299 100644 --- a/locale/uk/episodes/05-history.md +++ b/locale/uk/episodes/05-history.md @@ -223,13 +223,13 @@ $ git checkout HEAD mars.txt ## Не втрачайте голову (тобто, HEAD) -Above we used +Вище ми використовували ```bash $ git checkout f22b25e mars.txt ``` -to revert `mars.txt` to its state after the commit `f22b25e`. Проте, будьте обережні! +щоб повернути `mars.txt` до його стану після коміту `f22b25e`. Проте, будьте обережні! Команда `checkout` має інші важливі варіанти використання, та Git не зрозуміє ваших намірів, якщо ви будете неточно вводити команди. Наприклад, якщо ви забудете `mars.txt` у попередній команді. ```bash @@ -270,42 +270,28 @@ HEAD is now at f22b25e Start notes on Mars as a base ## Спрощення загального випадку -If you read the output of `git status` carefully, -you'll see that it includes this hint: +Якщо уважно прочитати результат команди `git status`, ви побачите, що він містить цю підказку: ```output (use "git checkout -- ..." to discard changes in working directory) ``` -As it says, -`git checkout` without a version identifier restores files to the state saved in `HEAD`. -The double dash `--` is needed to separate the names of the files being recovered -from the command itself: -without it, -Git would try to use the name of the file as the commit identifier. +Як сказано раніше, `git checkout` без ідентифікатора версії відновлює файли до стану, збереженого в `HEAD`. +Подвійне тире `--` необхідне, щоб відділити імена файлів, які відновлюються, від самої команди: без подвійного тире Git буде намагатися використати назву файлу як ідентифікатор коміту. :::::::::::::::::::::::::::::::::::::::::::::::::: -The fact that files can be reverted one by one -tends to change the way people organize their work. -If everything is in one large document, -it's hard (but not impossible) to undo changes to the introduction -without also undoing changes made later to the conclusion. -If the introduction and conclusion are stored in separate files, -on the other hand, -moving backward and forward in time becomes much easier. +Той факт, що файли можна відновлювати окремо, сприяє змінам в організації роботи. +Якщо все знаходиться в одному величезному документі, буде важко (але не неможливо) скасувати зміни у вступі без скасування також змін, внесених пізніше до висновку. +З іншого боку, якщо вступ і висновок зберігаються в окремих файлах, рухатися вперед і назад в часі стає набагато легше. ::::::::::::::::::::::::::::::::::::::: challenge -## Recovering Older Versions of a File +## Відновлення старих версій файлу -Jennifer has made changes to the Python script that she has been working on for weeks, and the -modifications she made this morning "broke" the script and it no longer runs. She has spent -\~ 1hr trying to fix it, with no luck... +Дженніфер зробила цього ранку деякі зміни у скрипті Python, над яким вона до цього працювала тижнями, та "зламала" його - він більше не запускається. Вона витратила майже годину, намагаючись виправити його, але безрезультатно... -Luckily, she has been keeping track of her project's versions using Git! Which commands below will -let her recover the last committed version of her Python script called -`data_cruncher.py`? +На щастя, вона використовує Git для відстеження змін у свому проєкті! Які з наведених нижче команд допоможуть їй відновити останню збережену у Git версію її скрипту, який називається `data_cruncher.py`? 1. `$ git checkout HEAD` @@ -319,24 +305,17 @@ let her recover the last committed version of her Python script called ::::::::::::::: solution -## Solution +## Рішення -The answer is (5)-Both 2 and 4. +Відповідь (5) - як 2, так і 4. -The `checkout` command restores files from the repository, overwriting the files in your working -directory. Answers 2 and 4 both restore the _latest_ version _in the repository_ of the file -`data_cruncher.py`. Answer 2 uses `HEAD` to indicate the _latest_, whereas answer 4 uses the -unique ID of the last commit, which is what `HEAD` means. +Команда `checkout` відновлює файли з репозиторію, перезаписуючи файли у ваш робочий каталог. Обидві відповіді 2 та 4 відновлюють _останню збережену в репозиторії_ версію файлу `data_cruncher.py`. Відповідь 2 використовує `HEAD`, щоб вказати _останній_ коміт, тоді як відповідь 4 використовує унікальний ідентифікатор останнього коміту, що саме й означає `HEAD`. -Answer 3 gets the version of `data_cruncher.py` from the commit _before_ `HEAD`, which is NOT -what we wanted. +Відповідь 3 замінить `data_cruncher.py` його версією з коміту _перед_ `HEAD`, що НЕ є тим, що ми хотіли. -Answer 1 can be dangerous! Without a filename, `git checkout` will restore **all files** -in the current directory (and all directories below it) to their state at the commit specified. -This command will restore `data_cruncher.py` to the latest commit version, but it will also -restore _any other files that are changed_ to that version, erasing any changes you may -have made to those files! -As discussed above, you are left in a _detached_ `HEAD` state, and you don't want to be there. +Відповідь 1 може бути небезпечною! Без назви файлу, `git checkout` відновить **всі файли** у поточному каталозі (і усіх підкаталогах нижче нього) до їх стану згідно із вказаним комітом. +Ця команда відновить `data_cruncher.py` до його останньої збереженої версії, але вона також відновить _всі інші файли, які було змінено_ на ту ж саму версію, стираючи будь-які зміни, які ви могли внести до цих файлів! +Як обговорювалося вище, ви перейдете у стан "_detached_ `HEAD`", але ж ви не хочете там бути. ::::::::::::::::::::::::: @@ -344,41 +323,31 @@ As discussed above, you are left in a _detached_ `HEAD` state, and you don't wan ::::::::::::::::::::::::::::::::::::::: challenge -## Reverting a Commit +## Скасування коміту -Jennifer is collaborating with colleagues on her Python script. She -realizes her last commit to the project's repository contained an error, and -wants to undo it. Jennifer wants to undo correctly so everyone in the project's -repository gets the correct change. The command `git revert [erroneous commit ID]` will create a -new commit that reverses the erroneous commit. +Дженніфер співпрацює з колегами над її скриптом Python. Вона зрозуміла, що її останній коміт до репозиторію проєкту містив помилку, і хоче його скасувати. Дженніфер хоче скасувати його правильним чином, щоб всі користувачі репозиторію цього проєкту отримали правильні зміни. Команда `git revert [erroneous commit ID]` створить новий коміт, який скасує помилковий коміт. -The command `git revert` is -different from `git checkout [commit ID]` because `git checkout` returns the -files not yet committed within the local repository to a previous state, whereas `git revert` -reverses changes committed to the local and project repositories. +Команда `git revert` відрізняється від `git checkout [commit ID]`, оскільки `git checkout` повертає файли, зміни у яких ще не ввійшли до нового коміту у локальному репозиторії, до їх попереднього стану, тоді як `git revert` скасовує зміни, які вже внесені до локального та віддаленого репозиторіїв. -Below are the right steps and explanations for Jennifer to use `git revert`, -what is the missing command? +Нижче наведені правильні кроки та пояснення для Дженніфер щодо користування `git revert`. Яка команда відсутня? -1. `________ # Look at the git history of the project to find the commit ID` +1. `________ # Подивіться на історію змін, щоб знайти ідентифікатор коміту` -2. Copy the ID (the first few characters of the ID, e.g. 0b1d055). +2. Скопіюйте цей ID (перші кілька символів ID, наприклад 0b1d055). 3. `git revert [commit ID]` -4. Type in the new commit message. +4. Введіть повідомлення для нового коміту. -5. Save and close +5. Збережіть його та закрийте редактор. ::::::::::::::: solution -## Solution +## Рішення -The command `git log` lists project history with commit IDs. +Команда `git log` зображує історію проєкту з ідентифікаторами комітів. -The command `git show HEAD` shows changes made at the latest commit, and lists -the commit ID; however, Jennifer should double-check it is the correct commit, and no one -else has committed changes to the repository. +Команда `git show HEAD` покаже зміни, зроблені в останньому коміті, і покаже його ID; однак Дженніфер повинна перевірити, що це правильний коміт, а не зміни, які зробив у репозиторії хтось інший. ::::::::::::::::::::::::: @@ -386,9 +355,9 @@ else has committed changes to the repository. ::::::::::::::::::::::::::::::::::::::: challenge -## Understanding Workflow and History +## Розуміння послідовності дій та історії -What is the output of the last command in +Який результат останньої команди в цій послідовності? ```bash $ cd planets @@ -423,23 +392,18 @@ Error because you have changed venus.txt without committing the changes ::::::::::::::: solution -## Solution +## Відповідь -The answer is 2. +Правильною є відповідь 2. -The command `git add venus.txt` places the current version of `venus.txt` into the staging area. -The changes to the file from the second `echo` command are only applied to the working copy, -not the version in the staging area. +Команда `git add venus.txt` розміщує поточну версію 'venus.txt' в зоні стейджингу. +Зміни до файлу з другої команди `echo` будуть зроблені лише у робочій копії цього файлу, але не у його версії в зоні стейджингу. -So, when `git commit -m "Comment on Venus as an unsuitable base"` is executed, -the version of `venus.txt` committed to the repository is the one from the staging area and -has only one line. +Тож, коли виконується команда `git commit -m "Comment on Venus as an unsuitable base"`, версія `venus.txt`, яка буде збережена у коміті, буде з зони стейджингу та буде мати тільки один рядок. -At this time, the working copy still has the second line (and -`git status` will show that the file is modified). However, `git checkout HEAD venus.txt` -replaces the working copy with the most recently committed version of `venus.txt`. +На цей час робоча копія файлу ще має другий рядок (і тому `git status` покаже, що файл змінено). Однак `git checkout HEAD venus.txt` замінить робочу копію останньою збереженою версією `venus.txt`. -So, `cat venus.txt` will output +Тож, `cat venus.txt` покаже ```output Venus is beautiful and full of love. @@ -451,32 +415,27 @@ Venus is beautiful and full of love. ::::::::::::::::::::::::::::::::::::::: challenge -## Checking Understanding of `git diff` +## Перевірка розуміння `git diff` -Consider this command: `git diff HEAD~9 mars.txt`. What do you predict this command -will do if you execute it? What happens when you do execute it? Why? +Розглянемо цю команду: `git diff HEAD~9 mars.txt`. Що, на вашу думку, зробить ця команда, якщо ви її виконаєте? Що станеться, коли ви її виконаєте? Чому? -Try another command, `git diff [ID] mars.txt`, where [ID] is replaced with -the unique identifier for your most recent commit. What do you think will happen, -and what does happen? +Спробуйте іншу команду, `git diff [ID] mars.txt`, де [ID] замінено на унікальний ідентифікатор вашого останнього коміту. Як ви думаєте, що вона зробить? Виконайте її та перевірте, чи це так. :::::::::::::::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::::: challenge -## Getting Rid of Staged Changes +## Скасування змін у зоні стейджингу -`git checkout` can be used to restore a previous commit when unstaged changes have -been made, but will it also work for changes that have been staged but not committed? -Make a change to `mars.txt`, add that change using `git add`, -then use `git checkout` to see if you can remove your change. +Команда `git checkout` може бути використана для відновлення попереднього коміту, коли зміни були зроблені, але ще не додані до зони стейджингу. Але чи спрацює вона і для змін, які були додані до зони стейджингу, але не ще збережені у коміті? +Зробіть зміни у `mars.txt`, додайте їх до зони стейджингу за допомогою `git add`, та використайте `git checkout`, щоб побачити чи можете ви скасувати свої зміни. ::::::::::::::: solution -## Solution +## Відповідь -After adding a change, `git checkout` can not be used directly. -Let's look at the output of `git status`: +Після додавання зміни за допомогою `git add`, команду `git checkout` не можна використовувати безпосередньо. +Подивіться на результат `git status`: ```output On branch main @@ -487,14 +446,10 @@ Changes to be committed: ``` -Note that if you don't have the same output -you may either have forgotten to change the file, -or you have added it _and_ committed it. +Зауважте, що якщо ви не маєте такого самого результату, то можливо, ви забули змінити файл, або ви не тільки додали його до зони стейджингу, _а також_ зробили коміт. -Using the command `git checkout -- mars.txt` now does not give an error, -but it does not restore the file either. -Git helpfully tells us that we need to use `git reset` first -to unstage the file: +Використання команди `git checkout -- mars.txt` тепер не дає помилки, але також не відновлює файл. +Git зображує корисне повідомлення - нам потрібно спочатку використати `git reset`, щоб видалити файл з зони стейджингу: ```bash $ git reset HEAD mars.txt @@ -505,7 +460,7 @@ Unstaged changes after reset: M mars.txt ``` -Now, `git status` gives us: +Тепер `git status` зображує наступне: ```bash $ git status @@ -522,8 +477,8 @@ Changes not staged for commit: no changes added to commit (use "git add" and/or "git commit -a") ``` -This means we can now use `git checkout` to restore the file -to the previous commit: +Це означає, що тепер ми можемо використовувати `git checkout`, щоб відновити файл +до попереднього коміту: ```bash $ git checkout -- mars.txt @@ -541,38 +496,34 @@ nothing to commit, working tree clean ::::::::::::::::::::::::::::::::::::::: challenge -## Explore and Summarize Histories +## Перегляд історії -Exploring history is an important part of Git, and often it is a challenge to find -the right commit ID, especially if the commit is from several months ago. +Перегляд історії є важливою частиною роботи з Git, але часто нелегко знайти правильний ідентифікатор коміту, особливо якщо коміт був зроблений декілька місяців тому. -Imagine the `planets` project has more than 50 files. -You would like to find a commit that modifies some specific text in `mars.txt`. -When you type `git log`, a very long list appeared. -How can you narrow down the search? +Уявіть, що проєкт `planets` має більш ніж 50 файлів. +Ви хотіли б знайти коміт, який змінює певний текст у `mars.txt`. +Коли ви вводите `git log`, з'являється дуже довгий список. +Як можна звузити коло пошуку? -Recall that the `git diff` command allows us to explore one specific file, -e.g., `git diff mars.txt`. We can apply a similar idea here. +Нагадаємо, що команда `git diff` може використовуватись для одного конкретного файлу, наприклад, `git diff mars.txt`. Ми можемо застосувати тут подібну ідею. ```bash $ git log mars.txt ``` -Unfortunately some of these commit messages are very ambiguous, e.g., `update files`. -How can you search through these files? +На жаль, деякі з цих повідомлень комітів дуже неоднозначні, наприклад, `update files`. +Як же переглянути усі ці версії файлу? -Both `git diff` and `git log` are very useful and they summarize a different part of the history -for you. -Is it possible to combine both? Let's try the following: +Обидві команди `git diff` та `git log` дуже корисні для отримання звітів про різні деталі історії проєкту. +Але чи можна об'єднати їх результат в одну команду? Давайте спробуємо наступне: ```bash $ git log --patch mars.txt ``` -You should get a long list of output, and you should be able to see both commit messages and -the difference between each commit. +Ви повинні отримати довгий список, у якому ви побачите як повідомлення коміту, так і зроблені зміни. -Question: What does the following command do? +Питання: Що робить наступна команда? ```bash $ git log --patch HEAD~9 *.txt @@ -582,7 +533,7 @@ $ git log --patch HEAD~9 *.txt :::::::::::::::::::::::::::::::::::::::: keypoints -- `git diff` displays differences between commits. -- `git checkout` recovers old versions of files. +- `git diff` відображає відмінності між комітами. +- `git checkout` відновлює старі версії файлів. ::::::::::::::::::::::::::::::::::::::::::::::::::