Git для самых маленьких

Дисклеймер: если ты продвинутый разработчик с Х годами опыта, пожалуйста, закрой эту статью. Здесь ты не найдешь абсолютно ничего полезного для себя.

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

В этой статье я расскажу о том, как сделать первый коммит на GitHub, и как делать последующие. Только мой опыт и сочетание консоли и фич IntelliJ Idea + у меня mac os, поэтому здесь именно про него (важно для установки).

Погнали.

Блок 1: Установка git

Еще раз — здесь для mac os. Если у тебя windows, установи git по другому туториалу и приходи сюда к шагу 2 — будем коммититься! Первое, что мы делаем — открываем терминал и вводим команду:

git --version

Если вы увидели такой ответ: git version 2.47.0 (версия любая) — супер! У вас есть git, скипай блок «Установка» и переходи к блоку «Использование»

Если нет, то вы увидите что-то такое: command not found: git

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

Итак, в терминале вводим:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Жмем enter. Начнется загрузка, а потом вас попросят ввести пароль

Вводим пароль от вашего ноута (ну который при загрузке), жмем enter. Если пароля нет, просто жмем enter. 

p.s. Вы не увидите, как вводится пароль, но он вводится, поверьте 🙂 После того, как ввели пароль и нажми enter пойдут следующие сообщения:

Когда дошли до нижний строки, снова жмем enter. Побегут строчки, потом снова попросят ввести пароль — вводим.

В конце вы увидите что-то такое. Главное, что нас интересует это «Installation successful»

Теперь проверим, что brew действительно установлен, вводим: brew —version и получаем в ответе версию homebrew: Homebrew 4.4.2

Теперь можно ставить git. Для этого вводим в терминал: brew install git

Пойдет загрузка, когда она наконец-то закончится, снова вводим в терминал:

git --version

и получаем такой ответ: gir version 2.47.0

Ура, git у нас есть. Теперь двигаемся к коммитам.

Блок 2: Первый Commit на Git

Напоминаю, что я здесь делюсь своим опытом и тем подходом, который удобен мне. Если вы знаете, как пользоваться гитом, и все еще читаете эту статью (зачем-то), ваш опыт может быть другим и более удобным для вас (рада за вас!).

Сначала идем на сайт GitHub, регистрируемся а потом нажимаем на плюсик и выбираем “Create new” → “New repository”

Вводим имя репозитория и нажимаем кнопку «create repository»

Удаленный репозиторий создан. Класс, теперь GitHub — наш помощник, ведь он выдал нам прям инструкцию с командами.

Но мы пойдем не совсем по ней (так как тут предлагают добавить только файл README.md, а мы будем добавлять все файлы).

Итак, открываем наше приложение в IntelliJ Idea, переходим на вкладку Terminal, вбиваем команду git remote -v

Ничего не получаем, все верно. Потому что наш локальный репозитория не привязан ни к какому удаленному репозиторию. Теперь начинаем вводить по очереди:

git init

Ответ в терминале:

Этим шагом мы инициализировали репозиторий.

Далее добавим нужные нам файлы к будущему коммиту. Можно добавлять выборочно (с этим вы потом обязательно разберетесь!), сейчас добавим просто все файлы командой:

git add --all

Отлично, теперь вводим git commit -m «first commit»

В терминале будут выведены все файлы, которые попали в этот коммит.

Разберем команду:  git commit — ну это сама команда на коммит. 

Название коммита — это команда -m «first commit»,  m —  значит message,  а в кавычках, собственно, само название. Старайтесь делать названия коммитов понятными. На практике в качестве названия часто используются имена задач из jira, в рамках которых делается та или иная правка в проекте. 

Далее вводим: git branch -M master

Видим, что справа в углу у нас поменялась ветка с main на master.

Осталось запушить ветку. Пушить будем с использованием ssh — как сгенерировать ssh-ключ — оставляю ссылкой на ютуб-видео: https://youtu.be/cGcpVQlhbuI?si=pqBcD93ujVufTHV9

Когда ключ сгенерирован и добавлен на GitHub,  копируем из нашего репозитория на GitHub строку, которая начинается на: git remote add origin (рис 10)

