Основы Git

Базовые команды в консоли

Навигация

— показать рабочую дерикторию;

ls

— отобразить содержимое дериктории;

ls -a

— покажет скрытые файлы м папки, название которых ничинаются с ".";

cd

— сменить дерикторию;

cd ..

— перейти на уровень выше;

cd ~

— перейтив домашнюю дерикторию;

cd /

— перейтив корневую дерикторию;

Работа с файлами и папками

Создание

— создание файла в текущей дериктории;

touch index.html style.css script.js

— созлание нескольких файлов;

mkdir

— создание дериктории;

Копирование и перемещение

— скопирует файл в другое место;

mv file.txt ~/my-dir

— переместит файл или дерикторию в другое место;

Чтение

— чтение файла(распечатай содержимое текстового файла);

Удаление

— удаление файла;

rmdir images

— удалить дерикторию;

rm -r

— "recursive" удалить дерикторию и все, что она содержит;

Полезные возможности

Команды не обязательно печатать и выполнять по очереди. Можно разделить двумя амперсандами (&&);

Начало работы c Git

Инициализируем репозиторий

Сделать дерикторию репозиторием

— инициализировать;

rm -rf .git

— "разгитить" дерикторию;

git status

— проверка состояния репозитория;

Добавление файлов в репозиторий

— подготовить файлы к сохранению;

git add —all

— подготовили к сохранению все файлы в репозитории;

git add .

— добавить всю текущую дерикторию;

Делаем коммит

— создает коммит c ключом

-m

,
который присваивает коммиту сообщение;

Просматриваем историю коммитов

— просмотр истории коммитов;

git log --pretty=format:"%h %ad %an %s" --stat

— история в формате "хеш коммита, дата, автор, описание комита, список изменённых файлов";

Создаём удалённый репозиторий (GitHub)

1. Зайдите в свой профиль по ссылке https://github.com/username,
   где username — имя, которое вы указали при регистрации.
2. Создайте репозиторий. Название удалённого репозитория необязательно должно совпадать
   с именем проекта у вас на компьютере. Но чтобы не путаться, лучше называть их одинаково.

Генерируем SSH-ключ

Проверка наличия SSH-ключа

— перешли в домашнюю директорию;

ls -la .ssh/

— список созданных ключей;

Инструкция по генерации SSH-ключа

1. Для генерации SSH-пары можно использовать программу
   ssh-keygen
   
   
   ssh-keygen -t ed25519 -C "email@yandex.ru"
   — Если вы видите сообщение об ошибке, то, скорее всего,
   ваша система не поддерживает алгоритм шифрования ed25519.
   Ничего страшного: используйте другой алгоритм;
   
   ssh-keygen -t rsa -b 4096 -C "email@yandex.ru"
   — другой алгоритм;
   
2. Программа запросит кодовую фразу (англ. passphrase) для доступа к SSH-ключу.

Привязываем SSH-ключ

1. id_rsa.pub
   или
   id_ed25519.pub
   добавляем (публичный ключ) на удаленный ресурс (GitHub)
2. ssh -T git@github.com
   — проверьте правильность ключа

Связываем локальный и удалённый репозитории

— привязывает удалённый репозиторий к локальному;

git remote add origin git@github.com:%ИМЯ_АККАУНТА%/название репозитория

— пример привязки к GitHub

git remote -v

— проверить, что репозитории связаны

Синхронизируем локальный и удалённый репозитории

— отправить изменения на удалённый репозиторий
(eсли команда приведёт к ошибке, попробуйте заменить main на master);

Хеш — идентификатор коммита

• Git преобразует информацию о коммитах с помощью алгоритма SHA-1 и для
  каждого из них рассчитывает уникальный идентификатор — хеш.
• Хеш — основной идентификатор коммита и позволяет узнать его автора,
  дату и содержимое закоммиченных файлов
• Все хеши, а также таблицу соответствий
  хеш → информация о коммите
  Git хранит в папке
  .git
  .

Исследуем лог

— получить сокращённый лог;

Статусы файлов в Git

• untracked
  — неотслеживаемый;
• staged
  — подготовленный (то есть в списоке файлов, которые войдут в коммит);
• tracked
  — отслеживаемый (файлы, которые уже были зафиксированы с помощью
  git commit
  );
• modified
  — изменённый (файл был закоммичен и после этого изменён);

Исправить коммит

— опция

—amend

работает только с последним коммитом (

HEAD

);

Дополнить коммит новыми файлами

— дополнить коммит новыми файлами;

git add common.css
# добавили файл common.css в список на коммит как обычно

# но вместо команды commit -m '...'
# будет:
$ git commit --amend --no-edit

