Сделать папку репозиторием — git init «Разгитить» папку, если что-то пошло не так, — rm -rf .git
**-rf:**
ключ -r (от англ. recursive — «рекурсивно») позволяет удалять папки вместе с их содержимым; ключ -f (от англ. force — «заставить») избавит вас от вопросов вроде «Вы точно хотите удалить этот файл? А этот? И этот тоже?». Проверить состояние репозитория — git status
Команда git status выведет:
• название текущей ветки: On branch master или On branch main; • сообщение о том, что в репозитории ещё нет коммитов: No commits yet; • сообщение, которое говорит: «чтобы что-нибудь закоммитить (то есть зафиксировать), нужно сначала это создать» — nothing to commit (create/copy files and use "git add" to track). Подготовить файлы к сохранению — git add git add --all # подготовили к сохранению все файлы в репозитории Выполнить коммит — git commit Сделать коммит можно командой git commit c ключом -m (от англ. message — «сообщение»), который присваивает коммиту сообщение.
Команда git commit выведет информацию о коммите. • [master (root-commit) baa3b6e] значит: o коммит был в ветке master; o root-commit — это самый первый, или «корневой» (англ. root), коммит в ветке, у следующих коммитов такой надписи не будет; o baa3b6e — сокращённый идентификатор коммита (подробнее об этом мы ещё расскажем). • 2 files changed, 1 insertion(+) значит: o изменились два файла (readme.txt и todo.txt); o одна строка была добавлена (1. Пройти пару уроков по Git.). • Строки вида create mode 100644 readme.txt — это более подробная информация о новых (добавленных в Git) файлах. o create (англ. «создать») говорит, что файл был создан. Если бы файл был удалён, на этом месте было бы слово delete (англ. «удалить»). o mode 100644 сообщает, что это обычный файл. Также возможны варианты 100755 для исполняемых файлов (например, что-нибудь.exe) и 120000 для файлов-ссылок в Linux. Файлы-ссылки не содержат данных сами по себе, а только ссылаются на другие файлы — как «ярлыки» в Windows.
Проверка наличия SSH-ключа Обычно SSH-ключи находятся в директории .ssh/. Проверить наличие этой директории и файлов в ней можно с помощью следующей команды.
$ ls -la .ssh/ # вывели список созданных ключей Если папка пустая или её нет, всё в порядке. Если есть файлы с похожими названиями, SSH-ключи уже создавались: • id_dsa.pub; • id_ecdsa.pub; • id_ed25519.pub; • id_rsa.pub. Инструкция по генерации SSH-ключа $ ssh-keygen -t ed25519 -C "электронная почта, к которой привязан ваш аккаунт на GitHub" Если вы видите сообщение об ошибке, то, скорее всего, ваша система не поддерживает алгоритм шифрования ed25519. Ничего страшного: используйте другой алгоритм. $ ssh-keygen -t rsa -b 4096 -C "электронная почта, к которой привязан ваш аккаунт на GitHub" После ввода отобразится такое сообщение.
Generating public/private rsa key pair. # сгенерированы публичный и приватный ключи Укажите место хранения ключей. Простой вариант — сделать домашний каталог пользователя путём по умолчанию. Для этого нажмите Enter. Enter a file in which to save the key (C:\Users<имя_пользователя>.ssh):[Press enter] Теперь в указанной директории появится пара ключей. Программа запросит кодовую фразу (англ. passphrase) для доступа к SSH-ключу. Вы можете оставить поле пустым. Для этого нажмите Enter, а затем ещё раз Enter для подтверждения.
Enter passphrase (empty for no passphrase): [Type a passphrase] Enter same passphrase again: [Type passphrase again] Готово! Теперь осталось проверить, что ключи действительно сгенерировались. Для этого вызовите эту команду. ls -a ~/.ssh На экране должны появиться два файла — один с расширением .pub, другой — без. Файл в .pub — публичный, им можно делиться с веб-сайтами или коллегами. Файл без расширения .pub — приватный. Ни в коем случае не передавайте его никому! Вся последовательность действий в консоли показана на скриншоте ниже.
Привязываем SSH-ключ к GitHub Инструкция по связыванию SSH-ключа и GitHub-аккаунта
- После выполнения команды ssh-keygen из предыдущего урока в директории ~/.ssh будет создано два файла — id_ed25519 и id_ed25519.pub (или id_rsa и id_rsa.pub — в зависимости от того, какой алгоритм вы использовали): o id_ed25519/id_rsa — приватный ключ (файл без .pub в конце). Ни в коем случае не копируйте его и не делитесь им. o id_ed25519.pub/id_rsa.pub — публичный ключ (на это указывает расширение .pub). Скопируйте содержимое файла с публичным ключом в буфер обмена.
$ clip < ~/.ssh/id_rsa.pub
$ clip < ~/.ssh/id_ed25519.pub Если clip не сработает, выведите содержимое файла с помощью cat ~/.ssh/id_rsa.pub или cat ~/.ssh/id_ed25519.pub и скопируйте вывод в буфер обмена из консоли.
- Перейдите на GitHub и выберите пункт Settings (англ. «настройки») в меню аккаунта.
- В меню слева нажмите на пункт SSH and GPG keys.
- В открывшейся вкладке выберите New SSH key (англ. «новый SSH-ключ»).
- В поле Title (англ. «заголовок») напишите название ключа. Например, Personal key (англ. «личный ключ»).
- В поле Key type (англ. «тип ключа») должно быть Authentication Key (англ. «ключ аутентификации»).
- В поле Key скопируйте ваш ключ из буфера обмена.
- Нажмите на кнопку Add SSH key (англ. «добавить SSH-ключ»).
- Проверьте правильность ключа с помощью следующей команды. $ ssh -T git@github.com. Если это первый раз, когда вы используете Git, чтобы поделиться проектом на GitHub, появится похожее предупреждение. The authenticity of host 'github.com (140.82.121.4)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? Это предупреждение сообщает, что вы никогда не соединялись с сервером GitHub. Поэтому Git не может гарантировать, что сервер является тем, за кого он себя выдаёт. Для подтверждения подлинности сервер генерирует и публикует ключи SHA256. Вы можете проверить ключи GitHub по этой ссылке. Если ключ в предупреждении совпадает с тем, что вы видите на сайте, значит, сервер является действительным. Введите yes, чтобы продолжить. Вы увидите приветствие на экране. i %ВАШ_АККАУНТ%! You've successfully authenticated, but GitHub does not provide shell access. Связываем локальный и удалённый репозитории Перейдите на страницу удалённого репозитория, выберите тип SSH и скопируйте URL. Кнопка справа позволит сделать это мгновенно.
Откройте консоль, перейдите в каталог локального репозитория и введите команду git remote add (от англ. remote — «удалённый» и add добавить»).
$ cd ~/dev/first-project $ git remote add origin git@github.com:%ИМЯ_АККАУНТА%/first-project.git Команде необходимо передать два параметра: имя удалённого репозитория и его URL. В качестве имени используйте слово origin. А URL вы скопировали со страницы удалённого репозитория. Убедиться, что репозитории связаны, — git remote -v Отлично: вы связали локальный репозиторий с удалённым. Осталось убедиться, что всё работает, с помощью следующей команды. Скопировать кодBASH
$ git remote -v origin git@github.com:%ИМЯ_АККАУНТА%/%ИМЯ-ПРОЕКТА%.git (fetch) origin git@github.com:%ИМЯ_АККАУНТА%/%ИМЯ-ПРОЕКТА%.git (push)
В выводе вы должны увидеть две строчки, аналогичные тем, что показаны выше. Флаг -v — короткая форма флага --verbose (англ. «подробный»). Он позволяет показать больше информации в выводе.
Синхронизируем локальный и удалённый репозитории
Отправить изменения на удалённый репозиторий — git push Вы уже прошли весь «цикл коммита»: подготовили файлы с помощью git add, закоммитили их с комментарием командой git commit -m. Осталось загрузить содержимое локального репозитория на GitHub. За это отвечает команда git push (от англ. push — «толкать»). В первый раз эту команду нужно вызвать с флагом -u и параметрами origin (имя удалённого репозитория) и main или master (название текущей ветки). Флаг -u свяжет локальную ветку с одноимённой удалённой. Как вы связывали локальный и удалённый репозитории в предыдущем уроке, так же и здесь нужно дополнительно связать ветки. $ git push -u origin main # Если команда приведёт к ошибке, попробуйте # заменить main на master. Tou
Файл HEAD (англ. «голова», «головной») — один из служебных файлов папки .git. Он указывает на коммит, который сделан последним (то есть на самый новый). В этом можно убедиться с помощью терминала. Перейдите в папку .git командой cd. Посмотрите содержимое файла HEAD командой cat. Скопировать кодBASH $ pwd # посмотрели, где мы /Users/user/dev/first-project
$ cd .git/ $ ls # посмотрели, какие есть файлы COMMIT_EDITMSG ORIG_HEAD description index logs/ refs/ HEAD config hooks/ info/ objects/
$ cat HEAD # команда cat показывает содержимое файла ref: refs/heads/master # в файле вот такая ссылка Внутри HEAD — ссылка на служебный файл: refs/heads/master (или refs/heads/main в зависимости от названия ветки). Если заглянуть в этот файл, можно увидеть хеш последнего коммита. Скопировать кодBASH $ cat refs/heads/master # взяли ссылку из файла HEAD
e007f5035f113f9abca78fe2149c593959da5eb7
$ git log
commit e007f5035f113f9abca78fe2149c593959da5eb7 Author: John Doe johndoe@example.com Date: Tue Mar 28 00:26:53 2023 +0300
Добавить амбиций в список дел
... # другие коммиты Когда вы делаете коммит, Git обновляет refs/heads/master — записывает в него хеш последнего коммита. Получается, что HEAD тоже обновляется, так как ссылается на refs/heads/master. При работе с Git указатель HEAD используется довольно часто. Мы уже упоминали, что многие команды Git принимают в качестве параметра хеш коммита. Если нужно передать последний коммит, то вместо его хеша можно просто написать слово HEAD — Git поймёт, что вы имели в виду последний коммит.
HEAD -- это голова. Коммит -- это всему голова. Статусы файлов: <тут пустая строка!>
%% описание схемы
<и тут пустая строка!>
Статусы untracked/tracked, staged и modified Одна из ключевых задач Git — отслеживать изменения файлов в репозитории. Для этого каждый файл помечается каким-либо статусом. Рассмотрим основные. • untracked (англ. «неотслеживаемый») Мы говорили, что новые файлы в Git-репозитории помечаются как untracked, то есть неотслеживаемые. Git «видит», что такой файл существует, но не следит за изменениями в нём. У untracked-файла нет предыдущих версий, зафиксированных в коммитах или через команду git add. • staged (англ. «подготовленный») После выполнения команды git add файл попадает в staging area (от англ. stage — «сцена», «этап [процесса]» и area — «область»), то есть в список файлов, которые войдут в коммит. В этот момент файл находится в состоянии staged. В одном из предыдущих уроков мы сравнили коммит с фотографией. Можно развить эту аналогию и сказать, что команда git add добавляет персонажей (текущее содержимое файла или нескольких файлов) на сцену (англ. stage) для общей фотографии, а git commit делает снимок всей сцены целиком. 💡 Staging area, index и cache Staging area также называют index (англ. «каталог») или cache (англ. «кеш»), а состояние файла staged иногда называют indexed или cached. Все три варианта могут встречаться в документации и в качестве флагов команд Git. А также в интернете — например, в вопросах и ответах на сайте Stack Overflow. • tracked (англ. «отслеживаемый») Состояние tracked — это противоположность untracked. Оно довольно широкое по смыслу: в него попадают файлы, которые уже были зафиксированы с помощью git commit, а также файлы, которые были добавлены в staging area командой git add. То есть все файлы, в которых Git так или иначе отслеживает изменения. • modified (англ. «изменённый») Состояние modified означает, что Git сравнил содержимое файла с последней сохранённой версией и нашёл отличия. Например, файл был закоммичен и после этого изменён. 💡 Для файлов в состояниях staged и modified обычно не указывают, что они также tracked, потому что это состояние подразумевается.
Как читать git status
Какие состояния показывает git status Большинство файлов в типичном проекте будут находиться в состоянии tracked (то есть закоммичены и не изменены после коммита). Вы не увидите это состояние в выводе команды git status — иначе она бы каждый раз выводила список вообще всех файлов проекта. В итоге git status показывает только следующие состояния файлов: • staged (Changes to be committed в выводе git status); • **modified **(Changes not staged for commit); • untracked (Untracked files).