Git
[GitHub] - (github)
[Jekyll конструктор] - (github/pages/jekyll)
Git How To - https://githowto.com/uk
git fetch
- отримує зміни лише з поточної гілки.git fetch --all
- отримати всі зміни з усіх гілок.git fetch --all --prune
- якщо ви хочете очистити гілки, які більше не існують у віддаленому сховищі
Клонувати репозиторій
Тобто зберегти на комп’ютері репозиторій з github :
Ця команда створить в поточній дерикторії дерикторію 'REP', де і розмістить усі файли проекту.
Назву цієї директорії на локальному компі можна змінити, налаштування репозиторія та сам локальний репозиторій не зламається - головне не втручатися в дочірню директорію .git
.
За назвою директорії проекту git не стежить, важливі лише зміни самих файлів у робочій директорії.
А взагалі можна відразу клонувати в потрібну вам директорію, на кшталт
Потім переходимо в неї і працюємо з git:
Перегляд віддалених репозиторіїв
Если вы клонировали репозиторий, то увидите как минимум origin
-- имя по умолчанию, которое Git дает серверу, с которого производилось клонирование. Можно также указать ключ -v
, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
добавить отдаленный репозиторий и присвоить ему имя (shortname)
Теперь вместо указания полного пути мы можем использовать 'e-note'.
получение изменений с сервера
Команда git fetch
забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.
Команда git pull
, как правило, извлекает (fetch) данные с сервера и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.
отправка изменений на сервер
Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удаленный репозиторий.
Чтобы отправить вашу ветку main на сервер origin (клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:
Сокращенный вывод статуса
-s
или --short
В выводе два столбца: в левом - статус, в правом - (не)модифицирован
??
- новые неотслеживаемые файлыA·
- файлы добавленные в отслеживаемые·M
- модифицирован и НЕ проиндексированM·
- модифицирован и проиндексированMM
- модифицирован, проиндексирован и еще раз модифицирован, т.е. на данный момент у него есть изменения которые попадут в коммит и те которые не попадут
Коммит
Додати в останній коміт файли
Сначала добавляем в индекс файлы, которые необходимо присоединить к последнему коммиту, затем выполнить команду commit
:
--amend
- при использовании этого ключа, на самом деле удаляется последний коммит и создается новый. Поэтому нельзя выполнять--amend
для коммитов, которые уже были отправлены на удаленный репозиторий (для которых был выполненgit push
).--no-edit
- позволяет оставить текущей комментарий к коммиту без изменений
Если необходимо также изменить и комментарий, то:
Просмотр истории коммитов
Побачити останні коміти по гілках
Опції --merged
та --no-merged
корисні для фільтрування списку гілок залежно від того чи вони були злиті з поточною гілкою.
Ви бачите atmo
в цьому списку тому, що раніше її злили з main
. Взагалі, гілки без * із цього списку можна вже видаляти (за допомогою git branch -d
), адже ми вже інтегрували ті зміни, тому не втратимо їх.
Наступна команда покаже гілки, які ви не зливали з поточною гілкою:
Тут ви бачите свою іншу гілку. Оскільки дана гілка містить роботу, що не зливалася, спроба видалити її за допомогою git branch -d
не буде успішною.
Якщо ж ви дійсно впевнені в тому, що гілка вам не потрібна і всі зміни з неї можна втрачати, можна змусити Git це зробити за допомогою параметра -D
i Описані вище опції --merged
і --no-merged
, якщо не надати команді хеш коміту чи назву гілки як аргумент, покажуть, що, відповідно, було чи не було залите до поточної гілки. Завжди можна додати ще один аргумент, щоб дізнатися про стан злиття відносно якоїсь іншої гілки — немає потреби спочатку на неї переходити. Наприклад, з поточної гілки testing
дивимося, що не було залите до гілки main
?
TODO!
git commit -m "description" filename.ext
- коммит только одного файла
Примусово оновити віддалений репозиторій:
! Але слід розуміти, що на сервері затруться всі зміни в файлах, які були зроблені після останнього git push
, навіть якщо відправляється лише один файл.
Примусово оновити локальний репозиторій:
Якщо вам байдужі локальні зміни
У цьому випадку ви просто хочете скинути всі незафіксовані локальні зміни. Можливо, ви змінили файл для експерименту, але вам більше не потрібні зміни. Єдине, про що ви дбаєте, — це бути в курсі розробок.
Це означає, що ви додаєте ще один крок між отриманням віддалених змін та їх об’єднанням. Цей крок скине гілку до незміненого стану, що дозволить git mergeпрацювати.
Якщо незафіксовані зміни важливі для вас
Є два варіанти. Ви можете закріпити їх, а потім виконати git pull
, або ви можете приховати їх.
Сховати означає відкласти зміни на мить, щоб повернути їх пізніше. Точніше, git stash
створює комміт, який не відображається у вашій поточній гілці, але все ще доступний Git.
Щоб повернути зміни, збережені в останньому сховищі, скористайтеся git stash pop
командою. Після успішного застосування схованих змін ця команда також видаляє сховану фіксацію, оскільки вона більше не потрібна.
Тоді робочий процес може виглядати так:
За замовчуванням зміни зі сховища стануть поетапними. Якщо ви хочете скасувати їх стадію, скористайтеся командою git restore --staged
(якщо використовується Git, новіша за 2.25.0).
Ви просто хочете завантажити віддалені зміни
Останній сценарій трохи відрізняється від попередніх. Скажімо, ви перебуваєте в середині дуже заплутаного рефакторинга. Ані втрачати зміни, ані зберігати їх не можна. Тим не менш, ви все одно хочете мати віддалені зміни, доступні для git diff
їх виконання.
Як ви, мабуть, зрозуміли, для завантаження віддалених змін зовсім не потрібен
! git pullgit fetch
буде достатньо.
git fetch
- отримує зміни лише з поточної гілки.git fetch --all
- отримати всі зміни з усіх гілок.git fetch --all --prune
- якщо ви хочете очистити гілки, які більше не існують у віддаленому сховищі
Але є і Git Pull Force
Допитливі уми, можливо, вже виявили, що існує така річ, як git pull --force
. Однак це зовсім інший звір, ніж той, який представлений у цій статті.
Це може звучати як щось, що допоможе нам перезаписати локальні зміни. Натомість це дозволяє нам отримати зміни з однієї віддаленої гілки до іншої локальної гілки. git pull --force
лише змінює поведінку частини, що отримується. Тому це еквівалентно git fetch --force
.
Як і git push
, git fetch
дозволяє нам вказати, з якою локальною та віддаленою гілкою ми хочемо працювати. git fetch origin/feature-1:my-feature
означатиме, що зміни у feature-1
гілці з віддаленого сховища будуть видимі в локальній гілці my-feature
. Коли така операція змінює існуючу історію, Git не дозволяє це робити без явного --force
параметра.
Так само, як git push --force
дозволяє перезаписувати віддалені гілки, git fetch --force
(або git pull --force
) дозволяє перезаписувати локальні гілки. Він завжди використовується з вихідними та кінцевими гілками, згаданими як параметри. Альтернативним підходом до перезапису локальних змін за допомогою git --pull force
може бути git pull --force "origin/$CURRENT_BRANCH:HEAD"
.
https://www.freecodecamp.org/news/git-pull-force-how-to-overwrite-local-changes-with-git/
Last updated