Git: будь-яку зміну можна відкотити

Що ти зробиш сьогодні

Теорія

1. Навіщо потрібен git

Ситуація, яка трапляється з кожним. Сервіс працює. Ти відкриваєш main.py, міняєш кілька рядків, перезапускаєш службу — програму, яку система запускає сама й тримає запущеною постійно; твоя зветься club-api, з нею ти працював на занятті 02, — і сторінка більше не відкривається. Що саме ти змінив десять хвилин тому, вже не пам’ятаєш: правок було чотири в трьох місцях файлу.

Звичайний спосіб захиститися — копії: main2.py, main_stare.py, main_finalne.py. Через тиждень з цих копій нічого не зрозуміло. Яка з них робоча? Чим main2.py відрізняється від main_stare.py? Коли саме з’явилася помилка? Копії відповіді на ці питання не дають.

Git — програма, яка зберігає історію змін у теці проєкту. Вона запам’ятовує, які саме рядки в яких файлах змінилися, коли це сталося і що ти написав про цю зміну, і вміє повернути будь-який попередній стан.

Репозиторій

Тека проєкту разом із усією історією змін. Історія лежить у прихованій підтеці .git всередині неї — прихованій, бо її назва починається з крапки, і звичайна команда ls такі назви не показує.

Робоча копія

Файли, які ти бачиш і редагуєш: main.py, README.md та інші. Це поточний стан проєкту; історія змін зберігається окремо, у теці .git.

Тека ~/app у тебе вже є репозиторієм: git там увімкнули, коли створювали акаунт, і зробили перший коміт із заготовкою. Сьогодні ти в цьому переконаєшся на першому кроці практики.

2. Коміт і історія

Коміт — записаний стан усіх файлів проєкту на той момент, коли ти виконав команду. У кожному коміті зберігається: вміст файлів, дата й час, ім’я автора, твоє повідомлення про те, що змінилося, і хеш — рядок із літер і цифр, який git обчислює сам. Хеш — це ідентифікатор коміта: за ним коміт знаходять і на нього посилаються. Повний хеш має 40 символів, наприклад a3f19c2b6d41e0f8c95a7b23d4e6f1908c7a5b3d, але git майже скрізь друкує тільки перші сім: a3f19c2. Цього скорочення достатньо, щоб відрізнити один коміт від іншого — на практиці два різні коміти не отримують однакового хеша.

Кожен коміт зберігає посилання на попередній, тому коміти утворюють послідовність. Завдяки цьому історію можна прочитати згори вниз командою git log. У прикладі нижче трапляється слово ендпоінт — так із заняття 02 називають окрему адресу, за якою твоя програма щось відповідає: /api/ping, /api/about.

git log --oneline

7c1a9e4 оновив README описом продукту
b83d0f1 виправив заголовок сторінки
5e2ab77 додав ендпоінт /api/about
a3f19c2 додав .gitignore
9f04c88 Заготовка проєкту

Приклад із твого вечора. О 19:40 ти зробив коміт «додав ендпоінт /api/about» — тоді все працювало. О 20:15 сервіс перестав відповідати. Історія показує, що між цими моментами був рівно один коміт, а решта змін ще не збережена. Значить, шукати треба у файлах, змінених після 19:40, і в найгіршому разі можна повернути стан на 19:40 і почати заново — код за цю дату нікуди не подівся.

3. Три стани, у яких буває змінений файл

Між зміненим файлом і комітом є проміжний крок, і саме на ньому найчастіше плутаються. Змінений файл спочатку потрапляє в індекс (англійською staging) — список змін, підготовлених до наступного коміта. Команда git add кладе зміни в цей список, команда git commit записує в історію те, що в ньому зібралося.

робоча копія  --git add-->  індекс  --git commit-->  історія

Побачити обидва списки одразу можна командою git status: зверху йде те, що вже в індексі й потрапить у наступний коміт, нижче — те, що змінено, але в індекс не додано.

Навіщо цей проміжний крок. За вечір ти виправив помилку в main.py й заодно переписав README.md. Це дві різні справи, і в історії їм краще бути двома комітами з різними повідомленнями. Індекс дозволяє покласти в коміт лише частину змін: git add main.py, коміт, потім git add README.md, ще один коміт.

