Робота з Git
Уяви, що ти на початку робочого дня. Перед тобою проєкт із кількома файлами, і тобі треба виконати якесь завдання (додати нову функцію, виправити баг тощо). А ще хочеться тримати усе це під контролем версій.
В результаті роботи можуть з’явитися нові файли, якісь із наявних зміняться, а якісь зникнуть. Іншими словами, робоче дерево (working tree) проєкту зміниться.
Це термін, яким Git позначає файли проєкту. Давай зупинимося на мить, щоб з цим розібратися.
(working tree), також відоме як робоча директорія (working directory). Це реальні файли твого проєкту в їхньому поточному стані. Саме цю версію проєкту ти бачиш перед собою і з нею працюєш. Коли хтось каже зміни в робочому дереві, він має на увазі зміни у файлах, які ще не потрапили до Git. Це можуть бути нові файли, зміни в наявних файлах або видалення.
Отже, після довгої роботи у твоєму робочому дереві з’явилися зміни. Хотілося б їх зберегти. Але перед цим треба переглянути всі ці зміни й вирішити, які з них залишити, а які — ні.
На цьому етапі Git може показати, які файли змінилися і які рядки в них було додано, видалено або змінено. Можна переглянути ці зміни, додати потрібні до області підготовки (staging area), а непотрібні відкинути.
(staging area) — це короткочасна пам’ять Git, де він записує, які зміни вибрано для наступного знімка проєкту (у термінах Git він називається комітом (commit); за мить поговоримо про це докладніше).
Скажімо, я цілий день працював над великою зміною в проєкті, а тепер, коли все готово, хочу назавжди зберегти ці зміни в історії проєкту. Я хочу створити (commit) — знімок поточного стану файлів проєкту. Коли коміт створено, він стає частиною історії проєкту, і його майже неможливо змінити або видалити.
Але перед створенням коміту треба точно вирішити, які саме зміни мають до нього потрапити. Найчастіше це всі зроблені зміни. Та іноді краще розділити їх на кілька комітів, щоб історія проєкту залишалася впорядкованою. У такому разі до області підготовки додається лише частина змін, створюється коміт, а потім процес повторюється для решти.
Аналогія: ти миєш машину і заодно доливаєш рідину в бачок омивача. Це дві незалежні зміни, тому їх краще оформити окремими комітами. Інакше в історії змін бачка омивача з’явиться запис Помив машину, що не дуже відповідає суті зміни й може заплутати того, хто потім читатиме цю історію.
Коли зміни обрано та впорядковано, лишається створити сам коміт. Разом із обраними змінами ти можеш залишити опис до коміту, який пояснює, що саме змінилося і чому. Це допомагає зрозуміти історію проєкту, коли ти або хтось інший переглядатиме її пізніше. Після створення коміту ці зміни назавжди зберігаються в Git-репозиторії (ще один Git-жаргонізм для історії проєкту).
(repository) — це довгострокова пам’ять Git. Будь-який створений коміт стає частиною репозиторію.
Деякі коміти можуть бути частиною основної історії проєкту, деякі належать до експериментальних гілок, а деякі — це тимчасові коміти, які потім відкидаються, і так далі. Коміт може бути зовсім маленьким, як виправлення друкарської помилки в одному рядку коду, або великим, як додавання цілої нової функції зі змінами в сотнях файлів.
Репозиторій зберігається в директорії .git у корені твого проєкту. Пам’ятай, що ця директорія за замовчуванням прихована. Якщо пошкодити або видалити її, локальний Git-репозиторій буде зіпсовано.
Ти можеш зупинитися на цьому етапі і мати повну локальну історію свого проєкту. Але надіслати (push) свої зміни та підтягнути (pull) чужі з віддаленого репозиторію — це те, що зазвичай роблять на наступному кроці.
Якщо ти працюєш у команді, саме так можна ділитися своїми змінами з іншими й отримувати їхні оновлення. Твої нові коміти потраплять до віддаленого репозиторію, а звідти підтягнуться всі коміти, які колеги створили з моменту останньої синхронізації.
Але навіть якщо ти працюєш самостійно, це все одно корисно: робота не загубиться, якщо з комп’ютером щось трапиться, а доступ до проєкту матимеш із будь-якого пристрою. Також можна ділитися кодом з іншими, надаючи їм доступ до віддаленого репозиторію.
-
Повертайся до Кроку 2, якщо в проєкті є інші зміни, які вже готові до збереження в історії — підготуй і закоміть ці зміни. За потреби також можна відкинути будь-які непідготовлені зміни, що залишилися.
-
Повертайся до Кроку 1, якщо хочеться продовжити роботу над проєктом і внести ще зміни в робоче дерево.
Спершу все це може здаватися трохи заплутаним, особливо якщо досвіду роботи з контролем версій ще не було. Але з часом цей процес стає природним, і зрештою більшість кроків виконується майже на автоматі.
Проходь курс так, як він і задуманий: маленькими порціями, у сфокусованому лінійному порядку, поступово відкриваючи статті Gitopedia. Будь-коли можна продовжити зі справжнім Git у VS Code/Cursor/Antigravity/Windsurf.
але потрібен вхід