ІТ

Основи Git та GitHub: як керувати системою контролю версій та працювати в команді над спільним проектом

17.01.2024

265 views

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

Це рішення – Git, розподілена система контролю версій, яка стала галузевим стандартом. Для полегшення командної роботи, проведення код-рев’ю та безшовної інтеграції GitHub також виріс у провідну платформу для хостингу репозиторіїв та управління спільними робочими процесами.

У цій статті я ділюся комплексним гайдом по Git та GitHub, який допоможе як новачкам, так і досвідченим розробникам оптимізувати процеси контролю версій. Я розгляну основи моделі даних Git, поясню, як розпочати роботу з Git і GitHub, а також надам практичні рекомендації щодо ефективної командної співпраці. Моєю метою є дати вам знання та впевненість у використанні цих інструментів для будь-якого програмного проекту – чи то open-source бібліотека, продукт стартапу або масштабна корпоративна система.

Чому контроль версій є важливим

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

Перезаписані файли: Без механізму відстеження змін один розробник міг легко перезаписати роботу іншого.
Невизначена історія: Розуміти, чому була зроблена певна зміна або хто її зробив, майже неможливо без належних повідомлень комітів та збереженої історії.
Складна співпраця: Злиття змін від кількох учасників може перетворитися на хаос, якщо немає системи для управління одночасними модифікаціями.

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

Основні поняття Git

Перш ніж зануритись у практичне використання, важливо зрозуміти, як Git працює “під капотом”. На відміну від традиційних централізованих систем контролю версій (наприклад, Subversion), Git є розподіленою системою. Кожен користувач має повну копію репозиторію, включаючи всю історію змін.

Знімки, а не відмінності

Багато новачків припускають, що Git зберігає зміни як «відмінності» (diff). Насправді Git зберігає кожен коміт як знімок вашого проекту на певний момент часу. Хоча для економії місця він використовує стиснення та посилання, концептуально кожен коміт є повною версією файлів проекту на даний момент. Якщо файл не змінювався, Git просто посилається на попередню збережену версію цього файлу.

Три основні області: робочий каталог, індекс (staging area) та репозиторій

Робочий каталог: Це локальна папка, де ви активно редагуєте свій код.
Індекс (Staging Area): Тут ви вибираєте, які зміни слід включити до наступного коміту. Завдяки цьому ви можете точно визначити, які модифікації потраплять до історії.
Локальний репозиторій: Після коміту ваші зміни зберігаються у папці .git в межах проекту, стаючи частиною історії змін.

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

Налаштування Git

Запуск Git досить простий, незалежно від того, чи використовуєте ви Windows, macOS або Linux.

Встановлення Git:
- На Windows можна завантажити інсталятор Git з git-scm.com.
- На macOS Git часто встановлено за замовчуванням; якщо ні, його можна встановити через Xcode Command Line Tools або Homebrew.
- На Linux зазвичай Git встановлюють через менеджер пакетів (наприклад, sudo apt-get install git для Ubuntu).
Налаштування вашої особистості:Після встановлення я завжди налаштовую своє ім’я та електронну адресу, щоб мої коміти належним чином відображали мою особу:
```
git config --global user.name "Ваше ім'я"
git config --global user.email "you@example.com"
```
Перевірка конфігурації:Ви можете перевірити налаштування, виконавши:
```
git config --list
```
Створення нової папки для проекту:Якщо ви розпочинаєте новий проект, перейдіть до потрібної папки через термінал та ініціалізуйте репозиторій:
```
git init
```
Ця команда створює папку .git, що позначає дану директорію як Git-репозиторій.

Перші кроки в Git: практичний приклад

Припустимо, у мене є простий застосунок – наприклад, веб-сайт з HTML, CSS та невеликим скриптом на JavaScript. Я хочу почати використовувати контроль версій для цього проекту.