Важлива деталь. У коміт іде та версія файлу, яка була на момент git add. Якщо після git add ти ще раз відредагував файл, останні правки лишаться поза комітом, поки ти не виконаєш git add вдруге. git status у такому разі показує один і той самий файл у двох списках одночасно.

4. Повідомлення коміта

Повідомлення пишеться для людини, яка читатиме історію, — найчастіше для тебе самого через місяць. Самому git усе одно, що там написано. Хороше повідомлення одним рядком відповідає на питання «що змінилося в проєкті».

У таблиці нижче трапляється число 500. Це код відповіді сервера: він означає, що запит дійшов до програми, але під час обробки програма завершилася з помилкою. Коди відповідей ти бачив на занятті 02: 200 — усе добре, 404 — такого шляху немає, 500 — помилка всередині програми.

Практичні правила: один рядок, приблизно до 70 символів; починати з дієслова («додав», «виправив», «переписав»); писати про зміст зміни — «додав ендпоінт /api/about» замість «змінив main.py». Якщо в повідомленні хочеться написати «і», це майже завжди означає, що змін дві й комітів теж має бути два.

5. Що не кладуть у репозиторій і навіщо .gitignore

.gitignore — файл зі списком того, що git навмисно не зберігає. Кожен рядок у ньому — правило: назва файлу, назва теки або шаблон на кшталт *.db, де зірочка означає «будь-яка послідовність символів».

Не кладуть у репозиторій три групи файлів.

• Те, що відновлюється однією командою. Віртуальне оточення (venv) — окрема тека з бібліотеками для одного проєкту. Створює її команда python3 -m venv venv; pip потім лише встановлює бібліотеки всередину. Тека важить сотні мегабайтів і на іншому комп’ютері все одно не запрацює: у ній записані шляхи конкретної системи. Сюди ж тека __pycache__: перед запуском Python переводить твій код у проміжний вигляд, зрозуміліший йому самому, і складає результат у цю теку, щоб наступного разу не робити цього знову. Такі файли Python створює сам, тому зберігати їх у git не треба.
• Дані. Файл бази лежить у ~/data і змінюється щоразу, коли хтось додає запис. Історія коду й дані користувачів — різні речі, і зберігати їх треба окремо: для бази на занятті 11 буде окремий бекап.
• Секрети. Файл .env — це текстовий файл із паролями та ключами, які програма читає під час запуску. Він з’явиться в тебе на занятті 07. Пароль, який потрапив у репозиторій, вважається розкритим, навіть якщо його звідти прибрали.

Тепер важливе про те, як .gitignore працює. Файл, який хоч раз потрапив у коміт, називається відстежуваним: git знає про нього і стежить за його змінами. Правила .gitignore діють тільки на невідстежувані файли. Якщо ти закомітив .env, а потім дописав його в .gitignore, git продовжить його зберігати, а стара копія з паролем назавжди залишиться в історії. Саме тому .gitignore пишуть заздалегідь — до того, як такі файли з’являються.

6. Відкат: чотири різні ситуації

«Відкотити» означає різні речі залежно від того, що саме сталося. Розберемо чотири випадки й команду до кожного.

Ситуація перша: зіпсував файл і ще не комітив. Команда повертає файл до стану з останнього коміта.

git restore main.py

Ситуація друга: не пам’ятаю, що саме змінив. Команда друкує рядки, які відрізняються від останнього коміта: із мінусом — те, що було, із плюсом — те, що стало.

git diff

Ситуація третя: треба повернути файл до стану з давнього коміта. Береш хеш із git log --oneline і вказуєш його як джерело.

git restore --source=a3f19c2 main.py

Ситуація четверта: коміт уже зроблений, а зміни виявилися невдалими. Команда git revert створює новий коміт, який скасовує зміни вказаного. Історія при цьому не стирається: видно і невдалу спробу, і її скасування.

git revert a3f19c2

7. Гілка

Гілка — окрема лінія комітів усередині того самого репозиторію. Основна гілка в наших проєктах називається master: у ній лежить те, що працює. Коли ти хочеш спробувати щось ризиковане, ти створюєш другу гілку й комітиш у неї. Коміти, зроблені в другій гілці, у master не потрапляють.

