Конференция по DevOps практикам — DevOps Fest, 20-21 марта. Cпикеры и доклады на сайте >>
×Закрыть

Git + GitHub: гайд для Java початківців

Всім привіт! Мене звати Софія, останні місяці я немало програмую на Java. В процесі навчання розбір Git та Github забирав досить багато часу. І щоб зекономити його вам, вирішила детально розібрати основні питання та вивільнити вам кілька вечорів для вивчення важливіших Java-штук.

На роботі для програмування я використовую досить популярне середовище розробки IntelliJ IDEA, тому сьогодні спробую провести паралель між використанням терміналу та IntelliJ IDEA при роботі з Git / Github. Детальний гайд по підключенню і правильній роботі можна знайти нижче.

Що таке Git і Github. В чому ключова відмінність?

Давайте для початку розберемо основи основ. Будь-які з існуючих технологій в програмуванні створені для того, щоб вирішувати проблеми людей/бізнесу/організацій. Git i Github також призначені для вирішення однієї з актуальних проблем, яка виникає в процесі розробки ПЗ. Мова йде про втрату історії змін, та можливість одночасної роботи над проєктом кількох розробників.

Уявімо наступну ситуацію. Туристична фірма хоче створити програмний продукт, який дозволяє клієнтам обирати тури для відпочинку. Продукт уже майже завершений і зараз готується до введення в експлуатацію. Проте від замовника надійшло прохання додати розсилку реклами на email клієнтів. Для її реалізації доводиться змінити логіку роботи програми і внести зміни в значну кількість класів.

Програмісти взялись за виконання вимог замовника, проте в процесі тестування виявилось, що обраний спосіб реалізації не задовольняє всі потреби замовника. Тому наступними кроками буде повернення проєкту до попереднього вигляду і спроба реалізації вимог замовника за допомогою використання інших технологій. Тут і виникає проблема, адже швидко повернути проєкт до попереднього вигляду не так просто, тому що змін було внесено досить багато. Вирішити дану проблему може наявність декількох версій проєкту. Найпростіший варіант — зробити копію проєкту і експериментувати над нею, проте це неможливо зробити, якщо розмір продукту занадто великий. Для вирішення цієї та інших подібних проблем була створена «система контролю версій» (VCS).

VCS дозволяє розробникам зберігати будь-які зміни, що були внесені в код, і у випадку виникнення проблеми, дає змогу повернути проєкт до попереднього стану. Це значно економить час та оптимізує процес написання коду.

Крім цього VCS дозволяє одночасно працювати над проєктом кільком розробникам. Тобто вони мають змогу відслідковувати зміни, які були внесені в програмний код в процесі спільної роботи над ним. Цим самим вирішується проблема нелінійної розробки програмного забезпечення.

Отож, що таке Git?

Це децентралізована система контролю версій, яка дає змогу розробникам відслідковувати зміни що були зроблені в проєкті під час його написання. Git дозволяє зберігати стан проєкту в будь-який момент і потім, за потреби, дає можливість повертатись до цього стану. Вся історія змін зберігається на локальному комп’ютері. Крім цього в розробників є можливість паралельної роботи над проєктом, та обміном актуальними даними, за рахунок використання гілок. Під децентралізованістю мається на увазі можливість використання однієї системи контролю версій на проєкті кількома розробниками.

Що таке GitHub?

Github це сервіс на якому зберігаються репозиторії (проєкти). Якби не існувало Github-а, то розробникам довелось би використовувати один із своїх комп’ютерів як центральний сервер. Саме через GitHub кілька розробників можуть одночасно працювати над проєктом, стягуючи собі актуальні зміни один одного.

Колись, давним-давно, одночасна робота над проєктом виглядала наступним чином. Один розробник вніс зміни в проєкт, заархівував його і відправив електронною поштою іншому розробнику. Після цього інший розробник розархівовує проєкт і звіряє його зі своїм проєктом, вносить актуальні зміни, знову архівує і відправляє наступному, і т.д. Я звичайно перебільшую, але думаю суть зрозуміла.

З приходом GitHub, кілька розробникім можуть синхронізуватись з віддаленим репозиторієм, і просто в процесі розробки заливати туди актуальні зміни. Тобто в будь-який момент часу можна зайти в репозиторій і отримати актуальну інформацію про програмний продукт над яким працює команда.

Отже, Git — це інструмент, що дозволяє реалізувати систему контролю версій, а GitHub — це сервіс для проєктів, які використовують Git.

Як правильно використовувати Git та GitHub

Створення пустого проєкту і залиття його на GitHub