$ git log —oneline
8340eb2 Добавить главную страницу
# коммит в истории всё ещё один (но у него новый хеш) 

Изменить сообщение коммита

— изменить сообщение коммита;

$ git commit —amend -m "Добавить главную страницу и стили"
$ git log —oneline
a31fa24 Добавить главную страницу и стили 

Откатиться назад

Выполнить unstage изменений

— переводит 'file' из

staged

обратно в

untracked

;

git restore app.js

— пример;

Откатить коммит

— откатиться до нужной версии;

git reset —hard b576d89

— пример;

При ресете передаётся один из трёх ключей:

• --soft
  — откатывает изменения до указанного комита.
  При этом изменения остаются в индексе, будто вы сделали git add, но не закоммитили их.
  
• --mixed
  (стоит по умолчанию) — аналогичен варианту выше,
  но изменения уже не будут отслеживаться. Если после ресета выполнить команду git status,
  то Git предложит добавить изменения командой
  git add
  .
  
• --hard
  — как видно из названия, это самый жёсткий вариант.
  Он полностью откатывает изменения и заменяет данные в рабочей директории.
  Все закоммиченные и незакоммиченные изменения удаляются.
  

Просмотр изменениё в файлах

— сравнивает последнюю закоммиченную версию файла с той, что находится в состоянии

modified

;

git diff —staged

— покажет изменения в

staged

-файлах относительно последних закоммиченных версий;

.gitignore

— показать записи файла .gitignore;

Клонируем репозиторий

— копирует проект на локальный компьютер;

git clone https://github.com/yandex-praktikum/git-clone-lesson

— пример;

Форк

• «Форк» позволяет получить точную копию GitHub-репозитория в ваш аккаунт.
• Копия, которая получена с помощью «форка», полностью независима от оригинального проекта — изменения не будут синхронизированы.

Основы работы с ветками в Git

— просмотреть ветки проекта. Звёздочкой (

*

) отмечено, в какой ветке вы находитесь в текущий момент ;

git branch <название_ветки>

— создает ветку;

git checkout <название_ветки>

— переключиться на другую ветку;

git checkout -b <название_ветки>

— создает ветку и сразу переключиться на неё;

git branch -a

— просматреть все доступные ветки проекта;

git diff <название_ветки1> <название_ветки2>

— cравнить ветки;

Суффикс навигации

~

Например,

— это следующий за текущим коммит. А

main~5

— это пятый коммит в ветке main,
если считать с последнего выполненного коммита.

Объединяем и удаляем ветки

— выполнить слияние;

• Перед тем как начать процесс слияния, нужно перейти в ветку, куда должны добавиться изменения. Обычно это главная ветка. Перейдите в неё и вызовите команду
  git merge
  с именем присоединяемой ветки
  feature/diff
  в качестве параметра.

Удалить ветку после объединения

— удалить ветку;

git branch -d <название_ветки>

— удалит ветку только если она была полностью объединена с другой;

git push -u origin <название_ветки>

— запушить ветку. (чтобы запушить ветку, необязательно в ней находиться).

Создать pull request

Первый способ. При создании новой ветки в удалённом репозитории Git распечатает сообщение.
Оно включает ссылку на создание пул-реквеста.

remote: Create a pull request for 'feat/diff' on GitHub by visiting:
remote:      https://github.com/%ВАШ_АККАУНТ%/git-branches/pull/new/feature/merge-request

Останется только скопировать её в адресную строку браузера, заполнить необходимые поля и нажать Create pull request (англ. «создать запрос на изменения»). Многие терминалы также позволяют кликнуть на эту ссылку — напрямую или через комбинацию Cmd / Ctrl + клик.
Второй способ. Чтобы создать пул-реквест для любой существующей ветки на GitHub, перейдите на страницу репозитория, а затем выберите вкладку Pull requests в верхней части экрана.

Забрать изменения из удалённого репозитория

— Забрать изменения из удалённого репозитория;
Дополнительно

git pull

и

git merge

выполняют перед тем, как создать пул-реквест.
При командной работе, особенно в больших командах, основная ветка часто успевает «убежать» вперёд,
пока вы подготавливаете свои изменения. Поэтому перед созданием пул-реквеста рекомендуется сначала
подтянуть изменения из основной ветки, объединить их с вашей, решить все возможные конфликты и лишь затем сделать

push

.

git checkout main # перешли в main
git pull # подтянули новые изменения в main
git checkout my-branch # вернулись в рабочую ветку my-branch
git merge main # влили main в новую ветку my-branch
git push -u origin my-branch # отправили ветку my-branch в удалённый репозиторий

Отвязать удаленный репозиторий