Додавання файлів:Розмістіть існуючий код (наприклад, index.html, style.css, app.js) у відповідній папці.
Перевірка статусу:Я завжди перевіряю статус репозиторію перед комітом змін:
```
git status
```
Git покаже, що ці файли знаходяться в стані “untracked” (не відстежуються).
Додавання файлів до індексу:Щоб почати відстежувати файли, я додаю їх до staging area:
```
git add index.html style.css app.js
```
Також можна використати команду git add . для додавання всіх файлів.
Створення коміту:Коміти схожі на точки збереження. Я можу закомітити зміни з описовим повідомленням:
```
git commit -m "Початковий коміт з базовою структурою проекту"
```
Перегляд історії комітів:Виконайте:
```
git log
```
Ця команда відображає коміти у зворотному хронологічному порядку, показуючи, хто, коли і з яким повідомленням вніс зміни.

Розгалуження в Git

Одна з найпотужніших функцій Git – можливість створювати гілки. Коли я працюю над новою функцією, я зазвичай створюю окрему гілку, щоб основна (main) залишалась стабільною. Після завершення роботи над функцією я зливаю її з основною гілкою.

Створення нової гілки:
```
git checkout -b feature/add-user-auth
```
Ця команда створює і перемикає вас на нову гілку feature/add-user-auth.
Розробка та коміти:Під час роботи над кодом автентифікації я роблю невеликі, логічні коміти. У разі виникнення проблеми я можу повернутись до попереднього коміту у цій гілці.
Злиття з основною гілкою:Після завершення роботи над функцією я повертаюсь до основної гілки:
```
git checkout main
```
Потім виконую злиття:
```
git merge feature/add-user-auth
```
Якщо конфліктів немає, Git безперешкодно застосовує зміни. У разі виникнення конфліктів, Git вкаже, які рядки у яких файлах потребують уваги.

Знайомство з GitHub

Хоч Git є локальною системою контролю версій, більшість сучасних проектів потребують віддаленого репозиторію для:

Резервного копіювання та зберігання історії змін у хмарі;
Командної співпраці та проведення код-рев’ю;
Легкого інтегрування з CI/CD для автоматичного розгортання.

GitHub надає всі ці можливості та ще більше. Хоч існують альтернативи, як-от GitLab чи Bitbucket, GitHub залишається однією з найпопулярніших платформ. Як розробник, я ціную екосистему GitHub за її сприяння співпраці, потужні функції запитів на злиття (Pull Requests), GitHub Actions для CI/CD та широку спільноту відкритого коду.

Створення репозиторію на GitHub

Реєстрація:Якщо у вас немає акаунту, зареєструйтеся на github.com.
Створення нового репозиторію:Натисніть кнопку «New» у розділі репозиторіїв вашого профілю. Ви можете обрати публічний репозиторій (для open-source проектів) або приватний.
Ініціалізація репозиторію або підключення існуючого локального репозиторію:Якщо починаєте з нуля, GitHub може створити порожній репозиторій або ініціалізувати його з README. Якщо ж у вас уже є локальний репозиторій, дотримуйтесь інструкцій GitHub для завантаження існуючого проекту.

Підключення локального репозиторію до GitHub

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

git remote add origin https://github.com/YourUsername/YourRepository.git
git branch -M main
git push -u origin main

Пояснення:

git remote add origin ... встановлює зв’язок між вашим локальним репозиторієм та віддаленим репозиторієм на GitHub, називаючи його «origin».
git branch -M main встановлює поточну локальну гілку як основну (main), якщо вона ще не названа так.
git push -u origin main завантажує ваш код на GitHub і встановлює upstream-гілку.

Відтепер, коли я роблю коміти локально, я можу поділитися ними з командою за допомогою команди git push. Аналогічно, я можу отримати зміни від інших розробників за допомогою git pull.

Запити на злиття та код-рев’ю

Однією з моїх улюблених функцій GitHub є робота з Pull Requests (Запити на злиття). Вона надає структурований спосіб запропонувати, обговорити та переглянути зміни перед злиттям їх в основну гілку.

