Подружим Git с Intellij IDEA

По сложившейся традиции, приветствую вас, будущие Senior Software Engineers. Сегодня поговорим о логическом продолжении моей статьи про Гит. Также я советую прочесть материал о стратегиях ветвления, который я опубликовал ранее. В статье про Гит я описал, как работать с ним в командной строке, а сегодня покажу, как сделать все это в Intellij IDEA. В начале своего пути как разработчика я пользовался именно командной строкой и думал, что мне незачем использовать UI для этого дела. Ведь все понятно и так… Но это было ровно до того момента, пока я не начал использовать Гит в Intellij IDEA… Хочу сказать сразу, что я буду описывать личный опыт работы. Есть несколько вариантов решения одних и тех же задач через Intellij IDEA, и если вы знаете, как сделать лучше то, что я опишу в статье — пишите в комментарии, обсудим.

Необходимые вводные:

1. Прочесть, повторить и понять статью про гит. Это поможет быть уверенным, что все уже настроено и готово к работе
2. Установить Intellij IDEA.
3. Выделить часик личного времени для полного усвоения.

Для работы возьмем демо-проект, который я использовал для статьи про гит. UPDATE: на момент публикации уже будет доступен новый UI гитхаба, и некоторые иконки будут не там, где показано это в статье. Вы не пугайтесь: просто нужно будет либо не переходить на новый UI, либо поискать их.

Клонируем проект локально

Здесь есть два варианта.

1. Если есть уже гитхаб аккаунт и хочется что-то потом запушить, лучше сделать форк проекта к себе и клонировать свою копию. Как сделать форк — я описывал в этой статье в главе пример the forking workflow.
2. Клонировать с моего репозитория и проделать все локально без возможности все это дело запушить на сервер. Ведь это же будет мой репозиторий))

Чтобы клонировать проект с гитхаба, нужно скопировать ссылку на проект и передать ее в IntelliJ IDEA:

1. Копируем адрес проекта:

2. Открываем Intellij IDEA и выбираем Get from Version Control:

3. Копируем вставляем адрес на проект:

4. Вам предложат создать Intellij IDEA проект. Принимаем предложение:

5. Так как нет системы сборки, и это не входит в задачу статьи, выбираем Create project from existing sources:

6. Далее будет такая картина маслом: С клонированием разобрались, теперь-то можно и оглянуться по сторонам.

Первый взгляд на Intellij IDEA как на гит UI

Присмотритесь еще раз внимательно на клонированный проект: уже там можно получить много информации о системе контроля версий. Первое — это Version Control панель в нижнем левом углу. В ней можно найти все локальные изменения и получить список коммитов (аналог git log). Перейдем в лекцию Log. Присутствует некая визуальная составляющая, которая помогает понять, как именно шел процесс разработки. Например, видно, что создавалась новая ветка с коммитом added header to txt, который после влился в мастер-ветку. Если нажать на коммит, в правом углу можно увидеть всю информацию о коммите: всех изменениях и его метаданных. Более того, можно посмотреть, какие были сделаны изменения. Тем более что там же был разрезолвлен конфликт. Это IDEA тоже отлично показывает. Если нажать два раза на файл, который был изменен за этот коммит, увидим, как резолвили кофликт: Заметно, что справа и слева были два варианта одного файла, который нужно было смержить в один. А посредине — результат, который в итоге получился. Когда в проекте множество веток, коммитов и пользователей, которые работают в проекте, необходимо поискать отдельно по ветке (branch), пользователю (user) и дате (date): И последнее, что я хочу объяснить перед началом работы — это то, как же понять, в какой ветке мы находимся. Даю минуту на поиск… нашли? Сдаетесь? :D В правом нижнем углу есть кнопка Git: master, где после Git: показано, на какой ветке находится сейчас проект. Если нажать на кнопку, можно проделать множество полезных вещей: перейти на другую ветку, создать новую, переименовать существующую, и так далее.

Работа с репозиторием

Полезные горячие клавиши

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

0. ctrl + t — получить последние изменения с удаленного репозитория (git pull).
1. ctrl + k — сделать коммит/посмотреть все изменения, которые есть на данный момент. Сюда входят и untracked, и modified файлы (смотри мою статью про гит, там это описано) (git commit).
2. ctrl + shift + k — это команда для создания пуша изменений на удаленный репозиторий. Все коммиты, которые были созданы локально и еще не находятся на удаленном, будут предложены для пуша (git push).
3. alt + ctrl + z — откатить в конкретном файле изменения до состояния последнего созданного коммита в локальном репозитории. Если в левом верхнем углу выделить весь проект, то можно будет откатить изменения всех файлов.

Что мы хотим?

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

1. Получить все изменения на текущий момент в основной ветке (master, например).

2. На базе этой основной создать отдельную для своей работы.

3. Реализовать новую функциональность.

4. Перейти на основную ветку и проверить, не было ли новых изменений за время, пока работали. Если не было, то все хорошо, а если было, то делаем следующее: переходим на работающую ветку и делаем ребейз изменений из основной ветки в нашу. Если все прошло успешно, то отлично. Но вполне могут быть и конфликты. И их как раз можно будет заранее решить, не тратя время на удаленном репозитории.

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

5. Запушить свои изменения на удаленный репозиторий.

Далее уже зависит от ваших задач и фантазии.

Получить изменения с удаленного сервера?