Приклад. Ти вирішив повністю переробити сторінку сервісу: інша структура, інші кольори, дві години роботи, і невідомо, чи вийде краще. Створюєш гілку feature/nova-storinka (feature — прийнята назва для гілок із новими можливостями; коса риска в назві дозволена), працюєш у ній. Якщо вийшло — переносиш зміни в master. Якщо ні — просто перемикаєшся назад, і всі файли master стають такими, якими були до експерименту.

git switch -c feature/nova-storinka   # створити гілку й перейти в неї
git switch master                     # повернутися на основну
git branch                            # список гілок, зірочка проти поточної

Перемикання гілки змінює файли в теці. Ти виконуєш git switch master — і www-index.html знову має той вміст, що в master. Це не втрата: коміти другої гілки лишилися на місці, повернешся в неї — повернеться і її версія файлів.

8. Віддалений репозиторій

Remote (вимовляється «рімоут») — адреса іншого репозиторію, з яким твій обмінюється комітами. Найвідоміший приклад такого репозиторію — GitHub, але remote може бути й просто текою на тому самому сервері. У тебе він уже є: це ~/repo.git. Коротка назва для нього — origin: саме її пишуть у командах замість повного шляху.

~/repo.git — bare-репозиторій (вимовляється «бер»), тобто репозиторій без робочої копії: тільки історія, самих файлів main.py чи README.md там немає. Туди не заходять редагувати код, туди надсилають коміти командою git push.

git push origin master

Читається так: надішли в репозиторій origin коміти гілки master. Надсилаються тільки ті коміти, яких там ще немає.

Навіщо це потрібно на тому самому сервері. По-перше, історія зберігається окремо від робочих файлів: якщо ти помилково видалиш або зіпсуєш теку ~/app, коміти вціліють у ~/repo.git, і проєкт можна відновити. По-друге, на занятті 09 саме звідти забиратиме код скрипт deploy.sh: викочування нової версії перетворюється на одну команду.

Практика

Далі скрізь замість bohdan.g9 підставляй свій логін. Усі команди git виконуються всередині теки репозиторію, тобто в ~/app.

ssh bohdan.g9@91.219.61.4
cd ~/app
pwd

git config --global user.name "Богдан"
git config --global user.email "bohdan.g9@club.local"

git config --global --list

ls -a ~/app
git log --oneline
git status
git remote -v

nano ~/app/.gitignore

# те, що відновлюється однією командою
__pycache__/
*.pyc
venv/
.venv/

# дані, які створює програма
*.db
*.sqlite3
data/

# секрети
.env

git status

git add .gitignore
git status

git commit -m "додав .gitignore: git не стежить за кешем, базою і .env"

git status

git add project.yaml
git commit -m "заповнив project.yaml: назва продукту, автор і три функції"

git add BRIEF.md
git commit -m "додав BRIEF.md з описом користувача і задачі"

git add main.py
git commit -m "додав ендпоінт /api/about з даними брифу"

grep ExecStart ~/.config/systemd/user/club-api.service

nano ~/app/README.md

## Що це

Список робіт для художньої школи. Оля, 11 років, записує туди
роботи й дати здачі та бачить, яка робота наступна. Без цього
дати розкидані по трьох зошитах і половина губиться.

## Як запустити

Сервіс працює на сервері як служба club-api: systemd запускає
її сам після перезавантаження сервера.

    systemctl --user status club-api      # стан служби
    systemctl --user restart club-api     # перезапуск після зміни коду
    journalctl --user -u club-api -n 30   # останні 30 рядків журналу

Перевірити, що відповідає (замість 9536 підстав свій порт):

    curl http://127.0.0.1:9536/api/ping

git add README.md
git commit -m "переписав README: розділи «Що це» і «Як запустити» під свій сервіс"

cp ~/www/index.html ~/app/www-index.html
git add www-index.html
git commit -m "додав www-index.html: копія сторінки сайту з заголовком і описом"

git log --oneline

git ls-files

git check-ignore -v .env

nano ~/app/main.py

import nemaye_takoyi_biblioteky

systemctl --user restart club-api
systemctl --user status club-api

journalctl --user -u club-api -n 15
curl -I http://91.219.61.4/u/$USER/api/ping

cd ~/app
git diff
git restore main.py
git diff

systemctl --user restart club-api
curl http://91.219.61.4/u/$USER/api/ping

git switch -c feature/nova-storinka
git branch

