Пошук уроків, статей та іншого контенту
Навчитеся надсилати коміти у віддалений репозиторій, працювати з помилками доступу та безпечно оновлювати спільні гілки.
git pushgit push надсилає локальні коміти у віддалений репозиторій. Команда не публікує всі зміни з робочої директорії — спочатку зміни потрібно додати до індексу та закомітити.
Типовий цикл:
git add .
git commit -m "Add login form"
git pushУ цьому прикладі:
git add . готує зміни;
git commit створює локальний коміт;
git push надсилає коміт у віддалений репозиторій.
Перевірити доступні віддалені репозиторії можна так:
git remote -vПриклад результату:
origin git@github.com:team/project.git (fetch)
origin git@github.com:team/project.git (push)origin — стандартна назва віддаленого репозиторію. Вона може бути іншою, але найчастіше використовується саме origin.
git push <remote> <branch>Наприклад:
git push origin mainКоманда надсилає локальну гілку main у віддалений репозиторій origin.
Зазвичай назва локальної та віддаленої гілки збігається, але Git дозволяє вказати їх окремо:
git push origin local-branch:remote-branchНаприклад:
git push origin feature/payment:feature/payment-reviewТут локальна гілка feature/payment буде опублікована як feature/payment-review.
Якщо гілка ще не існує у віддаленому репозиторії, виконайте:
git push -u origin feature/paymentПараметр -u або --set-upstream встановлює зв’язок між локальною та віддаленою гілками.
Після цього для наступних публікацій у цій гілці достатньо виконувати:
git pushІнформацію про поточну гілку та її upstream-гілку можна переглянути так:
git branch -vvПриклад:
* feature/payment 8a12f4c [origin/feature/payment] Add payment form
main 1c93d20 [origin/main] Release version 1.0Нижче наведено типовий сценарій для нової функціональності:
# Перевіряємо поточну гілку та стан робочої директорії
git status
# Створюємо окрему гілку для функціональності
git switch -c feature/profile
# Після редагування файлів переглядаємо зміни
git diff
# Додаємо потрібні файли до індексу
git add src/profile.js
# Створюємо локальний коміт
git commit -m "Add user profile"
# Публікуємо нову гілку та запам'ятовуємо upstream
git push -u origin feature/profile
# Перевіряємо, з якою віддаленою гілкою пов'язана поточна
git branch -vvПісля успішного push інші учасники команди зможуть отримати гілку через:
git fetch origin
git switch feature/profileЯкщо локальної гілки ще немає, git switch у сучасних версіях Git може автоматично створити її на основі віддаленої гілки. Явний варіант виглядає так:
git switch -c feature/profile --track origin/feature/profileGit надсилає не файли як окремі незалежні об’єкти, а коміти та пов’язані з ними об’єкти. Віддалена гілка переміщується на новий коміт лише після успішного оновлення.
Наприклад, якщо локальна історія має вигляд:
A---B---C origin/main
\
D---E mainПісля:
git push origin mainвіддалена гілка origin/main переміститься на коміт E:
A---B---C---D---E main, origin/mainНезакомічені зміни не надсилаються:
git statusЯкщо Git показує зміни у робочій директорії, спочатку потрібно вирішити, що з ними робити:
закомітити;
тимчасово сховати через git stash;
скасувати, якщо вони більше не потрібні.
Під час push Git може повідомити, що не вдалося автентифікувати користувача або немає дозволу на запис.
Типові повідомлення:
Permission denied
Authentication failed
Could not read from remote repository
Repository not foundСпочатку перевірте URL:
git remote get-url originЯкщо адреса неправильна, її можна змінити:
git remote set-url origin git@github.com:team/project.gitАбо для HTTPS:
git remote set-url origin https://github.com/team/project.gitПомилка Repository not found не завжди означає, що репозиторій справді не існує. Вона також може означати:
неправильний URL;
відсутність доступу до приватного репозиторію;
використання облікових даних іншого користувача;
відсутність прав на запис.
Віддалений репозиторій зазвичай використовує один із двох протоколів:
git@host.example:team/project.git
https://host.example/team/project.gitДля SSH перевірте, чи доступний сервер через ваш SSH-ключ:
ssh -T git@github.comДля HTTPS сервер може вимагати токен замість пароля. Спосіб автентифікації залежить від сервера та його налаштувань.
Не додавайте токени, паролі або приватні ключі до комітів. Якщо секрет уже потрапив до Git-історії, простого видалення файлу в новому коміті недостатньо: секрет потрібно відкликати або замінити.
У командному репозиторії може бути дозволене читання, але заборонене пряме надсилання змін. У такому разі можливі два варіанти:
отримати необхідні права;
опублікувати власну гілку або форк і створити запит на злиття відповідно до процесу команди.
Не намагайтеся обходити обмеження доступу зміною історії чи використанням чужих облікових даних.
non-fast-forwardОдна з найпоширеніших помилок під час push:
! [rejected] main -> main (non-fast-forward)
error: failed to push some refsЦе означає, що у віддаленій гілці вже є коміти, яких немає у вашій локальній гілці. Git відмовляється автоматично перезаписувати ці зміни.
Спочатку отримайте актуальну інформацію:
git fetch originПісля цього перегляньте різницю:
git log --oneline --graph --decorate --allЯкщо правила команди дозволяють перебудувати локальні коміти поверх актуальної віддаленої гілки:
git switch main
git fetch origin
git rebase origin/main
git push origin mainЯкщо під час rebase виник конфлікт:
# Після виправлення конфлікту у файлі
git add path/to/file
# Продовжуємо перебудову комітів
git rebase --continueЩоб скасувати незавершений rebase:
git rebase --abortЯкщо в команді зберігають merge-коміти або не хочуть переписувати локальну історію:
git switch main
git fetch origin
git merge origin/main
git push origin mainЯкщо виник конфлікт, виправте файли, додайте їх і завершіть злиття:
git add path/to/file
git commit
git push origin mainНе слід механічно виконувати git pull, не розуміючи, яку стратегію використовує команда. git pull поєднує отримання змін і подальше інтегрування їх у поточну гілку. Безпечніше спочатку виконати git fetch, перевірити стан гілок і лише потім обрати rebase або merge.
Спільними зазвичай є main, master, develop або інші гілки, у які працюють кілька розробників.
Перед публікацією змін у таку гілку:
перевірте поточну гілку;
отримайте останній стан віддаленого репозиторію;
переконайтеся, що локальні тести проходять;
інтегруйте віддалені зміни;
лише після цього виконуйте push.
Приклад:
git switch main
git fetch origin
git rebase origin/main
# Запускаємо тести проєкту
git push origin mainЯкщо гілка захищена, прямий push може бути заборонений навіть для користувача з правом запису. Це нормальний механізм, який змушує надсилати зміни через перевірку та схвалення.
Для спільної роботи краще публікувати окрему гілку:
git switch -c feature/search
git push -u origin feature/searchПісля перевірки цю гілку можна об’єднати зі спільною гілкою через прийнятий у команді процес.
pushЗвичайний git push захищає від випадкового видалення комітів у віддаленій гілці. Примусовий push вимикає це обмеження:
git push --force origin feature/searchЦе небезпечно для спільних гілок, оскільки може видалити коміти інших учасників.
Якщо ви навмисно переписали історію власної гілки, безпечнішим варіантом є:
git push --force-with-lease origin feature/search--force-with-lease перевіряє, чи не змінилася віддалена гілка після вашого останнього отримання даних. Якщо хтось уже опублікував нові коміти, Git відмовиться перезаписувати їх.
Навіть --force-with-lease потрібно використовувати обережно:
не застосовуйте його до спільних гілок без узгодження;
перед командою виконайте git fetch;
перевірте, які коміти будуть перезаписані;
переконайтеся, що переписування історії дозволене правилами проєкту.
Зазвичай примусовий push допустимий лише для особистої feature-гілки, коли її історію потрібно виправити після rebase або об’єднання комітів.
Після push перевірте стан локальної гілки:
git statusТипове повідомлення:
Your branch is up to date with 'origin/feature/search'.Порівняти локальну та віддалену гілки можна так:
git log --oneline main..origin/main
git log --oneline origin/main..mainПерша команда показує коміти, які є у origin/main, але відсутні в локальній main.
Друга показує коміти, які є у локальній main, але ще не опубліковані у origin/main.
Корисно також переглядати, куди саме вказує upstream:
git rev-parse --abbrev-ref --symbolic-full-name '@{u}'Якщо upstream не налаштований, Git повідомить про помилку. У такому разі виконайте першу публікацію з -u.
Перед push перевіряйте:
git branch --show-current
git statusЦе допомагає не надіслати незавершені зміни у main замість feature-гілки.
push надішле незакомічені зміниgit push працює лише з комітами. Перевірте:
git status
git log --oneline -5Якщо зміни не закомічені, вони не потраплять у віддалений репозиторій.
--force для виправлення звичайної помилки--force не є способом розв’язання non-fast-forward. Спочатку потрібно отримати нові коміти та інтегрувати їх через rebase або merge.
Перед оновленням спільної гілки виконуйте:
git fetch originІнакше можна не знати про коміти, які вже опублікував інший учасник.
Не додавайте до коміту:
паролі;
токени доступу;
приватні ключі;
файли з локальними секретними налаштуваннями.
Перевіряйте список змін перед комітом:
git diff --cachedgit push надсилає закомічені зміни у віддалений репозиторій.
Для першої публікації нової гілки використовуйте git push -u origin <branch>.
Помилки доступу потрібно діагностувати через перевірку URL, автентифікації та прав на запис.
Помилка non-fast-forward означає, що віддалена гілка містить нові коміти.
Перед оновленням спільної гілки отримуйте зміни через git fetch, а потім використовуйте погоджений у команді rebase або merge.
Не застосовуйте --force до спільних гілок.
Для особистої гілки після навмисного переписування історії безпечнішим варіантом є --force-with-lease.
Перед push завжди перевіряйте поточну гілку, список комітів і стан робочої директорії.