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

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

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

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

Погнали.

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

Еще раз — здесь для mac os. Первое, что мы делаем — открываем терминал и вводим команду 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. Начнется загрузка, а потом вас попросят ввести пароль

Рис 1. Установка Homebrew

Рис 1. Установка Homebrew

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

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

Рис 2. Установка Homebrew (продолжение)

Рис 2. Установка Homebrew (продолжение)

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

Рис 3. Установка Homebrew (продолжение)

Рис 3. Установка Homebrew (продолжение)

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

Рис 4. Установка Homebrew завершена

Рис 4. Установка Homebrew завершена

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

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

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

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

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

Рис 5. Создаем репозиторий на GitHub

Рис 5. Создаем репозиторий на GitHub

Рис 6. Создаем репозиторий на GitHub

Рис 6. Создаем репозиторий на GitHub

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

Рис 7. Создаем репозиторий на GitHub

Рис 7. Создаем репозиторий на GitHub

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

Рис 8. Инструкция по коммитам от GitHub

Рис 8. Инструкция по коммитам от GitHub

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

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

Рис 9. Проверяем наличие подключенного удаленного репозитория

Рис 9. Проверяем наличие подключенного удаленного репозитория

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

git init

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

Рис 10. Инициализация

Рис 10. Инициализация

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

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

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

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

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

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

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

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

Рис 11. Переключение на мастер

Рис 11. Переключение на мастер

Осталось запушить ветку. Пушить будем с использованием 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.

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

Рис 12. Первый коммит запушен!

Рис 12. Первый коммит запушен!

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

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

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

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

Рис 13. Создаем новую ветку

Рис 13. Создаем новую ветку

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

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

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

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

Рис 14. Создаем новую ветку

Рис 14. Создаем новую ветку

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

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

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

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

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

Рис 15. Пуш новой ветки

Рис 15. Пуш новой ветки

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

Рис 16. Успешно запушеная ветка

Рис 16. Успешно запушеная ветка

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

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

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

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

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

  1. Amend

  2. Squash

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

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

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


По поводу squash:

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

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

Рис 17. Squash Commits

Рис 17. Squash Commits

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

Рис 18. Название общего коммита

Рис 18. Название общего коммита

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

Рис 19. Снова пушим!

Рис 19. Снова пушим!

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

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

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

Рис 20. Подтягиваем изменения с удаленного репозитория

Рис 20. Подтягиваем изменения с удаленного репозитория

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

Рис 21. Изменения с удаленного репозитория подтянуты

Рис 21. Изменения с удаленного репозитория подтянуты

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

© Habrahabr.ru