Git для початківців: повний гайд з нуля до першого pull request

Майже кожен, хто вчиться програмувати, проходить через один і той самий незручний момент. Код написано, він працює, усе чудово — а потім на співбесіді чи на першому стажуванні лунає фраза: «Запуш гілку й відкрий пул-реквест». І людина зависає. Синтаксис Python вона знає, а от що робити з цим Git — незрозуміло.

Хороша новина: Git виглядає страшніше, ніж є насправді. За гучними словами на кшталт «розподілена система контролю версій» ховається доволі проста ідея, яку можна зрозуміти за один вечір. А щодня вам знадобиться не сотня команд, а приблизно сім. У цьому гайді я розберу Git так, як пояснюю його студентам на перших заняттях — без академічної води, з реальними прикладами й типовими граблями, на які наступають усі.

Навіщо розробнику знати Git

Git — це обов'язковий навик для будь-якого розробника, незалежно від мови та спеціалізації. За його допомогою команди зберігають історію коду, працюють над одним проєктом одночасно, відкочують помилки та рев'юять зміни одне одного. Без Git ви не пройдете технічну співбесіду на Junior і не зможете влитися в жодну реальну команду — там увесь код живе в Git-репозиторіях.

Наведу конкретику. Коли я співбесідую початківців, я майже ніколи не питаю про складні алгоритми. Натомість обов'язково прошу показати GitHub-профіль і розповісти, як влаштований їхній робочий процес із гілками. Причина проста: людина, яка вміє працювати з Git, вливається в команду за тиждень. Людина, яка не вміє, ще місяць ламатиме спільний репозиторій і забиратиме час у колег.

Є й друга, менш очевидна причина. Git — це ваша страховка. Він дозволяє експериментувати без страху: зіпсували код — повернулися до робочої версії однією командою. Видалили потрібний файл — відновили. Три дні писали фічу, а вона виявилася глухим кутом — відкотилися до точки, де все було добре. Для новачка це велике полегшення, бо знімає головний страх: «а раптом я все зламаю».

Що таке Git

Git — це система контролю версій: програма, яка відстежує зміни у файлах вашого проєкту й зберігає повну історію цих змін. Щоразу, коли ви зберігаєте стан проєкту (це називають «зробити commit»), Git запам'ятовує, що саме змінилося, хто і коли це зробив. У будь-який момент ви можете переглянути історію, порівняти версії або повернутися до будь-якої попередньої точки.

Уявіть, що ви пишете диплом і робите копії файлу: diplom.docx, diplom_фінал.docx, diplom_фінал_точно_останній.docx, diplom_фінал_правки_наукового.docx. Знайомо? Це ручна й дуже погана система контролю версій. Git робить те саме, тільки автоматично, охайно й без звалища файлів: уся історія зберігається в одному місці, а кожна версія підписана та доступна.

Технічно Git — це консольна програма, яку ви встановлюєте на комп'ютер. Працює вона локально: уся історія проєкту лежить у вас на диску, інтернет для базової роботи не потрібен. Слово «розподілена» у визначенні означає саме це — у кожного учасника команди є повна копія всієї історії, а не лише остання версія. Тому Git продовжує працювати в літаку, у потязі й узагалі будь-де.

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

Чому з'явився Git і хто його створив

Git написав у 2005 році Лінус Торвальдс — та сама людина, яка створила ядро Linux. І з'явився Git не від хорошого життя. До цього розробники ядра Linux користувалися пропрієтарною системою BitKeeper, але компанія-власник відкликала безкоштовну ліцензію для open-source. Тисячам розробників раптово стало нічим працювати.

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

Знати цю історію корисно не заради ерудиції. Вона пояснює, чому Git влаштований саме так: розподіленість, швидкість і акцент на цілісності даних — це не випадкові особливості, а прямі наслідки задачі, під яку його писали. Відтоді Git став стандартом де-факто: сьогодні на ньому працюють практично всі, від студентських pet-проєктів до кодової бази Google.

Git і GitHub: у чому різниця

