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 часто возникает необходимость исключить определенные файлы или директории из репозитория, чтобы они не передавались на сервер. Это может быть необходимо для конфиденциальных данных, временных файлов или других элементов, которые не должны попадать в общий доступ.

.gitignore

Самый простой способ: файл .gitignore. Это файл, создаваемый в репозитории (обычно в корне, но это не обязательно), в котором указаны файлы, которые не должны отслеживаться. Я добавлю в корень репозитория такой файл, а также тестовый файлик program.exe, и укажу его в .gitignore:

В данном случае git не будет отслеживать любые операции с этим файлом. Таким же образом можно исключать и целые директории. Обычно в такой файл попадают папки build, output и подобное — выходные данные, а также чувствительные данные, например, файлы с API-ключами.

Удаление из текущего отслеживания

Если случайно команда git add . захватила с собой нежелательные файлы, их можно убрать командой git rm --cached имя_файла

Заключение

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

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

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

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

No errors, no warnings, gentlemen and ladies!