Пошук уроків, статей та іншого контенту
Застосуєте типовий командний workflow: синхронізація, feature-гілки, Pull Request, інтеграція та видалення завершених гілок.
У типовій команді:
main — стабільна інтеграційна гілка;
кожна задача виконується в окремій feature-гілці;
зміни публікуються у віддаленому репозиторії;
Pull Request використовується для рев’ю та перевірок CI;
після схвалення гілка інтегрується в main;
завершені локальні й віддалені гілки видаляються.
Припустімо, що основний віддалений репозиторій має ім’я origin, а основна гілка — main.
Важливо розрізняти:
локальну гілку main;
віддалену гілку origin/main;
feature-гілку, наприклад feature/user-profile;
віддалену feature-гілку origin/feature/user-profile.
origin/main — це локальне посилання на стан main, який Git востаннє отримав із сервера. Воно не оновлюється автоматично після змін у віддаленому репозиторії.
Перед створенням нової feature-гілки потрібно оновити локальну інформацію про віддалений репозиторій і переконатися, що локальний
git switch main
git fetch origin
git pull --ff-only origin mainКоманда git fetch origin:
завантажує нові коміти, гілки й теги з origin;
оновлює посилання на кшталт origin/main;
не змінює поточні файли та локальні гілки.
Команда git pull --ff-only origin main складається з отримання змін і переміщення локального main уперед без створення merge-коміту.
Опція --ff-only захищає від неочікуваного merge. Якщо локальний main і віддалений main розійшлися, команда завершиться з помилкою, а ситуацію потрібно буде розглянути явно.
Перевірити стан можна так:
git status
git log --oneline --decorate --graph --all -10Якщо локальна гілка має встановлений upstream для origin/main, достатньо виконати:
git pull --ff-onlygit pullЗвичайний git pull може створити merge-коміт, якщо локальна й віддалена гілки мають різні коміти. Це не завжди помилка, але результат може бути неочікуваним і створити зайвий шум в історії.
Командна політика має явно визначати, як синхронізувати гілки:
git config --global pull.ff onlyЦе заборонить Git автоматично створювати merge-коміти під час pull.
Для feature-гілок часто використовують перебазування:
git config --global pull.rebase trueОднак глобальні налаштування не замінюють домовленостей команди. Важливо знати, чи проєкт використовує merge, squash merge або rebase під час інтеграції Pull Request.
Нову гілку потрібно створювати від актуального main:
git switch main
git pull --ff-only
git switch -c feature/user-profileНазва гілки має описувати задачу, а не спосіб її реалізації. Поширені формати:
feature/user-profile;
feature/PROJ-142-user-profile;
fix/invalid-email;
refactor/auth-service.
Після створення гілка спочатку існує лише локально. Коміти в ній не змінюють main.
Під час роботи бажано створювати логічні коміти. Один коміт має описувати завершену частину зміни, яку можна перевірити або скасувати окремо.
git status
git add src/profile.js test/profile.test.js
git commit -m "Add user profile validation"Перед комітом варто перевірити:
git diff
git diff --cachedgit diff показує ще не додані до індексу зміни;
git diff --cached показує зміни, які потраплять у наступний коміт.
Не слід без перевірки виконувати:
git add .У коміт можуть випадково потрапити:
файли з секретами;
локальні налаштування;
згенеровані файли;
тимчасові дані;
зміни, що належать іншій задачі.
Після першого коміту опублікуйте гілку:
git push -u origin feature/user-profileОпція -u встановлює upstream-гілку. Після цього в цій гілці можна використовувати скорочені команди:
git push
git pullПеревірити налаштований upstream:
git branch -vvПриклад результату:
* feature/user-profile 8f31a2c [origin/feature/user-profile] Add user profile validation
main 2c918d4 [origin/main] Merge pull requestПісля публікації можна створити Pull Request з feature/user-profile до main.
Поки розробник працює над задачею, інші учасники можуть додати коміти в main. Перед завершенням роботи feature-гілку потрібно синхронізувати з актуальним main.
Є два поширені підходи.
main у feature-гілкуgit fetch origin
git switch feature/user-profile
git merge origin/mainПереваги:
не змінюються вже опубліковані коміти feature-гілки;
безпечний підхід для гілок, над якими працює кілька людей;
не потребує примусового push.
Недолік — в історії можуть з’являтися merge-коміти.
origin/maingit fetch origin
git switch feature/user-profile
git rebase origin/mainRebase переносить коміти feature-гілки на нову вершину origin/main. Історія стає лінійнішою, але хеші комітів змінюються.
Якщо виник конфлікт:
git status
# Виправте конфліктні файли вручну
git add src/profile.js
git rebase --continueСкасувати перебазування можна командою:
git rebase --abortПісля успішного rebase гілку потрібно повторно опублікувати:
git push --force-with-lease--force-with-lease безпечніший за --force: Git відмовиться перезаписувати віддалену гілку, якщо вона змінилася непомітно для локального репозиторію.
Не виконуйте rebase опублікованої гілки, якщо інші розробники вже будують роботу на її комітах, без попередньої домовленості.
Нижче наведено послідовність команд для задачі, яку виконує один розробник.
# Перейти до основної гілки та отримати останні зміни
git switch main
git fetch origin
git pull --ff-only origin main
# Створити локальну гілку задачі
git switch -c feature/user-profile
# Перевірити та зафіксувати зміни
git status
git diff
git add src/profile.js test/profile.test.js
git commit -m "Add user profile validation"
# Опублікувати гілку та встановити upstream
git push -u origin feature/user-profile
# Пізніше отримати нові зміни з main
git fetch origin
git rebase origin/main
# Якщо конфліктів немає, опублікувати оновлену історію
git push --force-with-lease
# Переглянути стан перед створенням Pull Request
git status
git log --oneline --decorate --graph origin/main..HEADКоманда:
git log --oneline origin/main..HEADпоказує коміти, які є у поточній гілці, але ще відсутні в origin/main.
Pull Request — це не окрема команда Git, а процес перевірки змін на платформі розміщення репозиторію.
Перед створенням Pull Request потрібно перевірити:
feature-гілка опублікована;
цільова гілка правильна — зазвичай main;
у комітах немає випадкових файлів або секретів;
тести та перевірки проходять локально;
опис пояснює причину зміни та спосіб її перевірки.
У Pull Request зазвичай вказують:
що саме змінено;
чому це потрібно;
як перевірити результат;
відомі обмеження;
пов’язані задачі або дефекти.
Після створення Pull Request не потрібно створювати новий для кожного виправлення. Достатньо додати коміт у ту саму feature-гілку:
git add src/profile.js
git commit -m "Handle empty profile fields"
git pushНовий коміт автоматично з’явиться в існуючому Pull Request.
Зауваження рев’юера потрібно виправляти окремими зрозумілими комітами або, якщо це дозволено процесом команди, об’єднати коміти перед інтеграцією.
Приклад додаткового коміту:
git add src/profile.js test/profile.test.js
git commit -m "Handle empty profile fields"
git pushЯкщо потрібно привести локальну історію до охайного вигляду до інтеграції:
git rebase -i origin/main
git push --force-with-leaseПід час інтерактивного rebase можна:
об’єднати кілька комітів через squash або fixup;
змінити повідомлення коміту через reword;
змінити порядок комітів;
видалити непотрібний коміт.
Таку операцію слід виконувати лише для власної feature-гілки, коли команда допускає переписування її історії.
Після успішного рев’ю та перевірок Pull Request інтегрують у main. Поширені стратегії:
Усі коміти feature-гілки зберігаються, а до main додається окремий merge-коміт.
Переваги:
зберігається повна структура розробки;
не переписується історія feature-гілки.
Недолік — історія може містити багато розгалужень.
Усі коміти Pull Request об’єднуються в один коміт у main.
Переваги:
main має компактну історію;
проміжні коміти не потрапляють до основної гілки.
Недолік — окремі коміти feature-гілки не зберігаються в історії main.
Коміти feature-гілки додаються до main у лінійному порядку без merge-коміту.
Перевага — лінійна історія.
Недолік — коміти отримують нові хеші, тому цей підхід потребує узгодженої політики команди.
Конкретний спосіб інтеграції має визначатися правилами проєкту. Не слід самостійно змінювати стратегію для одного Pull Request, якщо це порушує загальний формат історії.
main після інтеграціїПісля злиття Pull Request серверний main змінився. Локальну копію потрібно оновити:
git switch main
git pull --ff-only origin mainАбо в два явні кроки:
git fetch origin
git switch main
git merge --ff-only origin/mainПеревага другого варіанта — чітко видно окремо отримання змін і зміну локальної гілки.
Після успішної інтеграції feature-гілку більше не потрібно зберігати як активну.
Видалити локальну гілку:
git switch main
git branch -d feature/user-profileОпція -d видаляє гілку лише тоді, коли Git вважає її зміни інтегрованими. Це захищає від випадкового видалення незлитої роботи.
Примусове видалення:
git branch -D feature/user-profile-D ігнорує перевірку інтеграції. Використовуйте його лише тоді, коли впевнені, що незлиті коміти більше не потрібні.
Видалити гілку на віддаленому репозиторії:
git push origin --delete feature/user-profileЯкщо платформа автоматично видалила віддалену гілку після злиття Pull Request, локальний список може ще містити застаріле посилання. Очистити такі посилання:
git fetch --prune originАбо ввімкнути автоматичне очищення під час кожного fetch:
git config --global fetch.prune trueПеревірити локальні гілки, що вже були інтегровані:
git branch --merged mainНе видаляйте автоматично всі гілки зі списку без перевірки: там можуть бути локальні гілки, потрібні для іншої роботи.
У деяких командах розробник має власний fork і основний командний репозиторій. Тоді віддалені репозиторії можуть називатися origin і upstream.
Переглянути їх:
git remote -vОновити основний командний репозиторій:
git fetch upstreamСтворити feature-гілку від актуального upstream/main:
git switch -c feature/user-profile upstream/mainОпублікувати її у власному fork:
git push -u origin feature/user-profilePull Request у такому процесі зазвичай створюють з origin/feature/user-profile до upstream/main. Назви origin та upstream — лише домовленість; перевіряйте фактичне налаштування через git remote -v.
mainЯкщо перед створенням гілки не виконати синхронізацію, Pull Request може містити старий стан основної гілки та зайві конфлікти.
Правильна послідовність:
git switch main
git pull --ff-only
git switch -c feature/new-taskmain і origin/mainmain — локальна гілка. origin/main — локальне віддалене посилання.
Команда:
git fetch originоновлює origin/main, але не переміщує локальний main.
git push --forceЗвичайний --force може перезаписати коміти, які інший розробник уже опублікував у тій самій гілці.
Для власної rebased-гілки використовуйте:
git push --force-with-leaseRebase змінює хеші комітів. Якщо гілкою користуються кілька людей, це може зламати їхню локальну історію.
Rebase зазвичай підходить для особистої feature-гілки до її інтеграції, але не для спільної гілки без узгодження.
Команда:
git branch -d feature/user-profileне видаляє гілку на сервері. Для цього потрібна окрема команда:
git push origin --delete feature/user-profileПеред git commit перевіряйте staged-зміни:
git diff --cachedЯкщо секрет уже потрапив до опублікованого коміту, просте видалення файлу в наступному коміті не прибирає його з історії. У такій ситуації потрібно негайно відкликати секрет і діяти за процедурою команди.
Після інтеграції не варто продовжувати додавати нові, не пов’язані зміни у вже завершену feature-гілку. Створіть нову гілку від оновленого main:
git switch main
git pull --ff-only
git switch -c feature/next-taskПеред новою задачею синхронізуйте локальний main з origin/main.
Створюйте окрему feature-гілку від актуального main.
Публікуйте її через git push -u origin <branch>.
Для оновлення feature-гілки використовуйте merge або rebase відповідно до політики команди.
Після rebase опублікованої особистої гілки використовуйте git push --force-with-lease.
Pull Request має містити перевірені зміни та зрозумілий опис.
Після інтеграції оновіть локальний main.
Видаляйте завершені локальні й віддалені гілки, а застарілі посилання очищайте через git fetch --prune.