1 year ago
by admin
Щоб зробити перебазування, а не commit
злитого вмісту, вкажіть для команди git pull
параметр --rebase
.
Параметр --rebase
можна використовувати, щоб зберегти лінійну історію та уникнути непотрібних комітів злиття. Багато розробників вважають за краще виконувати перебазування, а не злиття, як би заявляючи: «Я хочу, щоб мої зміни додалися поверх усіх інших». У цьому сенсі команда git pull
із прапором --rebase
більше схожа на команду svn update
,
ніж просту команду git pull.
Насправді команда pull
із опцією --rebase
використовується в робочому процесі настільки часто, що для неї існує виділена опція конфігурації:
git config --global branch.autosetuprebase always
Після виконання цієї команди всі команди git pull
інтегруватимуться за допомогою команди git rebase
,
а не git merge
.
Category: Git | Comments: 0
1 year ago
by admin
Команда git pull
використовується для вилучення та завантаження вмісту з віддаленого репозиторію та негайного оновлення локального репозиторію цим вмістом.
git fetch / git merge
Команда git pull
насправді є комбінацією двох інших команд: git fetch
і git merge
. На першому етапі git pull
виконується команда git fetch
, обмежена локальною гілкою, на яку вказує HEAD
. Відразу після завантаження вмісту команда git pull
виконує злиття. Для злитого вмісту створюється новий commit
, а покажчик HEAD
оновлюється і починає вказувати на цей новий commit
.
git pull <remote>
Порядок дій
Спочатку команда git pull
запускає команду git fetch
для завантаження вмісту із зазначеного віддаленого репозиторію. Потім виконується команда git merge
, що об'єднує посилання та покажчики віддаленого вмісту в новий локальний commit
злиття.
git pull
Виклик команди git pull
за умовчанням еквівалентний виконанню команд git fetch origin HEAD
і git merge HEAD
, де HEAD
– це покажчик на поточну гілку.
Поширені опції
git pull <remote>
Витягти з зазначеного віддаленого репозиторію копію поточної гілки та негайно злити її з локальною копією. Ця команда аналогічна команді git fetch <віддалений-репозиторій>
, після якої слідує команда git merge origin/<поточна-гілка>.
git pull --no-commit
Подібно до стандартного виклику, видаляє віддалений вміст, але не створює новий коміт зі злитим вмістом.
git pull --rebase
Аналогічно попередній команді pull
тільки замість команди git merge
для інтеграції віддаленої гілки з локальною гілкою використовується команда git rebase.
git pull --verbose
Під час виконання команди pull
видає докладний висновок про вміст, що завантажується, і інформацію про злиття.
Category: Git | Comments: 0
1 year ago
by admin
Відправка змін до чистого репозиторію
Перед push
треба зв'язати локальний та віддалений репозиторії. Робиться це за допомогою команди:
git remote add <repository_name> <link>
Замість repository_name
потрібно дати ім'я віддаленому репозиторію. Далі в інструкції замість цього параметра ми використовуватимемо origin
, оскільки найчастіше використовують це ім'я.
Замість link
— посилання на віддалений репозиторій, воно може виглядати по-різному, залежно від того, використовується ssh або https.
Надсилання змін
Перед push
треба зафіксувати поточні зміни, тобто зробити git commit
.
Далі для відправлення в терміналі пишемо:
git push origin <branch>
Замість branch
– ім'я гілки, яку треба відправити. Найчастіше використовується master
або main
:
git push origin master
Таке щоразу писати надто громіздко, для цього придумали git push
за замовчуванням.
Для цього один раз набираємо попередню команду з прапором -u
:
git push -u origin master
Після цього можна писати коротше, тому що git запам'ятав, що пушити треба на сервер origin
гілку під ім'ям master
:
git push
Таким чином, git дозволяє запушити гілку у віддалений репозиторій. Щоб через git додати гілку у віддалений репозиторій, треба запушити існуючу локальну гілку.
Додаткові опції публікації
Надсилання гілки на сервер у гілку з іншим ім'ям
Для того щоб зробити git push
в іншу гілку, є спеціальний синтаксис, де після імені гілки через двокрапку пишеться ім'я віддаленої гілки:
git push origin branch:server_branch
де branch
– ім'я локальної гілки,
server_branch
– ім'я віддаленої гілки на сервері.
Надсилання всіх гілок на сервер
Замість імені гілки пишемо прапор -all
:
git push origin --all
Після цього всі зафіксовані зміни у гілках вирушать у віддалений репозиторій.
Надсилання поточної гілки
Зручний спосіб відправити поточну гілку з тим самим ім'ям на сервері.
git push origin HEAD
HEAD
свідчить про поточну гілку (current branch). Тим самим не потрібно запам'ятовувати ім'я гілки, на якій ви знаходитесь.
Примусова публікація (git push - force ...)
При надсиланні може статися помилка публікації:
To github.com:example/test.git
! [rejected] master -> master (fetch first)
error: не вдалося надіслати деякі посилання до «github.com:example/test.git»
Це так званий git push rejected
, він означає, що push
був відхилений.
Найправильніше — зробити те, що написано у підказці до помилки. Потрібно отримати та смержити зміни, потім знову відправити.
Ця помилка відбувається, тому що git перевіряє,
що новий commit
заснований на попередніх комітах. Поки ви вносили зміни, хтось міг запустити зміни того, над чим ви працювали. Тому git не може виконати автоматичне злиття, ваш commit
був раніше і він не базується на оновлених коммітах у віддаленому репозиторії.
Прапором -force
або скороченою його версією -f
вимикається перевірка коммітів і за потреби виконується перезапис історії.
git push --force
Потрібно бути обережними з цією командою, оскільки вона стирає роботу інших людей. Ця команда виправдана лише зрідка, наприклад, якщо ви майже одразу внесли зміни комміту за допомогою git commit-amend
і запушили до того, як хтось зробив git pull
.
Примусова публікація з параметром (git push - force-with-lease ...)
Це безпечніший, але так само нерекомендований варіант варіант примусового пушингу. Він не перезапише роботу у віддаленій гілці, якщо до неї були додані комміти від інших людей.
git push --force-with-lease
Примусова публікація з цим параметром загрожує появою git push rejected
в інших людей
Category: Git | Comments: 0
1 year ago
by admin
Не рекомендувано використовувати "git pull"
взагалі, тому що ця команда бере на себе занадто багато функцій і її поведінка не є очевидною. Рекомендовано розібратися докладніше, як працює git, та використовувати fetch+merge
або fetch+rebase
git reset --hard
git checkout master
git reflog
# Знайти хэш комміта, в якому знаходились до першого pull-а.
# Буде щось на кшталт: "8f05e00 HEAD@{4}: checkout: moving from master to master"
# або "4c31200 HEAD@{10}: commit: Awesome feature implemented."
git reset --hard [потрібний хеш]
Перший раз git reset
потрібно, щоб очистити дерево від незакомічених змін, які могли залишитися від минулих pull-ів (merge конфлікти). Якщо таких змін немає, то команда нічого не зробить. З "брудним" деревом не вдасться зробити checkout master
, а для останньої команди ми маємо перебувати на master
Category: Git | Comments: 0
1 year ago
by admin
git pull
$ git pull origin main
**git pull** добре використовувати:
- перед початку роботи (щоб мати останні зміни),
- перед виконанням **git push** (щоб уникнути можливих конфліктів).
git push
$ git add .
$ git commit -m "added new file"
$ git push origin main
Category: Git | Comments: 0