Для того щоб виконати всі наступні кроки тобі знадобиться:

  • встановити IntelliJ IDEA Community (безкоштовна версія);
  • встановити Git собі на комп’ютер. Як це зробити можна знайти тут або тут
  • зареєструватись на сайті GitHub GitHub;
  • встановити Maven (не обов’язково). Як правильно це зробити для Windows або Linux/Mac.

1. Розпочнемо зі створення проєкту. В нашому випадку це буде Maven проєкт, проте можна використовувати і звичайний. Рекомендую вчитись працювати саме з Maven, адже він дає більше можливостей. Відкриваємо IntelliJ IDEA і обираємо — створити новий проєкт. Якщо IntelliJ IDEA уже відкритий обираємо File -> New -> Project.

2. Після цього відкривається вікно, де потрібно обрати Maven, та встановити SDK (в моєму випадку це 11 версія, але може бути інша). Після цього натискаємо Next.

3. Для Maven проєкту потрібно вказати GroupId (загальна назва для групи проєктів) та ArtifactId (назва кожного окремого проєкту). Третє поле змінювати не потрібно. Після цього натискаємо Next.

4. Далі з’являється вікно з автогенерованою назвою проєкту (відповідає тій, що була вказана в ArtifactId), яку за потреби можна змінити. Також можна змінити і розташування проєкту. Натискаємо Finish.

5. Після створення проєкту ми потрапляємо в його середовище, яке буде мати наступний вигляд. Зверніть увагу на повідомлення що з’явилось в правому нижньому куті (тільки для Maven), рекомендую обрати «Enable Auto-Import». Дане налаштування буде корисним при подальшому додаванні залежностей в pom.xml.

6. Структура проєкту має наступний вигляд:

7. Після цього внизу екрану потрібно відкрити вкладку Terminal.

8. Наступним етапом буде створення репозиторію на Github. Потрібно зайти на свій профіль, та перейти у вкладку «Repositories». Далі створюємо новий репозиторій натискаючи кнопку «New».

9. У формі обов’язково вказуємо назву репозиторію. Він може бути як публічний (будь-який користувач GitHub зможе переглянути репозиторій), так і приватний. Натискаємо «Create repository».

10. Після виконаних дій переходимо на наступну сторінку. На фото виділені основні команди, які потрібно буде прописати в терміналі, для того щоб зв’язати віддалений репозиторій з локальним проєктом.

11. Отже, повернемось в IntelliJ IDEA і в терміналі, який ми відкрили раніше, пропишемо перших дві команди:

1echo «# project-test» >> README.md додає до проєкту README файл, який в майбутньому можна використати для опису того, що виконує програма
2git init ініціалізує новий git репозиторій

12. Після виконання цих команд можна звернути увагу що в структурі проєкту з’явився файл README.md, і що колір всіх файлів став червоним. Це означає що тепер в проєкті ми можемо використовувати git, проте поки жоден з файлів не контролюється гітом.

Існує кілька станів файлів, які перебувають під контролем гіта, і кожен з них характеризується різними кольорами: чорний, червоний, зелений, синій. Детальніше про це за посиланням.

13. В структурі проєкту міститься досить велика кількість файлів і папок, проте деякі з них не несуть ніякої інформативності, а лише відповідають за налаштування і коректну роботу програми. Подібні файли потрібно приховувати від VCS. Для цього використовують файл «.gitignore», який створюють на найвищому рівні робочої директорії. Створимо «.gitignore» і пропишемо там усі небажані файли.

Додати файл: клік правою кнопкою миші на назву проєкта -> New -> File

14. Назва файлу: «.gitignore»

15. IntelliJ IDEA пропонує додати цей файл під контроль гіта, потрібно обрати «Add».

16. Після цього в структурі проєкту файл «.gitignore» виділиться зеленим кольором.

До цього ж файлу додамо наступне:

