Жизнь человека начинается со слова "мама".
Дорогой читатель, твой путь начнется со слова "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: Окружение, в котором работает терминал (Область с настройками, системные свойствами)
~/TestGit: Текущий каталог, где ~ обозначает домашний каталог пользователя, а TestGit — папку в нём.
Далее я буду показывать команды. Для множества команд в Git есть альтернативы или сокращения, я буду показывать только самое простое.
На данный момент папка, в которой мы находимся, является просто папкой. Сделаем её репозиторием с помощью команды git init. Git-репозиторий - это хранилище, которое содержит все версии кода проекта, включая историю изменений и служебную информацию.
Отлично, Git репозиторий создан!
Теперь зададим имя пользователя и почту в конфиге Git:
git config --global user.name "Имя пользователя"
git config --global user.email "Почта, к которой привязан аккаунт GitHub"--global служит здесь для задания данных для всех репозиториев на пк, для которых не определен индивидуальный конфиг (без данного флага)
Посмотреть, что все сохранилось, можно с помощью тех же команд, только без явных параметров:
git config --global user.name
git config --global user.emailДалее нужно создать первую версию репозитория (зафиксировать ее).
Я создам файл 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 описано здесь (тип нужен authentication).
Теперь для ssh нужно настроить конфиг. В папке .ssh я создал файл config без расширения и добавил в него следующее содержимое:
Host github.com
HostName github.com
User 666av6@gmail.com
IdentityFile C:/Users/A/.ssh/id_ed25519Host я называю именем ключа, поскольку оно может быть любым, но каждая платформа по дефолту в 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 часто возникает необходимость исключить определенные файлы или директории из репозитория, чтобы они не передавались на сервер. Это может быть необходимо для конфиденциальных данных, временных файлов или других элементов, которые не должны попадать в общий доступ.
.gitignore
Самый простой способ: файл .gitignore. Это файл, создаваемый в репозитории (обычно в корне, но это не обязательно), в котором указаны файлы, которые не должны отслеживаться. Я добавлю в корень репозитория такой файл, а также тестовый файлик program.exe, и укажу его в .gitignore:
В данном случае Git не будет отслеживать любые операции с этим файлом. Таким же образом можно исключать и целые директории. Обычно в такой файл попадают папки build, output и подобное - выходные данные, а также чувствительные данные, например, файлы с API-ключами.
Удаление из текущего отслеживания
Если случайно команда git add . захватила с собой нежелательные файлы, их можно убрать командой git rm --cached имя_файла
Ветки (опционально, но рекомендовано)
В 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. Вторая подсказка позволяет не показывать больше данное сообщение, но это выходит за рамки статьи.
Подпись коммитов (опционально)
В комментариях также подметили, что подпись коммитов добавить не дольше, чем SSH, поэтому после публикации статьи я решил добавить и это.
Подпись коммитов - это специальная плашка, которая подтверждает подлинность коммита - что его сделал именно его автор, т.к. Git позволяет создавать коммиты за кого угодно: можно даже за Линуса Торвальдса создать коммит, только он не сможет быть подписанным, поскольку у нас нет его ключа)
На одном из предыдущих шагов был создан SSH-ключ, его мы и будем использовать для подписи коммитов. Для этого зададим тип подписи ssh с помощью команды git config --global gpg.format ssh, а после укажем ключ, с помощью которого будет происходить верификация. Здесь нужно указать путь к публичному ключу: git config --global user.signingkey ~/.ssh/id_ed25519.pub.
Далее есть 2 пути: включить автоматическую подпись или подписывать самостоятельно:
Автоматическая подпись коммитов с помощью команды: git config --global commit.gpgsign true
Самостоятельно подписывать каждый раз с помощью ключа -S, дописывая его при коммите: git commit -S -m "сообщение"
Проверить, подписаны ли коммиты, можно с помощью команды git log --show-signature, но они окажутся "не подписанными".
На самом деле, они подписаны, просто Git не знает, есть ли у текущего пользователя права на подпись, потому сейчас мы это добавим.
В папке .ssh я создам файл allowed_signers и в него помещу следующее содержимое:
почта ssh-ed_25519 публичный_ключА после с помощью команды git config --global gpg.ssh.allowedSignersFile ~/.ssh/allowed_signers укажу Git, где искать пользователей с правами на подпись.
После этого подписанные коммиты будут отображаться корректно:
Заключение
В статье были рассмотрены начальные аспекты работы с Git
Начальные команды Git: Были описаны ключевые команды для управления репозиториями, включая создание, редактирование и управление ветками.
Настройка SSH для Git: Дано пошаговое руководство по настройке подключения по SSH для безопасной и удобной работы с удаленными репозиториями, а также подписью коммитов.
Надеюсь, что эта статья действительно станет началом большого пути для тех, кто начинает осваивать Git и мир управления версиями!
Критику и предложения в комментариях читаю и учитываю при пересмотре статьи!
No errors, no warnings, gentlemen and ladies!