У меня это git remote add origin git@github.com:мой-гит/just-test-repository.git

Используем именно ssh, потому что с https будут проблемы с логином при пуше. Если вы вдруг случайно привязали ссылку по https, то можно поменять командой: git remote set-url origin git@github.com:мой-гит/just-test-repository.git

Осталось сделать push. Вводим в консоле: git push -u origin master.

В консоли видим следующее, ура! Наш первый коммит сделан.

Обновляем страничку на GitHub и видим все наши файлы.

Блок 3: Дальнейшая разработка

Чтобы пилить новые фичи в приложении, лучше не делать все сразу в мастере, а то потом эти черри-пики (ух, та еще гадость). Поэтому создаем ветку. Можно делать через консоль, но здесь я использую функционал идеи всегда, поэтому за что купила, за то и продаю, как говориться.

Нажимаем на текущую ветку master, выбираем «new branch»

Вводим название этой ветки. У нас обычно принято так (на каждом проекте это по-разному!!!): 

• Если мы пилим новую фичу, то ветка называет feature/5778 (где цифры это номер задачи из Jira, там еще может быть название команды(типа feature/TPS-5778) — в общем, ориентируемся по названию задач в Jira)

• Если мы правим дефект, то ветка называет bugfix/TPS-9483 

Погнали назовем как-нибудь вот так.

Видите, там стоит галочка в окошке Checkout branch. Это значит, что после того, как мы создадим новую ветку, то переключимся на нее, т.е. наш master будет в безопасности.

Кстати, у меня есть telegram-канал, где я про разработку всякие штуки пишу — вот ссылочка для интересующихся 🙂 — t.me/crushiteasy

Класс, нажимаем create. Все, мы на новой ветке. Пилим фичи, добавляем классы, сервисные слои, дао и прочее, что только вашей душе угодно. 

Когда вы закончили и готовы отправлять вашу разработку далее, переходим в наш любимый терминал (который прямо в идее в проекте) и начинаем вводить команды:

git add —all git commit -m «feature/TASK-9090 - new filters» git push

Когда вы введете последнюю, то идея подскажет как правильно запушить в нужную ветку удаленно (красным на скрине):

Копируем это и снова вставляем в консоль: git push —set-upstream origin feature/TASK-9090

Идея уже подсказывает ссылку, по которой можно перейти, чтобы создать МР (он же ПР) в ветку мастер.

Переходим, создаем МР (merge request) — там все нативно.Вот мы и молодцы.

Блок 4: Изменения в ПР/МР

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

Тут есть два варианта:

1. Amend

2. Squash

Про каждый из них:

• Amend — по сути перезатирает предыдущий коммит новым.

• Squash — объединяет несколько коммитов в один.

Моя практика — в 99% случае пользуюсь amend:

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

git add —all git commit —amend —no-edit git push -f

По поводу squash:

Тут использую помощь интерфейса идеи, честно говоря:) Сделали изменения, дальше делаем отдельный коммит:

git add —all git commit -m «second commit» git push

Потом еще коммит, и еще (ну сколько вам понадобиться). В конце, перед тем, как создать МР (или перед мерджем в мастер, тут уж как пойдет разработка) переходим на вкладку Git, выделяем нужные нам коммиты, кликаем и выбираем Squash Commits:

Всплывет окошко, в котором будет названия первого и второго коммитов, удаляем их вводим новое общее название (ну или оставляем название одного из коммитов — тут, как вам кажется логичнее/понятнее) 

Нажимаем OK, идем в консоль и вводим git push -f и получаем:

Все, теперь также идем в GitHub и делаем МР.

Блок 5: Объединение веток и изменения в удаленном репозитории

После того, как наши (ну или не только наши) изменения влиты в master (кстати, в моем проекте основная ветка — это develop), переключаемся на нее в Idea и обновляем (по сути это git pull, но мне тут ближе интерфейс среды разработки): master → update

Когда все изменения с удаленного репозитория подтянутся мы увидим следующее (ну кол-во файлов и коммитов, само собой может отличаться):

Все, база по git выдана 🙂 Надеюсь, новичкам было полезно!