.idea/*
*.iml
target/* (для Maven)

17. Далі приступимо до виконання решти команд з пункту 10.

3 git add .додає всі файли в поточній папці під контроль гіта (git add README.md — додасть тільки вказаний файл)
4git commit -m «initial commit»зберігає поточний стан проєкту, до якого можна буде повернутись в будь-який момент часу. В лапках пишемо повідомлення про те що було зроблено в проєкті. Повідомлення повинні бути зрозумілими та інформативними
5git remote add origin urlвідповідає за додавання нового віддаленого репозиторію.
origin — адреса репозиторію на github.

url буде іншою для кожного нового репозиторія (приклад — github.com/User/project-test.git)

6git push -u origin masterзаливає всі локальні зміни на віддалений репозиторій

18. Після виконання всіх команд, на GitHub буде відображатись початкова версія вашого проєкту.

Що таке Pull Request?

Як загалом відбувається спільна робота кількох розробників над проєктом?

Якщо говорити саме про етап написання коду, то весь проєкт ділиться на окремі, невеликі завдання, і тільки тоді, кожен з розробників приступає за виконання своєї частини. Як вже було сказано вище, розробники можуть паралельно працювати над одним проєктом. Крім цього в репозиторії є головна гілка master — яка містить в собі актуальну версію проєкту. Перш ніж залити свій код в головну гілку необхідно створити «pull request» і дати його на перевірку своєму ментору / тім ліду / колезі. Тільки після їхньої перевірки і виправлення всіх зауважень, код можна зливати з master.

Для забезпечення правильної паралельної розробки досить часто використовують популярну модель git-flow, яка описує послідовність роботи з гілками та їх основні види в проєкті. Детальніше з цією моделлю можна ознайомитись за посиланням.

Спробуємо створити свій перший pull request.

1. Зараз ми перебуваємо в гілці master, тому перш за все потрібно переключитися на нову гілку. Заливати новий код одразу в master — погана практика, адже твій варіант коду може бути неробочим, тому для Junior developer необхідно вміти користуватися «pull requests» для того, щоб перед залиттям коду в master, можна було перевірити його правильність.

Отоже, створимо нову гілку. Це можна зробити знову ж таки через термінал виконавши команду git checkout -b [name_of_your_new_branch] origin/master Або ж через інтерфейс IntelliJ IDEA (правий нижній кут -> master -> New Branch -> вказуємо назву нової гілки).

2. Тепер можемо приступити до написання коду. Створимо новий клас в папці src -> main -> java. Назвемо його App. Під час створення знову з’явиться повідомлення про те чи хочемо ми додати цей клас під контроль гіта. Натискаємо — так (пункт 15). Для початку створимо кілька тестових методів в класі.

3. Після написання потрібного коду повертаємось в термінал. Перш за все нам потрібно додати всі файли в який були внесені зміни командою git add . а потім прописати, уже знайому, команду git commit -m «added methods sum() and div()», для того щоб зберегти поточний стан програми.

Замість терміналу можемо використати інтерфейс IntelliJ IDEA. На верхній панелі можна знайти кнопку «commit» (зелена галочка) і натиснути на неї. З’явиться вікно, де потрібно написати змістовне повідомлення і натиснути «Commit».

4. Після того як коміт був зроблений потрібно залити локальні зміни у віддалений репозиторій на GitHub. Знову ж таки можна використати термінал і прописати команду git push origin [name_of_your_new_branch]

Або теж саме можна зробити через інтерфейс. На верхній панелі вкладка VCS -> Git -> Push, і натиснути кнопку Push.

5. Після цього переходимо на GitHub в наш репозиторій і там повинно з’явитись наступне повідомлення.

6. Натискаємо Compare & pull request -> Create pull request.

7. Щоб перевірити чи потрапили в пул реквест всі необхідні зміни, потрібно перейти на вкладку File changed.

Якщо у вас є знайомий/знайома, яка може перевірити ваш код і залишити свої рекомендації, це можна зробити саме тут, на цій сторінці.

Як вносити правки в поточний Pull Request?

Щоб внести правки в код після коментарів, потрібно повернутись в свій локальний проєкт, не переходити в нову гілку, і просто виправити всі зауваження. Далі робимо git add. потім коміт (зберігаємо зміни) і знову робимо git push origin [name_of_your_new_branch]. Після цього нові зміни просто відобразяться в поточному PR.

Що робити коли Pull Request прийнятий?

Якщо код в PR правильний, ми можемо залити зміни в master. Для цього переходимо у вкладку Conversation i натискаємо кнопку «Merge pull request» -> «Confirm merge».

Тепер на GitHub в гловній гілці є актуальна версія нашої програми. Щоб отримати таку актуальну версію в себе локально, потрібно повернутись в свій локальний проєкт, переключитись на гілку мастер, прописавши в терміналі git checkout master. Далі виконуємо команду git pull і всі зміни з віддаленого репозиторію стягуються в наш локальний проєкт і автоматично зливаються з нашим проєктом.

Крім цієї команди, можна скористатись командою «fetch». Різницю про ці команди можна прочитати тут.

Стягнути зміни локально можна використовуючи IntelliJ IDEA, для цього на верхній панелі потрібно знайти кнопку «pull», яка має вигляд синьої стрілки, направленої в лівий нижній куток. Натиснувши на неї, у вас з’явиться вікно, де потрібно натиснути «ОК».

Після цього всі зміни з віддаленого репозиторію підтягнуться у ваш локальний проєкт.

Далі робота над проєктом здійснюється за аналогією. Для кожного нового завдання — новий Pull Request. Не забуваємо про те, що потрібно стягувати актуальні зміни з віддаленого репозиторію в свій локальний проєкт. І пам’ятаємо, що нову задачу — вирішуємо в новій гілці, яку створюємо від гілки master.

Підсумок

На завершення, ще раз наголошу, що системи контролю версій створені для автоматизації та покращення процесу розробки програмного забезпечення. Тому сміливо використовуйте їх при написанні коду, навіть якщо ви тільки вчитесь програмувати. В майбутньому це дозволить значно зекономити час при роботі з реальними проєктами, і ваша робота стане ще ефективнішою.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Колись, давним-давно, одночасна робота над проєктом виглядала наступним чином. Один розробник вніс зміни в проєкт, заархівував його і відправив електронною поштою іншому розробнику. Після цього інший розробник розархівовує проєкт і звіряє його зі своїм проєктом, вносить актуальні зміни, знову архівує і відправляє наступному, і т.д. Я звичайно перебільшую, але думаю суть зрозуміла.

З приходом GitHub, кілька розробникім можуть синхронізуватись з віддаленим репозиторієм, і просто в процесі розробки заливати туди актуальні зміни. Тобто в будь-який момент часу можна зайти в репозиторій і отримати актуальну інформацію про програмний продукт над яким працює команда

Ні, звичайно ж, без github точно можна обійтись, якщо мова йде про централізоване зберігання репозиторія. Інша справа — мега зручні додаткові сервіси, що надає github. Наприклад можливості для створення issues, pull-requests, можливість поставити зірочку і ще «мільйон» різних дрібних допоміжних сервісів.

Під децентралізованістю мається на увазі можливість використання однієї системи контролю версій на проєкті кількома розробниками.

Під децетралізованістю у СУВ розуміється відсутність якогось одного центрального серверу — єдиної точки відмови. Так Git передбачає більше одного репозиторію (remote), в якому зберігається код. Плюс ще локальний.

Супер гарна стаття і гарне послідовне пояснення для новачків. Дякую.

Респект таким девушкам!

Колись, давним-давно, одночасна робота над проєктом виглядала наступним чином

Доставали стопку карточек и смотрели на пробитые в них дырочки. А не

відправив електронною поштою іншому розробнику

Пока не насмотришься на дырочки в карточках — никто не сможет твой участок кода тронуть/изменить.

«Дырявый код» — теперь звучит не так плохо.

Розходимося, пацани, виявилося, що git без Intellij і Maven не працює.

я так понял, что это относится для java разработчиков из-за idea? Больше работайте консолью для гита. Единственное, что я делаю через idea — это коммиты и просмотр коммитов, остальное все через консоль

Нэ, нужно работать исключительно из ide кнопочками чтобы гит переписали на Rust и оставили только 5 команд,а не 15 тысяч комбинаций параметров с неочевидными эффектами.

Я підозрюю, що це тільки перша частина... із цілого циклу статей... ;)

София спасибо за статью. Единственное что бы я поправил, это при работе в команде перед тем же пул реквестом или может даже коммитом, получать последнюю версию с репозитория что б залить свои изменения с актуальными изменениями команды.

git это как svn, но только сложней.
а чтоб эти все команды не учить и была понятная картинка пользуюсь черепахой

Git это самая логически прямая из distributed VCS.
SVN это криворожденный комплект склеенных соплями ржавых костылей с претензией на что-то высокое. Кто хочет централизованную систему (что само по себе в XXI веке фантастическая нелепость) лучше пусть использует CVS, она проще, честнее и понятнее.

лучше пусть использует CVS

это там где хистори у каждого файла своя?

Да, это заметный недостаток. Приходилось иногда искать связь по сообщениям коммитов. В сумме всё равно гимора оказывалось меньше, чем с CVS — потому что всё время лезли тупые грабли с тем, что что-то постороннее происходит рядом, что нет единого commit id (а вместо этого для ветки есть диапазон id, в котором ветка не меняется), и, как ни странно, меньше чехарды с мержами.
Может, за последние лет 5-10 её подправили — тогда мой отзыв устарел. Но всё равно смысла в ней уже нет.

Дивчинка з мейт академії вирішила пропіаритися? Доволі тривіальний туторіал. Підозрюю, що всі хто бодай 1 місяць користувалися гітом і ІДЕА знають це все

блин, но сколько труда...

Досить гарна реклама, писати на DOU статті бо його частіше читають ніж блог Mate

Подписаться на комментарии