Як Git полегшує роботу з кодом

Мінімум, який повинен знати кожен розробник.

Системи контролю версій (Version Control Systems) відстежують зміни у файлах. VCS допомагають розробникам фіксувати стан коду та повертатися до попередніх версій. За допомогою систем контролю девелопери можуть одночасно працювати над одним проєктом, не ламаючи код один одного. VCS робить зліпки файлів, до яких можна повернутися після будь-яких змін. Найпопулярніша система — Git. Розповідаємо, як керувати версіями коду за її допомогою.

Початок роботи

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

git config –global user.name "name"
git config –global user.email "name@gmail"

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

У Git код розміщується в репозиторії — локальному (на ПК), віддаленому (на сервері), розподіленому (і на ПК, і на сервері). Локальний репозиторій створюється в робочій директорії командою git init. Якщо потрібно завантажити (клонувати) репозиторій із віддаленого сервера на ПК, вводиться команда git clone із посиланням на сторонній репозиторій або SSH (протокол передачі даних).

H:\SOURCE\LMS>git clone https://github.com/instructure/lms.git
Cloning into 'lms'...
remote: Enumerating objects: 737104, done.
remote: Counting objects: 100% (37790/37790), done.
remote: Compressing objects: 100% (10079/10079), done.
remote: Total 737104 (delta 28167), reused 36757 (delta 27184), pack-reused 699314
Receiving objects: 100% (737104/737104), 921.15 MiB | 15.16 MiB/s, done.
Resolving deltas: 100% (566500/566500), done.
Updating files: 100% (16751/16751), done.

Зміни з клонованого репозиторію завантажуються командою git pull.

H:\SOURCE\LMS>git pull
Already up to date.

Додавання файлів

Файли мають три стани:

Untracked — файл ще не додали до репозиторію;
Modified — файл уже був у репозиторії та його змінили;
Staged — проіндексований файл, який можна додати до репозиторію.

Подивитися стан файлів можна за допомогою git status.

On branch main
Your branch is up to date with 'origin/main'.
 
nothing to commit, working tree clean

До репозиторію додаються лише staged файли. Файли індексуються командою git add. Можна вибрати:

усі файли за допомогою прапорця –а;
частину файлів за іменем або розширенням.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   new_file.txt

Логи та файли збирання не потрібно індексувати. «Зайві» файли записують у.gitignore — спеціальний текстовий файл у кореневому каталозі, де вказані винятки. Git читає цей файл та пропускає винятки.

# Compiled class file #
*.class

# Log file
*.log

# Package Files #
*.jar
*.war
*.nar

# Build directory #
build/

Синтаксис gitignor простий:

порожні рядки при читанні ігноруються;
файли та каталоги вказуються з нового рядка;
коментарі відзначаються #;
вказується ім’я чи розширення файлу;
директорії відзначаються /.

Щоби не писати gitignore самостійно, можна згенерувати його за допомогою стороннього сервісу — наприклад, gitignore.io.

Коміт — це операція з додавання всіх проіндексованих файлів до репозиторію командою git commit -m «changes message». Прапор m вносить опис змін. Коміти мають ім’я автора, час додавання, хеш і опис внесених змін. Для відправлення на віддалений сервер потрібно ввести git push.

Щоб орієнтуватися у всіх комітах та відстежувати історію змін, можна скористатися командою git log. log повертає опис усіх комітів, їх хеш-функцію та авторів, коміти виводяться в порядку від нових до старих.

    Init commit 
 
commit 429211da2fd03394e9c53c32f73cr964f3bad436
Author: Dmytro <dmytro@gmail.com>

Git Flow

Програмісти однієї команди пишуть різний функціонал програми одночасно. Щоб управління розробкою було ефективним, використовується практика поділу репозиторію на гілки Git Flow. Створюються гілки Main, Develop та відповідальні за окремий функціонал (Feature). Гілки вказують на коміти, які до них належать. Ідея полягає в тому, що Main відповідає за робочу версію, а реалізація окремих фіч зливається лише в Develop. Коли команда готова до релізу, вона створює гілку, яка потім і буде злита з Main. Так до Main потрапляє гарантовано робочий код.

Для створення гілки з фічею необхідно ввести команду git branch [feature_name]. Команда git branch без вказівки імені виведе всі локальні гілки, а прапор –r покаже гілки у віддаленому репозиторії.

* main
  develop

Коли розробник хоче злити зміни в гілку, він перемикається на неї за допомогою команди git checkout [branch_name], а потім об’єднує гілки командою git merge [branch_name]. Для видалення непотрібної гілки використовується git branch -d [branch_name].

Скасування змін

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

git checkout [hash_code] — відкочується до коміту за вказаним хешем;
git revert [hash_code] — скасовує вказаний коміт і створює новий.

Звернення до комітів відбувається за їхніми хешами. Хеш-коди довгі, але не обов’язково писати їх повністю — Git ідентифікує коміт за першими чотирма символами. Якщо ви не програміст, але стикаєтеся з кодом, ви можете користуватися графічними оболонками для git (наприклад Git Desktop або Git Kraken). GUI вбудовані в більшість IDE — наприклад, реалізація є в Intellij IDEA. Щоби не запам’ятовувати всі прапори для команд, можна переглянути документацію за допомогою git help [command_name].

Автор: Біденко Дмитро

Поділитися: