Дослідження історії
Останнє оновлення 2025-01-24 | Редагувати цю сторінку
Приблизний час: 25 хвилин
Огляд
Питання
- Як визначити старі версії файлів?
- Як переглянути свої зміни?
- Як відновити старі версії файлів?
Цілі
- Пояснення, що таке HEAD репозиторію та як його використовувати.
- Визначення та використання ідентифікаторів комітів Git.
- Порівняння різних версій відстежуваних файлів.
- Відновлення старих версій файлів.
Як ми побачили у попередньому епізоді, ми можемо посилатися на коміти
за їх ідентифікаторами. Ви можете звернутися до останнього
коміту робочого каталогу за допомогою ідентифікатора
HEAD
.
Оскільки кожного разу ми додавали невеликі зміни до
guacamole.md
, зараз нам буде легко відстежувати наш
прогрес. Зробімо це, використовуючи HEAD
. Перш ніж ми
почнемо, змінімо guacamole.md
, додавши ще один рядок.
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
An ill-considered change
Тепер подивимося на наш результат.
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index b36abfd..0848c8d 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -4,3 +4,4 @@
* lime
* salt
## Instructions
+An ill-considered change
Це те саме, що ви отримаєте, якщо пропустите HEAD
(спробуйте це).
Але справжня користь полягає у тому, що ви таким чином можете посилатися
на попередні коміти. Наприклад, додаючи ~1
(де “~” - це
тільда), ми посилаємось на коміт зроблений безпосередньо перед
HEAD
.
Якщо ми хочемо побачити різницю між старішими комітами, ми можемо
знову використовувати git diff
, використовуючи для послання
на них HEAD~1
, HEAD~2
тощо:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..b36abfd 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,6 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
Ми також можемо використати команду git show
, яка
показує які зміни ми внесли у будь-якому попередньо зробленому коміті, а
також і повідомлення коміту (на відміну від команди
git diff
яка покаже різницю між комітом та нашим
робочим каталогом).
ВИХІД
commit f22b25e3233b4645dabd0d81e651fe074bd8e73b
Author: Alfredo Linguini <a.linguini@ratatouille.fr>
Date: Thu Aug 22 10:07:21 2013 -0400
Create a template for recipe
diff --git a/guacamole.md b/guacamole.md
new file mode 100644
index 0000000..df0654a
--- /dev/null
+++ b/guacamole.md
@@ -0,0 +1,3 @@
+# Guacamole
+## Ingredients
+## Instructions
Таким чином, ми можемо побудувати ланцюжок комітів. Останній кінець
ланцюжка називається HEAD
; ми можемо посилатися на
попередні коміти, використовуючи нотацію ~
, тому
HEAD~1
означає “попередній коміт”, тоді як
HEAD~123
повертається на 123 коміти назад від того місця,
де ми зараз знаходимось.
Ми також можемо посилатися на коміти, використовуючи їх
ідентифікатори (ці довгі рядки цифр і літер), які можна побачити за
допомогою git log
та git show
. Це унікальні
ідентифікатори змін, де “унікальний” насправді означає унікальний: кожна
зміна будь-якого набору файлів на будь-якому комп’ютері буде мати
унікальний 40-символьний ідентифікатор. Наш перший коміт отримав
ідентифікатор f22b25e3233b4645dabd0d81e651fe074bd8e73b
, тож
спробуймо наступне:
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..93a3e13 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,7 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
+An ill-considered change
Це правильна відповідь, проте, введення випадкових рядків з 40 символів дуже незручно. Тож Git дозволяє нам використовувати тільки перші кілька символів (як правило, сім для проєктів нормального розміру):
ВИХІД
diff --git a/guacamole.md b/guacamole.md
index df0654a..93a3e13 100644
--- a/guacamole.md
+++ b/guacamole.md
@@ -1,3 +1,7 @@
# Guacamole
## Ingredients
+* avocado
+* lime
+* salt
## Instructions
+An ill-considered change
Це чудово! Отже, ми можемо зберегти зміни у файлах і побачити, що ми
змінили. Наступне питання - а як ми можемо відновити їх старіші версії?
Припустимо, що ми передумали щодо останнього оновлення файлу
guacamole.md
(рядок “ill-considered change”).
git status
зараз каже нам, що файл був змінений, але ці
зміни не були додані до зони стейджингу:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Ми можемо повернути цей файл до його попереднього стану за допомогою
git restore
:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
Як можна здогадатися з назви, ‘git restore’ відновлює стару версію
файлу. За замовчуванням git restore
відновлює версію файлу,
записану в HEAD
, який є останнім збереженим комітом. Якщо
ми хочемо повернутися ще раніше, замість цього ми можемо використовувати
ідентифікатор коміту з опцією -s
:
ВИХІД
# Guacamole
## Ingredients
## Instructions
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Звернуть увагу, що зміни зараз знаходяться у зоні стейджінгу та не
були збережені у коміті. Знову ж таки, ми можемо повернути цей файл до
його попереднього стану за допомогою git restore
:
ВИХІД
# Guacamole
## Ingredients
* avocado
* lime
* salt
## Instructions
Важливо пам’ятати, що ми повинні використовувати номер коміту, який
ідентифікує стан репозиторію до зміни, яку ми намагаємося
скасувати. Поширеною помилкою є використання номеру коміту, в якому ми
зробили зміни, які намагаємося скасувати. У наведеному нижче прикладі
нам треба ‘дістати’ передостанній коміт (HEAD~1
), тобто
коміт f22b25e
. Ми використовуємо .
, щоб
позначити всі файли:
Отже, якщо скласти це все разом, то Git працює як зображено у цьому коміксі:
Той факт, що файли можна відновлювати окремо, сприяє змінам в організації роботи. Якщо все знаходиться в одному величезному документі, буде важко (але не неможливо) скасувати зміни у вступі без скасування також змін, внесених пізніше до висновку. З іншого боку, якщо вступ і висновок зберігаються в окремих файлах, рухатися вперед і назад в часі стає набагато легше.
Відновлення старих версій файлу
Дженніфер зробила цього ранку деякі зміни у скрипті Python, над яким вона до цього працювала тижнями, та “зламала” його - він більше не запускається. Вона витратила майже годину, намагаючись виправити його, але безрезультатно…
На щастя, вона використовує Git для відстеження змін у свому проєкті!
Які з наведених нижче команд допоможуть їй відновити останню збережену у
Git версію її скрипту, який називається
data_cruncher.py
?
$ git restore
$ git restore data_cruncher.py
$ git restore -s HEAD~1 data_cruncher.py
$ git restore -s <unique ID of last commit> data_cruncher.py
Як 2, так і 4
Відповідь (5) - як 2, так і 4.
Команда restore
відновлює файли з репозиторію,
перезаписуючи файли у вашому робочому каталозі. Обидві відповіді 2 та 4
відновлюють останню збережену в репозиторії версію файлу
data_cruncher.py
. Відповідь 2 використовує
HEAD
, щоб вказати останній коміт, тоді як
відповідь 4 використовує унікальний ідентифікатор останнього коміту, що
саме й означає HEAD
.
Відповідь 3 замінить data_cruncher.py
його версією з
коміту перед HEAD
, що НЕ є тим, що ми хотіли.
Відповідь 1 призведе до помилки. Вам потрібно вказати файл, який
треба відновити. Якщо вам треба відновити всі файли, скористайтеся
git restore .
Скасування коміту
Дженніфер співпрацює з колегами над її скриптом Python. Вона
зрозуміла, що її останній коміт до репозиторію проєкту містив помилку, і
хоче його скасувати. Дженніфер хоче скасувати його правильним чином, щоб
всі користувачі репозиторію цього проєкту отримали правильні зміни.
Команда git revert [erroneous commit ID]
створить новий
коміт, який скасує помилковий коміт.
Команда git revert
відрізняється від
git restore -s [commit ID] .
тим, що
git restore
повертає файли (де зміни ще не ввійшли до
нового коміту у локальному репозиторії) до їх попереднього стану. У той
час, як git revert
скасовує зміни, які вже внесені до
локального та віддаленого репозиторіїв.
Нижче наведені правильні кроки та пояснення для Дженніфер щодо
користування git revert
. Яка команда відсутня?
________ # Подивіться на історію змін, щоб знайти ідентифікатор коміту
Скопіюйте цей ID (перші кілька символів ID, наприклад 0b1d055).
git revert [commit ID]
Введіть повідомлення для нового коміту.
Збережіть його та закрийте редактор.
Команда git log
зображує історію проєкту з
ідентифікаторами комітів.
Команда git show HEAD
покаже зміни, зроблені в
останньому коміті, і покаже його ID; однак Дженніфер повинна перевірити,
що це правильний коміт, а не нові зміни, які зробив у спільному
репозиторії хтось інший.
Розуміння послідовності дій та історії
Який результат останньої команди в цій послідовності?
BASH
$ cd recipes
$ echo "I like tomatoes, therefore I like ketchup" > ketchup.md
$ git add ketchup.md
$ echo "ketchup enhances pasta dishes" >> ketchup.md
$ git commit -m "My opinions about the red sauce"
$ git restore ketchup.md
$ cat ketchup.md # this will print the content of ketchup.md on screen
ВИХІД
ketchup enhances pasta dishes
ВИХІД
I like tomatoes, therefore I like ketchup
ВИХІД
I like tomatoes, therefore I like ketchup ketchup enhances pasta dishes
ВИХІД
Помилка, оскільки ви змінили ketchup.md, але не виконали коміт
Правильною є відповідь 2.
Зміни, внесені другою командою echo
, будуть зроблені
лише у робочій копії цього файлу, залишаючи версію в зоні стейджингу без
змін. Команда git add ketchup.md
розміщує поточну версію
‘ketchup.md’ в зоні стейджингу.
Тож, коли виконується команда
git commit -m "My opinions about the red sauce"
,
зафіксованою версією ketchup.md
є та, яка знаходиться в
зони стейджингу та буде мати тільки один рядок.
На цьому етапі робоча копія все ще містить другий рядок (та
git status
покаже, що файл змінено). Однак
git restore ketchup.md
замінить робочу копію останньою
збереженою версією ketchup.md
. В результаті,
cat ketchup.md
покаже:
ВИХІД
I like tomatoes, therefore I like ketchup
Перевіримо розуміння
git diff
Розглянемо команду git diff HEAD~9 guacamole.md
. Що ви
очікуєте від цієї команди після виконання? Що насправді відбувається,
коли ви запускаєте її? Чому?
Спробуйте іншу команду, git diff [ID] guacamole.md
, де
[ID] замінено на унікальний ідентифікатор вашого останнього коміту. Що
ви очікуєте, і що насправді станеться?
Скасування змін у зоні стейджингу
Команда git restore
може бути використана для
відновлення попереднього коміту, коли зміни ще не додані до зони
стейджингу. Але чи спрацює вона зі змінами, які були додані до зони
стейджингу, але ще не збережені у коміті? Зробіть зміни у
guacamole.md
, додайте їх до зони стейджингу за допомогою
git add
, а потім використайте git restore
, щоб
перевірити чи можете ви скасувати свої зміни.
Після додавання зміни за допомогою git restore
, команду
git checkout
не можна використовувати безпосередньо.
Подивіться на результат git status
:
ВИХІД
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: guacamole.md
Зауважте, якщо ваш результат відрізняється, то можливо ви забули змінити файл, або вже додали його до зони стейджингу та зробили коміт.
Використання команди git restore guacamole.md
тепер не
викликає помилки, але також не відновлює файл. Git друкує корисне
повідомлення - нам потрібно спочатку використати
git restore --staged
, щоб видалити файл з зони
стейджингу:
Тепер git status
зображує наступне:
ВИХІД
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git git restore <file>..." to discard changes in working directory)
modified: guacamole.md
no changes added to commit (use "git add" and/or "git commit -a")
Це означає, що тепер ми можемо використовувати
git restore
для відновлення файлу до попереднього
коміту:
ВИХІД
On branch main
nothing to commit, working tree clean
Перегляд і пошук в історії
Перегляд історії є важливим аспектом роботи з Git, але зазвичай знайти правильний ідентифікатор коміту може бути важко, особливо якщо він був зроблений декілька місяців тому.
Уявіть, що проєкт recipes
містить понад 50 файлів. Вам
потрібно знайти коміт, який змінює певний текст у
guacamole.md
. Коли ви вводите git log
,
з’являється дуже довгий список. Як можна звузити коло пошуку?
Пам’ятайте, що команда git diff
дозволяє перевіряти
зміни в певному файлі, наприклад, git diff guacamole.md
. Ми
можемо застосувати подібну ідею тут.
На жаль, деякі повідомлення комітів дуже неоднозначні, наприклад,
update files
. Як же переглянути усі ці версії файлу?
Обидві команди git diff
та git log
дуже
корисні для отримання звітів про різні частини історії проєкту. Але чи
можна об’єднати їх результат в одну команду? Спробуймо наступне:
Ви повинні отримати довгий список, у якому ви побачите як повідомлення коміту, так і зроблені зміни.
Питання: Що робить наступна команда?
Ключові моменти
-
git diff
показує відмінності між комітами. -
git restore
відновлює старі версії файлів.