Я добавил описание в README новым коммитом и хочу эти изменения получить. Предлагается выбор между мерджем и ребейзом в случае, если были сделаны изменения и в локальном репозитории и на удаленном. Выбираем мерж. Вводим ctrl + t: В результате, видно как изменился README, т.е. изменения из удаленного репозитория подтянулись, и в правом нижнем углу можно посмотреть все детали тех изменений, которые пришли с сервера.

Создать новую ветку на основе master

Здесь все просто.

1. Переходим в правый нижний угол и нажимаем на Git: master, выбираем + New Branch.

Оставляем галочку Checkout branch и пишем имя новой ветки. Для меня это будет readme-improver.

После этого Git: master сменится на Git: readme-improver.

Имитируем параллельную работу

Чтобы конфликты появились, их кто-то должен создать :D Я через браузер отредактирую README новым коммитом и таким образом сымитирую параллельную работу. Мол кто-то во время моей работы сделал изменения в том же файле, что и я, что приведет к конфликту. Я удалю слово “полностью” из 10 строки.

Реализовать свою функциональность

Задача стоит в том, чтобы поменять README и добавить описание к новой статье, то есть то, что работа в гите идет через Intellij IDEA. Добавляем это: Изменения выполнены, теперь можно создать коммит. Нажимаем горячую клавишу ctrl + k, получим: Прежде чем создать коммит, нужно внимательно посмотреть на то, что предлагается в этом окне. Я специально добавил стрелочек, куда посмотреть. Там много интересных вещей. В секции Commit Message пишем текст коммита, и чтобы он создался, нужно нажать кнопку Commit. Я так и не нашел, как бы так сделать это горячей клавишей, так что если кто-то найдет — пишите, я буду очень рад. Пишем, что README изменился и создаем коммит. В результате в левом нижнем углу всплывает оповещение, в котором будет имя коммита:

Проверить, не изменилась ли основная ветка

Выполнили задачу, она работает, тесты написали, все хорошо. Но прежде чем пушить на сервер, нужно таки проверить, не было ли изменений в основной ветке за это время. Как это могло произойти? Очень просто: кому-то дали задачу после вас, и этот кто-то сделал ее быстрее вас. Поэтому переходим на master ветку. Для этого нужно в правом нижнем углу сделать то, что показано ниже на рисунке: В master ветке нажимаем ctrl + t, чтобы получить ее последние изменения с удаленного сервера. Если посмотреть, какие были изменения, легко можно заметить, что произошло: Как видим, было удалено слово “полностью”. Быть может, это был кто-то из маркетинга и решил, что так нельзя писать и дал разработчикам задачу обновить это. Теперь у нас локально последняя версия master ветки. Переходим обратно на readme-improver. Теперь нужно заребейзить изменения из мастер ветки в нашу. Делаем: Если вы все правильно выполняли со мной, в результате должен показаться конфликт в README файле: Здесь также много информации, которую нужно бы понять и впитать. Здесь показан список (в нашем случае из одного элемента) файлов, в которых есть конфликты. Мы можем выбрать три опции:

1. accept yours — принять только изменения из readme-improver.
2. accept theirs — принять только изменения из master.
3. merge — самому выбрать, что нужно оставить, а что убрать.

Непонятно, что там изменилось, и если уж изменения находятся в мастере, значит они нужны там, и просто принять наши изменения нельзя, поэтому выбираем merge: Здесь видно, что есть три части:

1. Это изменения из readme-improver.
2. Результат. Пока что там так, как было до изменений.
3. Изменения из master ветки.

Нам нужно таким образом собрать результат, чтобы он всех удовлетворил. Поэтому изучили, что сделали ДО нас, поняли, что просто убрали слово “полностью”. Ну окей, без проблем. Значит и мы его уберем в результате и добавим наши изменения. Как только поправим результат, можно нажать Apply. После этого всплывет оповещение, что ребейз прошел успешно: Вот так мы зарезолвили свой первый конфликт через Intellij IDEA :D

Запушить изменения на удаленный сервер

Следующий шаг — запушить изменения на удаленный сервер и создавать пул-реквест. Для этого просто нажимаем ctrl + shift + k, после чего получим: Слева будет список коммитов, которые не запушены на удаленный репозиторий, а справа будут все файлы, которые изменены. И все: нажимаем Push, и будет вам счастье :) При успешном пуше будет вот такое уведомление в нижнем правом углу:

Бонусная часть

Не хотел изначально добавлять создание пул-реквеста в статью, но получается не очень законченной из-за этого. Поэтому переходим на гитхаб репозиторий (если он ваш, конечно))) ) и видим, что гитхаб уже знает, что нам предложить: Нажимаем на Compare & pull request, после чего нажимаем Create pull request. Из-за того, что мы заблаговременно порешали конфликты, теперь при создании пул-реквеста, его сразу можно мержить: Вот и все, что я хотел вам рассказать в этот раз. Разумеется, я только открыл вам дверь и показал малую часть. Остальное уже по мере необходимости сами найдете. Традиционно приглашаю подписаться на мой GitHub аккаунт, где я выставляю проекты-наработки на разные технологии, которые использую на работе. У меня недавно было личное достижение — мой проект был оценен уже более чем сотней разработчиков. Это невероятное чувство радости, что то, что ты сделал, кто-то использует. И использует для пользы.

Полезные ссылки

1. JavaRush: Начало работы с Git: подробный гайд для новичков
2. GitHub: Демо-проект для работы
3. JavaRush: Разбираем стратегии ветвления в Гите
4. JetBrains: Set up a Git Repository
5. Habr: Git rebase
6. GitHub: Мой аккаунт