nano ~/app/www-index.html
git add www-index.html
git commit -m "проба: інший заголовок і порядок блоків на сторінці"

git switch master
head -25 www-index.html
git log --oneline

git branch --show-current

git push origin master
git push origin feature/nova-storinka

 * [new branch]      master -> master

   9f04c88..b83d0f1  master -> master

git -C ~/repo.git log --oneline master
git -C ~/repo.git branch

git status
git log --oneline
git ls-files
git branch

Що перевіряє автоматика

Шість критеріїв заняття 03. П’ять перевіряє програма, шостий відмічає викладач під час розбору. Перевірка запускається за розкладом, тому відмітка в кабінеті з’являється не в ту саму секунду, коли ти виконав команду.

Домашнє завдання

cd ~/app
git add README.md
git commit -m "пояснив у README, що сервіс працює на сервері, а не на моєму ноутбуці"
git push origin master

Якщо щось не працює

git commit пише «Please tell me who you are»

Git не знає, чиїм іменем підписувати коміт. Виконай два рядки з кроку 2 практики:

git config --global user.name "Богдан"
git config --global user.email "bohdan.g9@club.local"

Після цього повтори git commit — раніше введена команда не пропала, просто коміт не був створений. Перевірити, що ім’я записалося, можна командою git config --global --list.

git status каже «nothing to commit, working tree clean», хоча ти щойно правив файл

Git бачить файли на диску, а не те, що на екрані в редакторі. Найчастіша причина — файл не збережений: у nano треба натиснути Ctrl+O, потім Enter, і лише потім Ctrl+X. Друга причина — редагували не той файл: перевір дату зміни командою ls -l ~/app, у потрібного файлу час має бути свіжий. Третя — ти виконуєш git не в тій теці: pwd має друкувати /home/bohdan.g9/app.

Файл не потрапляє в коміт, у git status його взагалі немає

Швидше за все, він підпадає під правило з .gitignore. Спитай git прямо:

git check-ignore -v shlyah/do/faylu

Команда надрукує рядок із номером правила, яке його виключає. Якщо правило зайве — прибери його з .gitignore. Якщо правило потрібне, а конкретний файл усе ж треба зберегти, його додають примусово: git add -f назва_файлу. Для .env, бази й кешу так робити не можна — саме їх правила й мають зупиняти.

git push відповідає «src refspec … does not match any» або «Updates were rejected»

Перший текст означає, що гілки з такою назвою в тебе немає: ти надсилаєш main, а гілка називається master. Дивись назву й підставляй її:

git branch --show-current
git push origin master

Другий текст означає, що в ~/repo.git уже є коміти, яких немає в тебе. На цьому сервері в твій репозиторій пише тільки ти, тому таке трапляється, якщо ти працював у двох місцях. Забери те, чого в тебе немає, і надішли своє:

git pull --rebase origin master
git push origin master

Ключ --rebase тут обов’язковий. Без нього git 2.27 і новіші зупиняться з повідомленням fatal: Need to specify how to reconcile divergent branches і не зроблять нічого: git не вибирає сам, як поєднати дві розбіжні історії. З --rebase він спершу забирає коміти з ~/repo.git, а потім укладає твої поверх них. Щоб не писати цей ключ щоразу, виконай один раз:

git config --global pull.rebase true

Файл повернувся, а сервіс усе одно не відповідає

Служба тримає в пам’яті ту версію коду, з якою її запустили. Після git restore її треба перезапустити:

systemctl --user restart club-api
systemctl --user status club-api

Якщо стан і далі failed, читай останні рядки журналу: journalctl --user -u club-api -n 30 — там буде назва файлу й номер рядка з помилкою. Перевір, що робоча копія справді чиста: git status має сказати working tree clean, а git diff — нічого не надрукувати.

Окремий випадок. HEAD — службова позначка git, яка показує, на якому коміті ти зараз стоїш; зазвичай вона вказує на гілку, наприклад на master. Стара команда git checkout уміє перемикатися і на гілку, і просто на хеш коміта; у другому разі HEAD вказує на коміт без гілки. Такий стан git називає detached HEAD і пише про нього в терміналі кількома рядками. Це означає, що ти дивишся старий стан історії, і коміти, зроблені зараз, не потраплять у жодну гілку. Повернися на основну гілку командою git switch master.