Що таке Git і як зберігати історію змін?
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: Git — це розподілена система контролю версій, тобто інструмент для збереження історії змін у файлах. Він дає змогу порівнювати послідовні версії, відновлювати попередній вміст і поєднувати роботу кількох людей. Git працює локально на комп’ютері; для базової роботи не потрібні ні GitHub, ні підключення до інтернету.
Для чого потрібен Git?
Без контролю версій легко накопичити файли з назвами proiekt-final, proiekt-final2 і proiekt-vypravlenyi. Git замінює такі ручні копії впорядкованою історією. Кожен навмисно збережений етап можна описати, перевірити й порівняти з іншим.
Git особливо корисний для вихідного коду, конфігурації, документації та статей, збережених як звичайний текст, наприклад у Markdown. Він також може зберігати фотографії чи офісні документи, але зазвичай не показує зміни в них так само наочно, як відмінності між рядками тексту. Для великих двійкових файлів, які часто змінюються, потрібно додатково продумати спосіб зберігання.
Наприклад, ви змінюєте контактну форму, і після виправлення перестають працювати сповіщення. Якщо попередні етапи роботи були збережені в Git, можна перевірити, що саме змінилося, і скасувати невдалу зміну. Не доведеться відтворювати попередню версію з пам’яті.
Репозиторій, коміт і гілка — основні поняття
Репозиторій — це база історії проєкту разом з інформацією, потрібною Git для керування версіями. У типовому локальному проєкті ці дані містяться в прихованому каталозі .git, поруч із робочими файлами, які ви редагуєте.
Коміт — це збережений стан відстежуваних файлів, пов’язаний із попередньою історією. Він має ідентифікатор, інформацію про автора й опис. Вдалий опис, наприклад «Виправити перевірку адреси електронної пошти», пояснює мету зміни краще, ніж «Виправлення». Git не створює коміти автоматично після кожного збереження файлу в редакторі.
Область підготовки, яку також називають індексом або staging area, дає змогу вибрати зміни для наступного коміту. Завдяки цьому можна редагувати кілька файлів, але окремо зберегти виправлення помилки й оновлення документації. Так згодом буде легше зрозуміти історію.
Гілка, або branch, — це окрема лінія роботи в репозиторії. У ній можна розробляти нову функцію, не змінюючи одразу основну версію проєкту. Злиття, або merge, поєднує зміни з різних гілок.
Слово розподілений означає, що звичайне клонування репозиторію створює локальну копію його історії, а не лише надає доступ до файлів на сервері. Існують також клони з обмеженою історією. За стандартного способу роботи перегляд збережених змін і створення комітів не потребують зв’язку з центральним сервером.
Git і GitHub — чим вони відрізняються?
Git — це інструмент контролю версій. GitHub — сервіс, який, зокрема, зберігає репозиторії Git і надає можливості для співпраці, як-от перевірка змін чи повідомлення про помилки. Подібну роль виконують GitLab і Bitbucket; репозиторій також можна розмістити на власному сервері.
Віддалений репозиторій — це друга копія репозиторію, доступна за певною адресою. Команда push надсилає до нього локальні коміти, а fetch завантажує інформацію та історію з віддаленої копії, не інтегруючи їх у поточну гілку. Команда pull завантажує зміни, а потім інтегрує їх — спосіб інтеграції залежить від налаштувань і використаних параметрів.
Отже, саме створення коміту не публікує вашу роботу в інтернеті. А надсилання змін до сервісу хостингу не обов’язково робить їх загальнодоступними: видимість визначають права доступу до репозиторію.
Як почати: перше збереження змін
Установіть Git за інструкціями для вашої системи в офіційній документації проєкту. У терміналі можна перевірити встановлення командою git --version. Можна також користуватися графічним інтерфейсом або засобами роботи з Git у редакторі, але основний процес залишається тим самим.
У новому тестовому каталозі виконайте:
git init
git config user.name "Іван Коваленко"
git config user.email "ivan (at) example.com"
Ці налаштування автора стосуються поточного репозиторію й не призначені для входу в обліковий запис. Обирайте адресу усвідомлено: дані автора є частиною комітів і можуть стати видимими для інших, коли ви надасте доступ до історії.
Створіть у редакторі файл README.md, додайте короткий опис проєкту та збережіть його. Потім виконайте:
git status
git add README.md
git diff --staged
git commit -m "Додати опис проєкту"
git log --oneline
git status показує стан файлів. git add готує вказаний вміст до збереження, а git diff --staged дає змогу перевірити його перед комітом. Останні дві команди зберігають етап роботи й показують стислу історію.
Співпраця та обмеження Git
Під час спільної роботи Git може автоматично поєднати багато незалежних змін. Проте якщо двоє людей несумісним чином змінять той самий фрагмент, може виникнути конфлікт злиття. Тоді потрібно вручну визначити правильний вміст, позначити файли з розв’язаними конфліктами за допомогою git add і завершити операцію. Git не оцінює, яка версія правильна за змістом.
До репозиторію не слід додавати паролі, ключі доступу чи інші секретні дані. Файл .gitignore визначає, які невідстежувані файли Git має ігнорувати, але не видаляє дані, уже збережені в історії. Розкритий ключ потрібно відкликати або замінити; видалити його лише з найновішої версії недостатньо.
Git також не замінює повноцінного резервного копіювання: він не захищає автоматично незбережені зміни чи файли поза репозиторієм. Для початку створіть два коміти в тестовому каталозі й порівняйте їх командою git diff HEAD~1 HEAD. Ви побачите, як саме Git показує відмінності між збереженими етапами.
Дивіться також: Що таке AGI?
Читайте також
