Що таке Git і чому без нього неможливо працювати з кодом

Є ситуація, знайома кожному, хто хоч раз писав щось складніше однієї команди: ти змінив файл, все зламав, але не пам’ятаєш, що саме змінив. Чи то треба було видалити той рядок, чи залишити. А раптом нова версія працює гірше за попередню. І як повернути те, що було вчора.

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

Навіть якщо ти працюєш один — Git тобі потрібен. Якщо працюєш у команді — він необхідний як повітря.

Проблема / контекст: як люди жили без Git

До появи систем контролю версій працювали приблизно так:

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

Як це працює простими словами

Git працює за простою моделлю. Уявіть три зони:

Робоча директорія (working directory)

Це те, що ти бачиш у файловому менеджері: файли проєкту, які ти редагуєш. Тут ти пишеш, видаляєш, додаєш коди.

Стaging area (індекс)

Це «корзина для комітів» — ти вирішуєш, які саме зміни хочеш зберегти. Не кожен файл з робочої директорії обов’язково потрапляє в коміт. Можеш обрати лише ті, що готові.

Локальний репозиторій

Тут живуть всі коміти — історія всіх збережених станів. Кожен коміт має унікальний ID, повідомлення, автора і дату. Можна повертатися до будь-якого з них.

Потік виглядає так:

  1. Редагуєш файли в робочій директорії.
  2. Додаєш зміни в staging area: git add.
  3. Комітиш: git commit — і Git фіксує стан.
  4. (Опціонально) Відправляєш у віддалений репозиторій: git push.

Базові команди, які потрібні кожному

Не треба вчити все одразу. Ось мінімум для початку:

Початок роботи

git init                  # ініціалізувати новий репозиторій в поточній папці
git clone URL            # скопіювати існуючий репозиторій з GitHub / GitLab
git config --global user.name "Твоє ім'я"      # задати ім'я для комітів
git config --global user.email "email@example.com"  # задати email

Щоденна робота

git status                # що змінилося з останнього коміту
git add файл.txt          # додати файл до наступного коміту
git add .                 # додати всі зміни
git commit -m "опис змін"  # зберегти зміни з коментарем
git log                   # подивитися історію комітів

Робота з віддаленим репозиторієм

git remote add origin URL  # зв'язати з віддаленим репозиторієм
git push origin main       # відправити зміни на сервер
git pull origin main       # отримати зміни з сервера

Гілки

git branch                  # показати всі гілки
git branch нова_фіча        # створити нову гілку
git checkout нова_фіча      # перейти на іншу гілку
# аби скористатися скороченою командою:
git checkout -b нова_фіча   # створити і одразу перейти на гілку
git merge нова_фіча         # злити зміни з «нова_фіча» в поточну гілку
git branch -d нова_фіча     # видалити гілку після злиття

Навіщо потрібні гілки

Гілка — це окрема лінія розробки. Припустимо, ти працюєш над веб-сайтом. Наразі є основна гілка main — це стабільна версія, яка працює.

Тепер ти хочеш додати нову кнопку, але не впевнений, що все вийде добре. Замість того, щоб ламати main, ти створюєш гілку:

git checkout -b feature/new-button

Працюєш в цій гілці: робиш зміни, комітиш. Якщо все добре — зливаєш в main:

git checkout main
git merge feature/new-button

Якщо щось пішло не так — просто видаляєш гілку, і main залишається чистим. Жодного хаосу.

В команді це ще корисніше: кожний розробник працює у своїй гілці і не заважає іншим. Коли фіча готова — її зливають з основною версією через code review або без.

Як працює віддалений репозиторій

Віддалений репозиторій — це копія твого проєкту на сервері GitHub, GitLab або будь-якому іншому. Це потрібно для:

Типові помилки початківця

1. Не робити коміти або робити занадто великі

Коли ти працюєш годину і комітиш все в один git commit -m "fixes", не тільки не зрозуміло, що саме змінилося, але й не можна скасувати лише частину змін. Краще робити маленькі коміти: один — одне логічне змінення.

2. Ігнорувати .gitignore

У репозиторій не повинні потрапляти тимчасові файли: node_modules/, .env з секретами, зібрані бінарники, кеш. Для цього існує .gitignore — файл з іменами файлів, які Git не має відстежувати.

3. Комітити секрети

Токени, паролі, ключі API не повинні потрапляти в репозиторій. Потрапить один раз — доведеться змінювати всі секрети і чистити історію. Додай .env в .gitignore ще до першого коміту.

4. Боятися merge conflict

Merge conflict — це не катастрофа. Це просто повідомлення: “Гей, дві гілки змінили одні й ті самі рядки по-різному. Виріши, який варіант правильний.” Вирішується вручну: відкриваєш файл, бачиш, що Git позначив як конфлікт (<<<< і >>>>), залишаєш правильний варіант, і комітиш.

5. Не працювати в гілках

Працювати безпосередньо в main — як їздити без шолома. Може, нічого не станеться. А може стукнешся. Краще мати звичку робити нову гілку під кожну задачу.

Висновок / план дії

Git — це не складно, якщо не намагатися вчити все одразу. Для більшості задач достатньо п’яти команд: add, commit, push, pull, status. І коли звикнеш до них, все інше прийде природно.

Що зробити найближчим часом:

  1. Встанови Git (якщо ще не встановлений) і налаштуй ім’я та email.
  2. Ініціалізуй репозиторій в будь-якій існуючій папці з кодом: git init.
  3. Зроби перший коміт: git add . і git commit -m "initial commit".
  4. Створи окрему гілку для нової ідеї або зміни.
  5. Зареєструйся на GitHub і відправ свій код у віддалений репозиторій.

Коли ти зробиш ці п’ять кроків — ти вже на етапі, де Git стане твоїм другом, а не страшилкою.