Подружимо 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: Мій обліковий запис