Git — це програма для контролю версій, яка працює на вашому комп'ютері. GitHub — це онлайн-сервіс (сайт), де можна зберігати Git-репозиторії в інтернеті, показувати код іншим і працювати над проєктом командою. Git може існувати без GitHub, а от GitHub без Git — ні. Простіше кажучи: Git — це інструмент, GitHub — це майданчик, де результати роботи цим інструментом зберігаються й обговорюються.

Цю пару плутають найчастіше, тому розберемо докладніше. Аналогія, яка добре заходить студентам: Git — це як програма для роботи з документами на вашому ноутбуці, а GitHub — як хмарне сховище, куди ви ці документи вивантажуєте, щоб поділитися з колегами й вести спільну роботу. GitHub не єдиний такий сервіс — є ще GitLab, Bitbucket, Gitea та інші. Усі вони роблять приблизно одне й те саме й працюють поверх одного й того самого Git.

Критерій	Git	GitHub
Що це	Програма (система контролю версій)	Онлайн-сервіс для зберігання репозиторіїв
Де працює	Локально, на вашому комп'ютері	В інтернеті, на серверах компанії
Чи потрібен інтернет	Ні, для базової роботи не потрібен	Так
Хто створив	Лінус Торвальдс, 2005	Компанія GitHub, 2008 (нині частина Microsoft)
Головне завдання	Відстежувати зміни в коді	Зберігати код онлайн, спільна робота, review
Аналоги	Mercurial, SVN (застаріває)	GitLab, Bitbucket, Gitea
Вартість	Безкоштовний, open-source	Безкоштовний тариф + платні плани

Ще одна деталь, яку корисно зрозуміти одразу. GitHub додає до Git багато речей, яких у самому Git немає: вебінтерфейс, pull request'и, issue-трекер, code review, GitHub Actions для автоматизації, дошку проєктів. Усе це — «надбудова» над Git. Тому коли кажуть «pull request», технічно це функція GitHub, а не Git. У Git є схожа, але низькорівнева команда git request-pull, якою на практиці майже ніхто не користується.

Як працює контроль версій

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

Ключова ідея, яку треба вкласти в голову: у Git файл проходить через три «зони». Розуміння цих зон знімає 80% плутанини в новачків.

• Робоча директорія (working directory) — звичайна папка проєкту, де ви редагуєте файли. Тут живуть ваші актуальні зміни, які Git ще не зафіксував.
• Індекс, або staging area — «зона підготовки». Сюди ви кладете зміни, які хочете включити в наступний commit. Це як кошик у магазині: ви вже поклали товар, але ще не оплатили.
• Репозиторій (.git) — сховище, де Git зберігає коміти назавжди. Після git commit зміни переїжджають сюди, у постійну історію.

Шлях будь-якої зміни виглядає так: ви правите файл (working directory) → командою git add відправляєте його в staging area → командою git commit фіксуєте в репозиторії. Поділ на staging і commit здається зайвим ускладненням, але він дає важливу свободу: ви можете зробити десять правок, а закомітити лише три пов'язані між собою, залишивши решту на потім. Це дозволяє тримати історію охайною та осмисленою.

Ключові поняття Git, які треба зрозуміти першими

Далі — словник термінів, який ви чутимете постійно. Я розберу кожен на простому прикладі, а не сухим визначенням. Якщо опануєте ці вісім понять, усе інше в Git нарощуватиметься поверх них природно.

Репозиторій (repository)

Репозиторій — це папка проєкту, за якою стежить Git, разом з усією історією її змін. Технічно це ваш звичайний каталог із кодом плюс прихована підпапка .git, де зберігається вся історія, гілки й налаштування. Поки папки .git немає — це просто набір файлів; щойно ви виконали git init, папка перетворюється на репозиторій.

