Якщо ти працюєш у команді (або просто не хочеш ламати власний проєкт), Git — це твоя страховка. Він дозволяє робити зміни окремо від “робочої” версії, показувати їх на перевірку і лише потім додавати в основну гілку. Процес “гілка → PR → рев’ю → мердж” — це стандарт, який тримає якість і не дає хаосу в коді.
Почнемо з базових понять. Репозиторій — це папка проєкту з історією змін. Основна гілка зазвичай називається main (інколи master або develop, але зараз частіше main). Правило просте: в main має бути стан, який можна деплоїти і який не соромно показати. Тому під кожну задачу ми створюємо окрему гілку.
Перший крок — оновити main перед стартом. Ти переходиш у main і забираєш найсвіжіші зміни з сервера. Команди однакові на Mac і Windows. Спершу перевір, в якій ти гілці:
- git status
- Перейди в main:
- git switch main
- Підтягни зміни:
- git pull
Це важливо: якщо почати роботу зі старої версії, потім з’являться конфлікти і зайва нервовість.
Другий крок — створити гілку під задачу. Гілка — це “копія” поточного стану коду, де ти можеш робити правки без ризику зламати основне. Називай гілки зрозуміло: що за задача і коротко. Наприклад: feature/publication-control, fix/storage-link, chore/update-deps. Команда створення і переходу:
git switch -c feature/publication-control
Після цього всі твої зміни будуть у цій гілці, а main лишається чистим.
Третій крок — зробити правки і підготувати коміт. Коміт — це “знімок” змін із поясненням, що ти зробив. Але коміт робиться не “все підряд”, а тоді, коли є логічно завершений шматок: додав форму, виправив баг, оновив валідацію. Перед комітом подивись, що ти змінив:
- git status
- git diff
- Далі додаєш потрібні файли:
- git add .
- або точково:
- git add path/to/file
git commit -m "Add publication control page filters"
Коментар має бути коротким і зрозумілим: що саме зроблено, без “fix” на все життя.
Четвертий крок — відправити гілку на сервер. Поки ти працюєш локально, команда не бачить твоїх змін. Тому ти “пушиш” гілку в remote:
git push -u origin feature/publication-control
Параметр -u робить так, щоб наступного разу було простіше пушити без зайвих слів.
П’ятий крок — створити PR (Pull Request). PR — це “запит на злиття”: ти кажеш команді “я зробив зміни, перевірте і якщо ок — злийте в main”. PR створюється на GitHub/GitLab/Bitbucket. Ти обираєш: з якої гілки (feature/...) у яку (main). У описі PR має бути конкретика: що зроблено, де перевірити, які ризики. Для новачка ідеальна структура опису така: “що змінив”, “як перевірити”, “на що звернути увагу”.
Перед тим як просити рев’ю, ти маєш сам пройти мінімальний чек. Запусти проєкт, переконайся, що сторінка відкривається, і якщо є тести — запусти їх. Навіть якщо тестів мало, звичка важлива. У Laravel часто достатньо:
php artisan test
або хоча б відкрити фічу в браузері і перевірити happy path: створення/редагування/видалення, фільтри, доступи.
Шостий крок — рев’ю. Рев’ю — це не “приниження”, а механізм захисту проєкту. Рев’юер дивиться: чи не зламав ти існуючі обмеження, чи немає дір у доступах, чи не з’явився N+1, чи код читається і чи є логічні межі. Твоє завдання — відповідати на коментарі і робити правки в тій самій гілці. Ти просто комітиш додаткові зміни і пушиш — PR оновиться автоматично.
Коли рев’юер пише коментар, правило просте: не сперечайся “бо мені так подобається”, а пояснюй “чому так” або виправляй. Якщо коментар про стиль — виправляй. Якщо про логіку — перевіряй, чи справді є ризик. Якщо про доступи — завжди став безпеку вище самолюбства. Так формується професійний процес.
Сьомий крок — мердж. Мердж — це злиття PR у main. В нормальних командах мердж робиться після того, як PR схвалили і пройшли перевірки (тести/лінтер). Часто доступ до мерджа має не новачок, а відповідальний розробник або тімлід. Але навіть якщо мердж робиш ти, правило одне: мерджити тільки те, що працює і не ламає існуючий функціонал.
Після мерджа ти повертаєшся в main, підтягуєш свіжий стан і можеш прибрати локальну гілку, щоб не засмічувати простір. Команди:
- git switch main
- git pull
- Видалити локальну гілку:
- git branch -d feature/publication-control
git push origin --delete feature/publication-control
Окрема реальність — конфлікти. Конфлікт виникає, коли двоє людей змінили одні й ті самі рядки. Це не трагедія, а робоча ситуація. Лікується так: підтягнути main у свою гілку, вирішити конфлікти і продовжити. Для новачка важливо не панікувати: конфлікт — це просто вибір, яка версія рядків має лишитися.
Висновок: процес “гілка → PR → рев’ю → мердж” робить розробку контрольованою. Він не дає випадково поламати main, змушує перевіряти зміни, фіксує рішення і навчає думати про наслідки. Якщо ти звикнеш до цього з першого місяця, ти будеш корисним у будь-якій команді, а твої правки перестануть бути лотереєю.