— эта команда удалит текущий origin;

Fast-forward

Fast-forward включен

Схематически результат слияния веток при fast-forward выглядит так.

Отключить Fast-forward

— отключить fast-forward;

git config [--global] merge.ff false

— отключить «навсегда» fast-forward;

Схематически результат слияния веток при отключенном fast-forward выглядит так.

Решение конфликтов

— форсированный пуш;

До

После

Через инструмент слияния vimdiff

При возникновении конфликта вызываем

командой

git mergetool

;
После сообщения в консоли Hit return to start merge resolution tool (vimdiff), нажимаем Enter, чтобы открыть vimdiff;

vimdiff

показывает четыре окна:

• в верхнем левом углу — текущая версия файла в
  HEAD
  ;
• в правом верхнем углу — версия из ветки
  br2
  ;
• посередине сверху — версия из ветки, которая является общим
  предком, то есть из
  main
  ;
• снизу — результат изменения с маркерами конфликта.
  vimdiff
  создаёт копию конфликтного файла с маркерами изменений и расширением
  .orig
  . Этот файл можно удалить после слияния.

Модели веток

• Feature branch workflow — простой и самый популярный вариант.
  Если коротко, в нём для каждого нового изменения создаётся новая ветка,
  которая позже вливается в
  main
  с помощью
  git merge
  .
• Git flow — более сложный вариант. Подход похож на feature branch workflow,
  но в нём создаётся больше веток, а изменения (коммиты) делят на разные типы:
  исправление, новая функциональность и так далее. Разные типы коммитов попадают в разные ветки.
• Trunk-based — подход тоже похож на feature branch workflow.
  Главное отличие в том, что участники проекта вливают (merge) свой код в основную ветку максимально часто.
  Например, каждый день.

Feature branch workflow

Дополнительно

Чтобы постоянно не печатать длинную команду, вы можете создать для неё короткое имя —

.

Для этого внесите изменения в файл

~/.gitconfig

.

[alias]
    history = log --graph --oneline --decorate

В этом файле хранятся настройки Git. Всего таких файлов три:

• /etc/gitconfig
  — содержит общие для всей системы настройки.
  
• ~/.gitconfig
  — содержит настройки для вашего пользователя.
  
• .git/config
  — находится в папке репозитория. В нём указаны настройки конкретного проекта.

Откатиться

Чтобы перейти к состоянию предыдущего коммита, выполните команду

.

HEAD

— это указатель на коммит, на котором вы находитесь. HEAD~1 возвращает хеш предыдущего коммита. То же самое вы можете сделать, скопировав нужный хеш из команды git log: git reset --soft ha1234sh. Если вы заглянете в

git log

, то увидите, что ваш последний коммит пропал из списка.
А

git status

покажет, что все файлы остались в индексе. Нужно убрать оттуда пустой файл

reset_help.md

. Для этого пригодится команда

git rm

с параметром

--cached

— удалить из индекса, но оставить в файловой системе.

git rm --cached reset_help.md 

— Лучший выбор. Git сотрёт файл и уберёт его из индекса.

Rebase

создаёт более чистую историю коммитов.
Переключитесь на новую ветку, начав её от первого коммита в репозитории.
Подставьте свой

hash

, посмотрев его в

git log

.

git checkout -b feature/rebase 91d0e04

Выполните

и посмотрите в историю коммитов

git log --graph --oneline --decorate

. Мастер-ветка вмёржилась в

feature/rebase

, создан автоматический коммит о слиянии. Теперь вернитесь в исходное состояние ветки.

git reset --soft 003bf78
git stash
git reset --hard 91d0e04 
git stash pop
git commit -m "Добавил пустой файл про запас"

В такой последовательности команд сначала откатывается первый коммит из ветки

с сохранением нового файла

empty_file.txt

. Этот файл будет помечен как новый,

но не закоммиченный. Затем

empty_file.txt

помещается во временное хранилище

stash

.

После этого изменения в ветке

feature/rebase

откатываются до изначального состояния.
Таким образом ветка

feature/rebase

не будет отличаться от мастера (коммит 91d0e04).
Далее новый файл достаётся обратно из

stash

. Такая последовательность действий позволяет

изменить название коммита и не потерять изменения в файлах.
Выполните команду

git pull --rebase origin master

и сравните историю.
В отличие от merge, который выполняет слияние веток в отдельном коммите,
rebase перемещает ваш коммит в самый верх ветки.

Rebase с изменением коммитов

Ещё одно преимущество ребейза — этой командой все коммиты схлопываются в один.
История становится более чистой, а коммиты с мелкими фиксами или исправлениями
комментариев ревьюверов отсутствуют.