Git
Last updated
Last updated
[GitHub] - (github)
[Jekyll конструктор] - (github/pages/jekyll)
Git How To -
git fetch - отримує зміни лише з поточної гілки.
git fetch --all - отримати всі зміни з усіх гілок.
git fetch --all --prune - якщо ви хочете очистити гілки, які більше не існують у віддаленому сховищі
Тобто зберегти на комп’ютері репозиторій з github :
Ця команда створить в поточній дерикторії дерикторію 'REP', де і розмістить усі файли проекту.
Назву цієї директорії на локальному компі можна змінити, налаштування репозиторія та сам локальний репозиторій не зламається - головне не втручатися в дочірню директорію .git.
За назвою директорії проекту git не стежить, важливі лише зміни самих файлів у робочій директорії.
А взагалі можна відразу клонувати в потрібну вам директорію, на кшталт
Потім переходимо в неї і працюємо з git:
Если вы клонировали репозиторий, то увидите как минимум origin -- имя по умолчанию, которое Git дает серверу, с которого производилось клонирование. Можно также указать ключ -v, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:
Теперь вместо указания полного пути мы можем использовать '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?
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 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".