Створіть гілку та зробіть коміти:Як уже згадувалося, я зазвичай створюю окрему гілку для кожної нової функції або виправлення.
Завантажте гілку на GitHub:
```
git push -u origin feature/add-user-auth
```
Відкрийте запит на злиття:На GitHub перейдіть до вашого репозиторію. Натисніть кнопку «Compare & pull request», яка з’явиться після завантаження нової гілки. Додайте зрозумілий заголовок та опис змін, зазначте причини для виправлень чи додавання функції.
Обговорення та перегляд:Колеги (або ви самостійно, якщо працюєте над проектом самостійно) можуть коментувати окремі рядки коду, ставити запитання або пропонувати покращення. За необхідності можна додати нові коміти до тієї ж гілки для врахування зауважень.
Злиття запиту:Коли всі будуть задоволені, можна зливати запит на злиття з основною гілкою. GitHub зберігає історію обговорення та остаточного злиття, що стає чудовим довідковим матеріалом для розуміння, чому були зроблені певні зміни.

Найкращі практики для ефективної співпраці

На основі мого досвіду роботи як у невеликих, так і у великих командах, я визначив наступні стратегії як надзвичайно корисні:

Значущі повідомлення комітів: Пишіть короткі, але змістовні повідомлення, що пояснюють, які зміни були зроблені і чому. Це критично важливо для збереження зрозумілої історії проекту.
Часті коміти: Невеликі, регулярні коміти полегшують відстеження змін, дозволяють швидко відновити попередню версію та зменшують ризик виникнення складних конфліктів при злитті.
Робота за принципом feature-branch: Зберігайте основну гілку стабільною, створюючи окремі гілки для нових функцій. Зливайте їх до основної лише після повного тестування та завершення розробки.
Код-рев’ю: Перевірка коду перед злиттям не тільки допомагає знаходити помилки, але й служить можливістю для навчання всіх учасників.
Безперервна інтеграція: Використовуйте інструменти, такі як GitHub Actions, Jenkins або Travis CI, для автоматичного складання та тестування коду щоразу, коли відбуваються зміни. Це допомагає підтримувати стабільність основної гілки.

Просунуті операції Git

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

Rebase: Замість злиття (merge) можна використовувати rebase, який переписує історію комітів, ніби усі ваші зміни відбулись після останніх комітів у основній гілці. Це створює лінійну історію, але потрібно використовувати з обережністю, особливо для публічних гілок.
Cherry-Pick: Якщо потрібно перенести окремий коміт з однієї гілки в іншу, використовуйте команду cherry-pick. Це особливо корисно, коли виправлення помилки в одній гілці потрібно застосувати і в іншій.
Submodules: За їх допомогою можна вкладати один Git-репозиторій у інший, що корисно, коли у вас є окремі проекти, які потрібно розробляти разом.

Типові помилки та як їх уникнути

За час роботи з Git я зіткнувся з декількома типічними проблемами:

Невипадкове комітування конфіденційних даних: Завжди використовуйте файл .gitignore для виключення облікових даних або великих файлів. Якщо ви випадково додали секретну інформацію до коміту, негайно видаліть її та змініть паролі або токени.
Складні конфлікти при злитті: Конфлікти при злитті можуть бути досить виснажливими. Ретельно перевіряйте внесені зміни з обох боків і після вирішення конфліктів обов’язково протестуйте роботу проекту.
Забування оновити репозиторій перед завантаженням змін: Якщо не виконати git pull перед git push, ваші зміни можуть не завантажитись або виникнути конфлікти. Проста команда git pull допомагає синхронізувати роботу всієї команди.
Надмірне використання force push: Команда git push --force може перезаписати історію в віддаленому репозиторії, що призведе до втрати важливих даних або вплине на роботу інших розробників. Використовуйте її лише у випадках крайньої необхідності.

Висновок

Опановування Git та GitHub змінило мій підхід до розробки програмного забезпечення. Те, що спочатку здавалося складною системою, перетворилося на надійний інструмент, який дозволяє експериментувати, ефективно співпрацювати та зберігати чітку історію змін. Сьогодні майже кожна професійна команда розробників покладається на Git (а часто і на GitHub) для координації роботи, автоматизації процесів збірки та розгортання, а також для організації історії проекту.

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

Сподіваюся, що цей гайд допоможе вам здобути як теоретичні знання, так і практичні навички для впевненого використання Git та GitHub. Продовжуйте досліджувати просунуті функції, інтегрувати інструменти безперервної інтеграції/розгортання та вдосконалювати свій робочий процес – і ви відкриєте для себе всю міць сучасного контролю версій.

Успішної розробки та ефективного контролю версій!

Дивіться огляди: