Git для самых маленьких. От первой команды до настройки ssh

Жизнь человека начинается со слова "мама".

Дорогой читатель, твой путь начнется со слова "git".

И как первые шаги в жизни ведут нас к новым открытиям, так и первые команды git открывают двери в мир бесконечных возможностей. Каждый коммит — это шаг вперед, каждая ветка — это путь к новым горизонтам, а каждое слияние — это гармония между прошлым и будущим. Пусть твой путь в мире git будет наполнен творчеством, инновациями и бесконечным стремлением к совершенству.

Пролог

В этой статье я решил объединить полную первоначальную настройку SSH и базовые команды, которые помогут быстро начать работать с git. Постараюсь объяснять всё максимально простым языком!

Я пропускаю установку git на пк, потому что в зависимости от системы это либо протыкать много раз "далее", либо установить одной командой. Моя рекомендация в случае в Windows: при установке включить Windows Explorer Integration, т.к. это позволит быстро открывать git в любой папке.
Так выглядит пункт, который нужно отметить галочкой

Так выглядит на практике то, что мы включили выше:

Для дальнейшей работы понадобится аккаунт на GitHub, имы будем использовать почту, которая была указана при регистрации или в качестве дополнительной в аккаунте.

Настройка

Теперь начнем с момента, когда уже все установлено, чтобы настроить и начать работу.

Я буду показывать на примере git bash из Windows, т.к. большинство начинающих пользователей git используют именно эту систему, поэтому читателю будет проще следовать статье.

В папке пользователя я создал папку TestGit, перешел в нее в проводнике и из контекстного меню вызвал "Open Git Bash here", и вот я здесь:

• A: Имя пользователя.

• DESKTOP-70203MC: Имя компьютера.

• MINGW64: Окружение, в котором работает терминал (среда MinGW64).

• ~/TestGit: Текущий каталог, где ~ обозначает домашний каталог пользователя, а TestGit — папку в нём.

Далее я буду показывать команды. Для множества команд в git есть альтернативы или сокращения, я буду показывать только самое простое.

Для начала нужно задать имя пользователя и почту в конфиге git:

git config --global user.name "Имя пользователя"
git config --global user.email "Почта, к которой привязан аккаунт GitHub"

--global служит здесь для задания данных для всех репозиториев на пк, для которых не определен индивидуальный конфиг (без данного флага)

Посмотреть, что все сохранилось, можно с помощью тех же команд, только без явных параметров:

git config --global user.name
git config --global user.email

На данный момент папка, в которой мы находимся, является просто папкой. Сделаем её репозиторием с помощью команды git init

Отлично, git репозиторий создан!

Далее нужно создать первую версию репозитория (зафиксировать ее).

Я создам файл Test.txt, и с помощью команды git status посмотрим текущий статус репозитория:

• Мы находимся в ветке master (о ветках позже)

• Коммитов еще нет (о коммитах позже)

• Не отслеживаемые файлы - файлы, изменения в которых не видит git

• Ничего не добавлено в коммит, но есть не отслеживаемые файлы

Здесь git сам говорит, что нужно сделать: команда git add, но для нее нужен параметр:
Можно начать отслеживать только один файл с помощью git add имя_файла, а можно сразу все с помощью git add .. Точка здесь означает текущую папку. 

После снова посмотрим, что происходит в репозитории:

Появилась новая надпись: Изменения, которые могут быть закоммичены.

Коммит - своего рода снимок текущего состояния репозитория, создаваемый git'ом. Давайте создадим его с помощью команды git commit -m "Initial commit", в которой параметр commit выполняет одноименную операцию, а параметр "Initial commit", передаваемый как именованный параметр с помощью флага -m, - это сообщение коммита, которое будет отражено в истории. Обычно в таком сообщении указывают, что было сделано в коммите или какие изменения произошли, например: "fix gradle configuration" или "add new color scheme".

Теперь снова посмотрим состояние репозитория. Какая команда? Правильно, git status.

Нечего коммитить, а директория, в котором мы работаем, чистая. В git это значит, что в ней нет изменений.

Теперь я допишу что-нибудь в созданный ранее файл и снова посмотрю состояние репозитория:

Здесь мы видим, что файл Test.txt изменен.

Git снова подсказывает:
- git add для обновления того, что будет закоммичено.
- git restore для отмены изменений в рабочей директории.

Процесс добавления файла в индекс (то, что будет закоммичено) я уже рассмотрел выше, а выполнив вторую команду, мы получим то же состояние репозитория, что и было после создания коммита на прошлом шаге.

Я заранее создал репозиторий на GitHub, подробно здесь, три скрина достаточно ярко описывают весь процесс. На этом моменте можно уже отправлять изменения в удаленный репозиторий, но для начала нужно настроить соединение локального компьютера с аккаунтом GitHub. Я буду делать это с помощью ssh, т.к. это более гибкий и безопасный инструмент по сравнению с HTTPS-соединением, и сейчас проведем эту настройку.

SSH

SSH-соединение работает с помощью двух ключей: публичного и приватного. Приватный будет храниться на ПК, а публичный добавим на GitHub.

Создается пара ключей с помощью утилиты ssh-keygen командой ssh-keygen -t ed25519 -C "почта", дальше можно переопределить директорию для сохранения ключей и названия файлов, но я буду показывать для дефолтных настроек, для этого следует просто протыкать enter до конца.

Ключи теперь лежат в папке .ssh в директории пользователя. Нам нужно получить публичный, для этого в windows используется команда type или cat. type путь_к_файлу , или можно просто пойти в эту папку в проводнике, открыть через удобный редактор и скопировать всё содержимое. Как добавить публичный ключ на GitHub описано здесь.

Теперь для ssh нужно настроить конфиг. В папке .ssh я создал файл config без расширения и добавил в него следующее содержимое:

Host github.com
    HostName github.com
    User 666av6@gmail.com
    IdentityFile C:/Users/A/.ssh/id_ed25519

• Host я называю именем ключа, поскольку оно может быть любым, но каждая платформа по дефолту в ssh ссылках делает его идентичным HostName (Здесь я оставляю это имя дефолтным, т.к. GitHub дает ссылки именно для такого имени ключа, а для другого придется менять ссылку самостоятельно)

• HostName - имя хоста

• User - здесь указывается почта, для которой был сгенерирован ключ

• IdentityFile - это файл с путем к приватному ключу для идентификации

Теперь скопируем с GitHub ссылку на репозиторий, выбрав SSH:

Добавим удаленный репозиторий в локальный с помощью команды git remote add origin ссылка. Проверить, что все добавилось, можно с git remote -v 

origin - дефолтное название удаленного репозитория. Может быть любым, потому что у локального репозитория может быть много удаленных.

Теперь отправим локальный репозиторий на удаленный с помощью команды git push, но git не даст нам этого сделать, поскольку у ветки нет информации об отслеживании удаленной ветки, и git подскажет, как сделать эту ветку отслеживаемой. Также нам предложена команда для задания отслеживания каждой ветки по дефолту, но я не использую данную опцию, поскольку не всегда всё, что я делаю локально, нужно отправлять на удаленный репозиторий: иногда нужна ветка, чтобы потестить что-то и удалить её после.

После ввода команды git предложит использовать текущий ssh для не известного ранее хоста. Git создаст файл known_hosts в папке .ssh после ввода yes, чтобы добавить этот хост в список подлинных, а после отправит все изменения в удаленный репозиторий.

Теперь все, что мы сделали ранее, увидим на GitHub:

Когда ключ потеряет свой смысл, его можно просто удалить из GitHub, в то время, как с HTTPS-соединением придется либо менять пароль от аккаунта, либо вручную удалять credentials с устройства.

Настройка SSH-соединения происходит один раз, поэтому можно выдохнуть)

Ветки (опционально, но рекомендовано)

В Git ветки - это указатели на коммиты, позволяющие работать над разными версиями кода независимо друг от друга. Основная ветка обычно называется master (или main в новых проектах).

В консоли git текущая ветка показывается в конце первой строчки.

В локальном репозитории ветка создается с помощью команды git branch имя_ветки, а перейти на нее можно с помощью команды git checkout имя_ветки (также эти два действия можно сделать с помощью git checkout -b имя_ветки, но это уже из углубленного).

Посмотреть список доступных локально веток - git branch, в котором рядом с текущей веткой стоит символ звездочки, а список веток в удаленном репозитории - git branch -r.

Поработав с этой веткой и отправив в удаленный репозиторий, переключение на главную ветку производится также с помощью git checkout имя_ветки.

Здесь git говорит, что эта ветка синхронизирована с удаленной - это часть вывода команды git status.

Удаление локальной ветки производится с помощью команды git branch -d имя_ветки.

Здесь git не дает удалить ветку, поскольку она не была отправлена в удаленный репозиторий, и данные могут быть потеряны, поэтому нужно либо отправить её, либо воспользоваться командой git branch -D имя_ветки - force-delete. После отправки ветки в удаленный репозиторий ее можно будет удалить с помощью -d. Вторая подсказка позволяет не показывать больше данное сообщение, но это выходит за рамки статьи.

Заключение

В статье были рассмотрены начальные аспекты работы с git

• Начальные команды Git: Были описаны ключевые команды для управления репозиториями, включая создание, редактирование и управление ветками.

• Настройка SSH для Git: Дано пошаговое руководство по настройке подключения по SSH для безопасной и удобной работы с удаленными репозиториями.

Надеюсь, что эта статья действительно станет началом большого пути для тех, кто начинает осваивать Git и мир управления версиями!

No errors, no warnings, gentlemen and ladies!