Git

TODO!

клонувати репозиторій

git clone git@github.com:NICKNAME/REP.git

Також можна змінювати назву директорії проекту локально, налаштування репозиторію та сам локальний репозиторій не злетять - всі ці речі зберігаються в директорії .git, за назвою директорії проекту git не стежить, важливі лише зміни самих файлів у робочій директорії.

А взагалі можна відразу клонувати в потрібну вам директорію, на кшталт git clone https://site.com site_from_github

перегляд віддалених репозиторіїв

git remote
origin

Если вы клонировали репозиторий, то увидите как минимум origin – имя по умолчанию, которое Git дает серверу, с которого производилось клонирование. Можно также указать ключ -v, чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

git remote -v

origin	git@github.com:olexsyn/e-note.git (fetch)
origin	git@github.com:olexsyn/e-note.git (push)

подробнее…

добавить отдаленный репозиторий и присвоить ему имя (shortname)

git remote add SHORTNAME URL

git remote add e-note git@github.com:olexsyn/e-note.git

Теперь вместо указания полного пути мы можем использовать ‘e-note’.

получение изменений с сервера

git fetch origin

Команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Команда git pull, как правило, извлекает (fetch) данные с сервера и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

отправка изменений на сервер

Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удаленный репозиторий.

git push REMOTE-NAME BRANCH-NAME

Чтобы отправить вашу ветку main на сервер origin (клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:

git push origin main

Сокращенный вывод статуса

-s или --short

git status -s

 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

В выводе два столбца: в левом - статус, в правом - (не)модифицирован

git add file1.ext file2.ext ...

git add --all

Коммит

git commit -m 'Commit comment'

Добавить файл(ы) в последний коммит

Сначала добавляем в индекс файлы, которые необходимо присоединить к последнему коммиту, затем выполнить команду commit:

git add --all
git commit --amend --no-edit

Если необходимо также изменить и комментарий, то:

git commit -m 'New commit comment' --amend

Просмотр истории коммитов

git log
git log --stat

Побачити останні коміти по гілках

git branch -v
  atmo 2def2c2 atmo: end, to main brunch
  iss9 91bf676 iss9 process
* main ff22c5e add local icon

Опції --merged та --no-merged корисні для фільтрування списку гілок залежно від того чи вони були злиті з поточною гілкою.

git branch --merged:
  atmo
* main

Ви бачите atmo в цьому списку тому, що раніше її злили з main. Взагалі, гілки без * із цього списку можна вже видаляти (за допомогою git branch -d), адже ми вже інтегрували ті зміни, тому не втратимо їх.

Наступна команда покаже гілки, які ви не зливали з поточною гілкою:

git branch --no-merged
  iss9

Тут ви бачите свою іншу гілку. Оскільки дана гілка містить роботу, що не зливалася, спроба видалити її за допомогою git branch -d не буде успішною.

git branch -d iss9
  error: The branch 'testing' is not fully merged.
  If you are sure you want to delete it, run 'git branch -D testing'.

Якщо ж ви дійсно впевнені в тому, що гілка вам не потрібна і всі зміни з неї можна втрачати, можна змусити Git це зробити за допомогою параметра -D

i Описані вище опції --merged і --no-merged, якщо не надати команді хеш коміту чи назву гілки як аргумент, покажуть, що, відповідно, було чи не було залите до поточної гілки. Завжди можна додати ще один аргумент, щоб дізнатися про стан злиття відносно якоїсь іншої гілки — немає потреби спочатку на неї переходити. Наприклад, з поточної гілки testing дивимося, що не було залите до гілки main?

git checkout testing
git branch --no-merged master
  topicA
  featureB

TODO!

git commit -m "description" filename.ext - коммит только одного файла

Просмотр индексированных и неиндексированных изменений

git diff
git diff --staged
git diff --cached

Выбор программы для сравнения

Посмотреть, что уже установлено, и что можно можно установить:

git difftool --tool-help

Установить для git программу сравнения, например, meld

git difftool --tool=meld

Примусово оновити віддалений репозиторій:

git push -f origin master

! Але слід розуміти, що на сервері затруться всі зміни в файлах, які були зроблені після останнього git push, навіть якщо відправляється лише один файл.

Примусово оновити локальний репозиторій:

Якщо вам байдужі локальні зміни

У цьому випадку ви просто хочете скинути всі незафіксовані локальні зміни. Можливо, ви змінили файл для експерименту, але вам більше не потрібні зміни. Єдине, про що ви дбаєте, — це бути в курсі розробок.

Це означає, що ви додаєте ще один крок між отриманням віддалених змін та їх об’єднанням. Цей крок скине гілку до незміненого стану, що дозволить git mergeпрацювати.

git fetch
git reset --hard HEAD
git merge origin/$CURRENT_BRANCH

Якщо незафіксовані зміни важливі для вас

Є два варіанти. Ви можете закріпити їх, а потім виконати git pull, або ви можете приховати їх.

Сховати означає відкласти зміни на мить, щоб повернути їх пізніше. Точніше, git stash створює комміт, який не відображається у вашій поточній гілці, але все ще доступний Git.

Щоб повернути зміни, збережені в останньому сховищі, скористайтеся git stash pop командою. Після успішного застосування схованих змін ця команда також видаляє сховану фіксацію, оскільки вона більше не потрібна.

Тоді робочий процес може виглядати так:

git fetch
git stash
git merge origin/$CURRENT_BRANCH
git stash pop

За замовчуванням зміни зі сховища стануть поетапними. Якщо ви хочете скасувати їх стадію, скористайтеся командою git restore --staged (якщо використовується Git, новіша за 2.25.0).

Ви просто хочете завантажити віддалені зміни

Останній сценарій трохи відрізняється від попередніх. Скажімо, ви перебуваєте в середині дуже заплутаного рефакторинга. Ані втрачати зміни, ані зберігати їх не можна. Тим не менш, ви все одно хочете мати віддалені зміни, доступні для git diff їх виконання.

Як ви, мабуть, зрозуміли, для завантаження віддалених змін зовсім не потрібен git pull! git fetch буде достатньо.

Але є і 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/

Книга Pro Git

Pro Git book

Другие ссылки