Репозиторії бувають локальні (у вас на комп'ютері) та віддалені (на GitHub). Зазвичай це дві пов'язані копії одного й того самого проєкту: ви працюєте в локальному, а результати відправляєте у віддалений, щоб вони були доступні команді й не загубилися.

Commit (коміт)

Commit — це збережений знімок вашого проєкту в певний момент, з описом того, що було зроблено. Кожен commit має автора, дату, текстове повідомлення та унікальний ідентифікатор (хеш на кшталт a3f9c21). Саме з комітів складається історія, і саме до будь-якого коміту можна повернутися.

Хороший commit — це не «збереження файлу», а логічно завершена одиниця роботи. Наприклад: «додав валідацію форми реєстрації» — це хороший commit. А от комітити кожні дві хвилини по одному рядку або, навпаки, звалити в один commit три непов'язані фічі — погана звичка, яка псує історію. Правило просте: один commit — одна осмислена зміна, яку можна описати однією фразою.

Гілка (branch)

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

Уявіть книжку, у якій ви дійшли до певної сторінки й раптом захотіли написати альтернативний фінал, не псуючи оригінал. Ви робите «відгалуження» від поточної сторінки й пишете там. Якщо фінал вдався — вклеюєте його в основну книжку. Якщо ні — просто викидаєте гілку, оригінал не постраждав. Основну гілку за замовчуванням нині називають main (раніше було master). Робочі гілки зазвичай називають за змістом задачі: feature/login, fix/header-bug.

Злиття (merge)

Merge — це операція об'єднання змін з однієї гілки в іншу. Коли ви завершили роботу у своїй гілці й хочете, щоб її зміни потрапили в основну, ви робите merge: Git бере коміти з вашої гілки й вплітає їх у цільову. Якщо правки не перетинаються, усе проходить автоматично.

Іноді виникає конфлікт злиття (merge conflict) — це коли двоє людей змінили один і той самий рядок файлу по-різному, і Git не може вирішити, чия версія правильна. Новачків це лякає, але нічого страшного тут немає: Git просто позначає спірне місце у файлі, а ви вручну обираєте, який варіант залишити. Конфлікти — звична частина командної роботи, а не ознака того, що ви щось зламали.

Pull Request (пул-реквест)

Pull request — це запит на додавання ваших змін до основної гілки проєкту, оформлений на GitHub. Ви кажете команді: «Ось код, який я написав у своїй гілці, подивіться і, якщо все добре, влийте його в main». Це точка, де відбувається code review — колеги читають ваш код, залишають коментарі, просять щось поправити.

Pull request (на GitLab його називають merge request) — серце командної розробки. Саме через нього код потрапляє в продукт, і саме вміння грамотно оформлювати й обговорювати pull request'и відрізняє junior'а, готового до роботи, від того, хто «лише курси пройшов». На співбесіді питання «розкажи, як ти працюєш із pull request'ами» трапляється дуже часто.

Clone (клонування)

Clone — це створення повної локальної копії віддаленого репозиторію. Команда git clone завантажує весь проєкт разом з усією історією на ваш комп'ютер, щоб ви могли з ним працювати. Саме з цього ви починаєте, коли приєднуєтеся до наявного проєкту або хочете вивчити чужий відкритий код.

Відмінність клонування від простого завантаження архіву в тому, що clone створює справжній Git-репозиторій, пов'язаний з оригіналом. Ви отримуєте не мертвий набір файлів, а живу копію, з якої можна тягнути оновлення (git pull) і в яку можна відправляти свої (git push).

Fork (форк)

Fork — це ваша особиста копія чужого репозиторію на GitHub, повністю незалежна від оригіналу. На відміну від клонування, яке створює локальну копію, fork створює копію на сервері, під вашим акаунтом. Ви можете змінювати її як завгодно, не маючи прав на оригінальний проєкт.

Fork потрібен переважно для open-source. Припустімо, ви знайшли баг у популярній бібліотеці й хочете його виправити. Прав на зміну чужого репозиторію у вас немає. Тоді ви форкаєте проєкт до себе, лагодите баг у своїй копії й відкриваєте pull request в оригінал — автори подивляться і, якщо виправлення хороше, приймуть його. Так працює вся культура відкритого коду.

Віддалений репозиторій (remote)

Remote — це версія вашого репозиторію, розміщена на сервері (наприклад, на GitHub), з якою синхронізується ваша локальна копія. За замовчуванням головний віддалений репозиторій називають origin. Коли ви робите git push, ви відправляєте коміти в remote; коли робите git pull — забираєте звідти чужі зміни.

Можна думати про remote як про точку зустрічі команди. У кожного розробника своя локальна копія, де він спокійно працює, а remote — спільне місце, куди всі стікаються, щоб синхронізуватися. Без remote Git працює, але лише для вас одного; командна робота починається саме з віддаленого репозиторію.

Як встановити Git

Встановити Git нескладно, процес залежить від операційної системи. Після встановлення перевірте, що все стало, командою git --version — якщо вона показала номер версії, Git готовий до роботи.

• Windows: завантажте інсталятор з git-scm.com і пройдіть майстер, залишаючи налаштування за замовчуванням. Разом із Git встановиться Git Bash — термінал, у якому зручно виконувати команди.
• macOS: найпростіше через Homebrew командою brew install git. Або Git підтягнеться сам під час встановлення інструментів розробника через xcode-select --install.
• Linux: через пакетний менеджер, наприклад sudo apt install git для Ubuntu/Debian або sudo dnf install git для Fedora.

Одразу після встановлення треба один раз відрекомендуватися Git — вказати ім'я та email, якими будуть підписані ваші коміти. Це робиться двома командами:

git config --global user.name "Ваше Ім'я"
git config --global user.email "[email protected]"

Email краще вказувати той самий, що й на GitHub, — тоді ваші коміти правильно прив'язуватимуться до профілю. Прапорець --global означає, що налаштування застосується до всіх ваших проєктів на цьому комп'ютері. Це разова дія: налаштували один раз — і забули.

Типовий робочий процес розробника

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

1. Забрати свіжі зміни зі спільного репозиторію: git pull. Так ви отримуєте те, що колеги зробили, поки вас не було.
2. Створити гілку під свою задачу: git switch -c feature/login. Працювати одразу в main — погана практика.
3. Писати код, час від часу фіксуючи логічні шматки: git add → git commit. Кілька маленьких осмислених комітів кращі за один величезний.
4. Відправити гілку на GitHub: git push. Тепер ваш код видно команді.
5. Відкрити pull request і попросити колег про review. Обговорити, внести правки, знову запушити.
6. Після схвалення — merge у main. Гілку видалити, задачу закрито.

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

Git-команди, які має знати кожен

Команд у Git багато, але в повсякденній роботі ви користуєтеся невеликим набором. Нижче — ті, що потрібні буквально щодня, з поясненням людською мовою. Опануєте цей список — покриєте 90% реальних задач.

Команда	Що робить	Коли використовується
git init	Перетворює папку на Git-репозиторій	На початку нового проєкту
git clone	Завантажує віддалений репозиторій на комп'ютер	Коли приєднуєтеся до готового проєкту
git status	Показує стан: що змінено, що готове до коміту	Постійно, щоб розуміти, де ви перебуваєте
git add	Додає зміни в staging area	Перед кожним комітом
git commit	Фіксує зміни в історії	Коли завершили логічний шматок роботи
git push	Відправляє коміти на віддалений репозиторій	Коли хочете поділитися кодом із командою
git pull	Забирає чужі зміни із сервера	На початку роботи та перед push
git branch	Показує список гілок / створює гілку	Коли треба побачити або створити гілку
git switch	Перемикається між гілками	Коли міняєте задачу
git merge	Об'єднує гілки	Коли вливаєте готову фічу в main
git log	Показує історію комітів	Коли треба згадати, що і коли робили

Окремо поясню про git switch і git checkout. Раніше перемикання гілок робили через git checkout, і ви досі зустрінете цей варіант у старих статтях. Але checkout перевантажений — він уміє забагато різних речей, і це плутало новачків. Тому в сучасному Git з'явилися дві окремі команди: git switch для перемикання гілок і git restore для скасування змін у файлах. Учіть одразу їх — це чистіше й зрозуміліше.

Реальні приклади: від нуля до push

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

Сценарій 1: новий проєкт з нуля

Припустімо, ви починаєте писати сайт-портфоліо й хочете одразу поставити його під контроль версій. Створюємо папку, ініціалізуємо репозиторій, робимо перший commit:

# створюємо папку і заходимо в неї
mkdir portfolio
cd portfolio

# перетворюємо папку на Git-репозиторій
git init

# створюємо файл (для прикладу)
echo "<h1>Привіт, я розробник</h1>" > index.html

# дивимося стан — Git бачить новий невідстежуваний файл
git status

# додаємо файл у staging area
git add index.html

# фіксуємо перший commit із повідомленням
git commit -m "Перший коміт: додав головну сторінку"

Розберемо, що сталося. git init створив приховану папку .git — з цього моменту Git стежить за проєктом. git status показав index.html як «untracked» — тобто Git його бачить, але поки не відстежує. git add перевів файл у staging, а git commit -m зберіг знімок з описом. Прапорець -m — це message, повідомлення коміту; без нього Git відкриє текстовий редактор і попросить його ввести.

Тепер зв'яжемо проєкт із GitHub. Спершу створіть порожній репозиторій на сайті GitHub, скопіюйте його адресу й виконайте:

# додаємо віддалений репозиторій під іменем origin
git remote add origin https://github.com/username/portfolio.git

# перейменовуємо гілку в main (якщо потрібно)
git branch -M main

# відправляємо код на GitHub уперше
git push -u origin main

Прапорець -u в останній команді пов'язує вашу локальну гілку з віддаленою один раз, щоб далі можна було писати просто git push і git pull без зазначення, куди й звідки. Після цієї команди оновіть сторінку репозиторію на GitHub — ваш код буде там.

Сценарій 2: підключення до наявного проєкту

Другий частий випадок — ви прийшли в команду або хочете попрацювати з чужим відкритим проєктом. Тут усе починається з клонування:

# завантажуємо проєкт цілком
git clone https://github.com/company/project.git
cd project

# створюємо гілку під свою задачу й одразу перемикаємося на неї
git switch -c feature/contact-form

# ... пишемо код ...

# дивимося, що змінилося
git status

# додаємо всі зміни разом
git add .

# комітимо
git commit -m "Додав форму зворотного зв'язку"

# відправляємо свою гілку на GitHub
git push -u origin feature/contact-form

Зверніть увагу на git add . — крапка означає «додати всі зміни в поточній папці». Це зручно, але небезпечно: так легко випадково закомітити зайве. Тому перед git add . завжди корисно зробити git status і подивитися, що саме потрапить у commit. Після push зайдіть на GitHub — він запропонує кнопку «Compare & pull request». Натискаєте, описуєте, що зробили, і відкриваєте pull request. Далі — review, обговорення та merge.

Коли щось пішло не так: базові рятувальні команди

Рано чи пізно ви захочете щось відкотити. Ось три команди, які знімають паніку:

# подивитися, що саме змінилося у файлах
git diff

# скасувати зміни у файлі, повернути до останнього коміту
git restore index.html

# подивитися історію комітів стисло, по одному рядку
git log --oneline

Тут важлива одна настанова, яку я завжди даю студентам: поки зміни не відправлені на GitHub, майже все можна виправити локально й ніхто не побачить. Git дуже важко «зламати по-справжньому», якщо ви вже зробили хоча б один commit. Це дає свободу експериментувати.

Як читати те, що показує Git

Окремий біль новачка — вивід команд у терміналі виглядає як незрозумілий шум. Насправді Git доволі багатослівний і майже завжди прямо підказує, що робити далі. Навчитися читати цей вивід важливіше, ніж завчати команди. Розберемо два найчастіші екрани.

Ось типовий вивід git status, коли ви змінили один файл і створили інший:

On branch main
Changes to be committed:
  (use "git restore --staged ..." to unstage)
        modified:   index.html

Untracked files:
  (use "git add ..." to include in what will be committed)
        style.css

Читається це буквально. On branch main — ви перебуваєте в гілці main. Changes to be committed — файл index.html уже в staging area й потрапить у наступний commit. Untracked files — файл style.css Git бачить, але ще не відстежує, і без git add він у commit не ввійде. Зверніть увагу: Git прямо в дужках пише, якою командою що скасувати чи додати. Він вам підказує — треба просто читати.

Другий важливий екран — історія комітів через git log --oneline:

a3f9c21 (HEAD -> main, origin/main) Додав форму зворотного зв'язку
7b2e5d8 Виправив валідацію email
1c4a9f0 Перший коміт: додав головну сторінку

Ліворуч — короткі хеші комітів, праворуч — їхні повідомлення (ось навіщо потрібні осмислені тексти). Позначка HEAD -> main означає «ви зараз перебуваєте тут, на верхівці гілки main». origin/main поруч показує, що віддалена версія на GitHub збігається з локальною — тобто все запушено. Якби origin/main опинився на коміті нижче, це означало б, що у вас є незапушені зміни. Уміння бачити ці вказівники — половина впевненості в роботі з Git.

Типові помилки новачків і як їх уникнути

За роки викладання я бачу одні й ті самі граблі знову й знову. Якщо ви заздалегідь про них знатимете, то заощадите собі багато нервів. Ось топ помилок, які роблять майже всі початківці.

Помилка	Чим погана	Як правильно
Коміти з повідомленнями «fix», «asdf», «працює»	Через місяць неможливо зрозуміти історію	Писати осмислено: «виправив валідацію email у формі»
Комітити все підряд, включно з паролями та .env	Секрети витікають у публічну історію назавжди	Використовувати .gitignore для секретів і сміття
Працювати напряму в гілці main	Легко зламати спільний робочий код	Завжди створювати окрему гілку під задачу
Один величезний commit на весь день роботи	Неможливо ні відрев'юїти, ні відкотити частково	Дробити на маленькі логічні коміти
Не робити git pull перед початком роботи	Постійні конфлікти й робота на застарілому коді	Починати день з git pull
Панікувати при merge conflict	Люди роблять різкі рухи й втрачають код	Спокійно розібрати конфлікт руками — це норма
Класти в Git важкі файли, node_modules, збірки	Репозиторій роздувається до сотень мегабайтів	Додати їх у .gitignore

Окремо про .gitignore — це простий текстовий файл у корені проєкту, де ви перелічуєте, що Git має ігнорувати. Туди зазвичай додають папки залежностей (node_modules/), файли оточення із секретами (.env), артефакти збірки (dist/, build/) і системне сміття (.DS_Store). Налаштувати .gitignore на самому початку проєкту — звичка, яка відрізняє охайного розробника.

Окремо попереджу про найболючішу помилку: закомічені та запушені секрети. Якщо пароль або API-ключ потрапив у публічну історію, недостатньо просто видалити його наступним комітом — він залишається в історії, і його вже побачили боти. Єдино правильне рішення — одразу відкликати цей ключ і випустити новий. Тому .env у .gitignore додають насамперед.

Roadmap вивчення Git з нуля

Учити Git краще шарами: спершу мінімум для соло-роботи, потім командні речі, потім просунуте. Не намагайтеся опанувати все одразу — більшість «складних» команд вам не знадобляться місяцями. Ось послідовність, яку я рекомендую студентам.

Етап	Що опанувати	Результат
1. База (1–2 дні)	init, add, commit, status, log	Ведете історію особистого проєкту
2. Робота з GitHub (2–3 дні)	clone, remote, push, pull, акаунт на GitHub	Викладаєте код онлайн, є портфоліо
3. Гілки (3–5 днів)	branch, switch, merge, розв'язання конфліктів	Працюєте як у реальній команді
4. Командний процес (1 тиждень)	Pull request, code review, fork, .gitignore	Готові до стажування й першої роботи
5. Просунуте (у міру зростання)	rebase, stash, cherry-pick, reset, revert	Упевнено розв'язуєте складні ситуації

Важливий момент про п'ятий етап: не чіпайте rebase, reset --hard і cherry-pick, поки міцно не опануєте перші чотири. Це потужні команди, але саме ними новачки найчастіше «стріляють собі в ногу». Вони потрібні, ви до них прийдете, але не першого тижня. Спершу — упевнена база.

Практична порада щодо темпу: заведіть особистий проєкт (хоч простий сайт, хоч навчальні задачі) і з першого ж дня ведіть його в Git. Навик Git ставиться не читанням, а руками. Десять реальних комітів дадуть більше розуміння, ніж десять статей, включно з цією.

Питання про Git на співбесіді Junior

На співбесідах Git питають майже завжди, і питання зазвичай базові — перевіряють, що ви реально працювали, а не лише читали. Розберемо найчастіші, щоб ви не губилися.

• У чому різниця між Git і GitHub? Git — програма контролю версій на вашому комп'ютері, GitHub — сервіс для зберігання репозиторіїв онлайн. Класичне перше питання, що відсіює тих, хто плутається в базі.
• Чим відрізняється git pull від git fetch? fetch лише завантажує зміни із сервера, але не застосовує їх до вашої гілки. pull — це fetch плюс автоматичний merge, тобто завантажує й одразу вливає.
• Що таке merge conflict і що з ним робити? Це ситуація, коли двоє змінили один рядок по-різному. Треба відкрити файл, знайти позначки конфлікту, вибрати правильну версію руками й закомітити.
• Що робить git add? Переводить зміни в staging area — зону підготовки до коміту. Багато хто плутає його зі збереженням; насправді зберігає лише commit.
• Чим merge відрізняється від rebase? Обидва об'єднують гілки, але merge створює окремий коміт злиття й зберігає гіллясту історію, а rebase «переписує» коміти поверх іншої гілки, роблячи історію лінійною.
• Як скасувати останній commit? Залежить від ситуації: git revert створює новий коміт, що скасовує зміни (безпечно для спільної історії), а git reset прибирає коміт з історії (лише для локальної, ще не запушеної роботи).
• Що таке .gitignore? Файл зі списком того, що Git має ігнорувати: залежності, секрети, артефакти збірки.

Порада щодо підготовки: не завчайте відповіді напам'ять. Краще реально попрацюйте з Git пару тижнів — тоді ви відповідатимете своїми словами й на основі досвіду, а це інтерв'юери відчувають одразу. Завчена відповідь помітна за версту, а розповідь «я на своєму проєкті ось так робив» звучить переконливо.

Практичні поради, що заощаджують час

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

• Робіть git status постійно. Це ваш компас. Перед кожним add і commit перевіряйте, у якому ви стані. З часом це стане рефлексом.
• Пишіть повідомлення комітів у наказовому способі й по суті: «додай», «виправ», «видали». Так прийнято в більшості команд, і історія читається як список дій.
• Комітьте часто, пушіть регулярно. Незапушений код існує лише у вас на диску. Зламався ноутбук — робота зникла. Push — це ще й бекап.
• Не бійтеся гілок. Гілка в Git — дешева операція. Створюйте окрему гілку під кожну задачу, навіть дрібну. Це норма, а не надмірність.
• Налаштуйте .gitignore на самому початку. Простіше не пускати сміття в репозиторій, ніж потім його звідти виколупувати.
• Опануйте один графічний клієнт, але розумійте команди. GUI на кшталт GitHub Desktop, GitKraken чи вбудованого у VS Code зручні для повсякдення. Але розуміти, що відбувається під капотом у терміналі, обов'язково — інакше в нестандартній ситуації ви застрягнете.

Часті запитання про Git

Чи складно вивчити Git новачку?

Ні. Базовий Git опановується за один-два вечори, а впевнена робота з гілками й pull request'ами — за пару тижнів практики. Git здається складним через термінологію, але щодня вам потрібні лише близько семи команд. Головне — не читати, а одразу пробувати на своєму проєкті.

Чи потрібно знати Git для першої роботи?

Так, це обов'язковий навик для будь-якого junior-розробника. Увесь код у компаніях зберігається в Git-репозиторіях, і без уміння працювати з гілками, комітами та pull request'ами влитися в команду неможливо. На співбесідах Git питають майже завжди.

Чи можна користуватися Git без GitHub?

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

Git і GitHub — це одне й те саме?

Ні. Git — це програма для контролю версій, яка працює на вашому комп'ютері. GitHub — це сайт, де Git-репозиторії зберігаються в інтернеті. Git створено 2005 року, GitHub — 2008-го. Можна використовувати Git без GitHub, але не навпаки.

Що таке commit простими словами?

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

Чим гілка відрізняється від основного коду?

Гілка — це окрема лінія розробки, де ви можете писати нову функціональність, не чіпаючи основний робочий код у гілці main. Поки ви експериментуєте у своїй гілці, main залишається стабільною. Коли робота готова, гілку зливають (merge) у main.

Що робити при merge conflict?

Не панікувати — це нормальна ситуація. Git позначає у файлі спірні місця спеціальними маркерами. Треба відкрити файл, вибрати правильну версію (свою, чужу або комбінацію), прибрати маркери конфлікту й зробити commit. Сучасні редактори на кшталт VS Code показують конфлікти наочно.

Як скасувати зміни в Git?

Залежить від того, на якому етапі зміни. Незакомічені правки у файлі скасовуються командою git restore. Останній локальний commit прибирається через git reset. Уже запушений commit безпечніше скасовувати через git revert, який створює новий зворотний коміт, не переписуючи історію.

Що таке pull request і навіщо він потрібен?

Pull request — це запит на додавання ваших змін до основної гілки проєкту на GitHub. Через нього проходить code review: колеги читають код, коментують, просять поправити. Це основний спосіб, яким код потрапляє в продукт у командній розробці.

Чим clone відрізняється від fork?

Clone створює локальну копію репозиторію на вашому комп'ютері. Fork створює копію чужого репозиторію на сервері GitHub, під вашим акаунтом. Fork потрібен для open-source: ви форкаєте чужий проєкт, вносите правки у свою копію й пропонуєте їх авторові через pull request.

Чи можна вивчити Git безкоштовно?

Так. Офіційна документація на docs.github.com, безкоштовна книжка Pro Git та інтерактивні тренажери на кшталт Learn Git Branching покривають усе необхідне безкоштовно. Але найшвидший спосіб — вести реальний навчальний проєкт у Git з першого дня й розбирати ситуації в міру їх появи.

Що робити, якщо випадково закомітив пароль?

Негайно відкличте цей пароль або ключ і випустіть новий — вважайте його скомпрометованим. Просто видалити його наступним комітом недостатньо: секрет залишається в історії. Щоб такого не траплялося, додавайте файли із секретами (наприклад, .env) у .gitignore ще до першого коміту.

Які Git-команди потрібні новачку насамперед?

Сім команд закривають майже все: git init, git add, git commit, git status, git push, git pull і git switch. Опанувавши їх, ви зможете вести проєкт, викладати його на GitHub і працювати з гілками. Решта додається в міру потреби.

Що далі

Git — це не окремий предмет, який вчать заради галочки, а робочий інструмент, яким ви користуватиметеся щодня до кінця кар'єри. Саме тому його не треба зубрити — його треба прожити на практиці. Заведіть проєкт сьогодні, зробіть перший git init і перший commit одразу після прочитання цієї статті. За тиждень щоденних комітів страх перед Git зникне, а за місяць ви працюватимете з гілками не замислюючись.

І ще одна думка наостанок. Git — це фундамент, на який стає решта професії: код-рев'ю, командна робота, CI/CD, деплой. Опанувавши його на початку шляху, ви знімаєте один із головних бар'єрів між «людиною, яка пройшла курс» і «розробником, готовим до роботи». Це вкладення, яке окупається з першого робочого дня.

Якщо ви хочете не просто розібратися з Git, а системно увійти в професію з ментором і реальними проєктами, погляньте на наші програми. На курсі Python Developer + AI та Java Developer + AI робота з Git вбудована в навчальний процес із перших тижнів — ви ведете проєкти в репозиторіях так само, як у справжніх командах. Тим, хто йде у веб, підійдуть Frontend і Full Stack, де Git і pull request'и — частина кожного практичного завдання. А якщо вас тягне до даних чи автоматизації, погляньте на Data Analytics і AI Automation — там Git теж невід'ємна частина роботи. У всіх програмах ви вчитеся не у вакуумі, а з наставником, який розбирає ваш код так, як це роблять на реальному code review.