GIT (вимовляється "ґіт") - це безкоштовна програма з відкритим кодом, розроблена для розподіленого контролю за версіями проекту (distributed version control system, VCS). "Проектом" може бути будь-що, що зберігається на комп'ютері у вигляді файлів. В тому числі, звичайно, проекти програмістів.
Роботу над Git розпочав Лайнус Торвальдс (Linus Torvalds) в 2005 році з метою керування версіями для написання ядра операційної системи Linux. Слово git в британському слензі має значення "неприємна персона".
Офіційний сайт програми - git-scm.com. SCM - це абревіатура від source control management. Звідти ж можна завантажити програму, а також безкоштовну книжку для її вивчення - Pro Git написану Scott Chacon та Ben Straub.
Для Windows програма встановлюється просто - потрібно тільки завантажити exe-файл та запустити його:
При встановленні потрібно обрати спосіб запуску програми з консолі - Git Bash, консоль від Windows, або консоль від Windows плюс деякі команди Unix. Рекомендують обрати перший варіант:
Після встановлення у вас буде можливість як запуску програми в консолі, так і в графічній оболонці. Для тіснішого, першого конаткту з програмою краще почати з консольного варіанту:
Для того, щоб розпочати працювати з програмою, потрібно спочатку розібратись в її термінології та базовому порядку роботи - basic workflow (www.git-tower.com).
1) Базовим будівельним елементом для Git є репозитарій (repository). Репозитарій - це сукупність файлів, де зберігаються всі дані стосовно вашого проекту (різні версії файлів проекту, метадані). Репозитарій представляє собою звичайну невидиму папку, яка має назву ".git" і знаходиться в кореневій папці проекту. Наприклад, для проекту, для якого використовується IDE Eclipse, це може бути папка із вихідним кодом src, всередині якої ми можемо створити директорію-репозитарій .git. Про структуру папки .git можна почитати на www.siteground.com.
Є два шляхи створення репозитарію на вашому ПК:
- ви самі створюєте його для свого власного проекту, над яким працюєте локально;
- ви приєднуєтесь до роботи над існуючим проектом, для якого вже створено репозитарій в мережі (інтранет, або інтернет). В такому разі ви його клонуєте (clone) на свій ПК.
2) Як тільки ви створили свій локальний репозитарій, ви можете приступати до роботи над проектом, тобто писати код. Відповідно, ви будете редагувати існуючий код, писати новий, створювати нові файли, видаляти їх, або переіменовувати... Тобто ви виконуєте звичну для програміста роботу. На цьому етапі ви не маєте справу з Git, ви працюєте над кодом в звичній для вас IDE.
3) Як тільки ви бачите, що ваша робота принесла плоди і ви отримали нову, РОБОЧУ версію програми (з новим, або вдосконаленим функціоналом), ви можете знову звернутись до Git і зберегти ваші зміни у вигляді нової версії. Таким чином, ви фіксуєте точку відкату, куди ви зможете без проблем повернутись в разі, якщо подальша робота над проектом заведе вас в царство непофіксених багів, з якого вже неможливо вибратись. Цей етап називається підтвердженням (реєстрацією) правки (commit).
Підтвердження змін (Commit)
Підтвердження змін - це запамятовування окремої підмножини змін. Автор змін повинен написати короткий коментар про те, що саме було зроблено (написати так званий "commit message"). В майбутньому це повідомлення допоможе іншим розробникам, та і йому самому, зрозуміти, що конкретно було зроблено на даному етапі.
Кожна множина змін створює іншу, нову версію вашої програми. Це ніби поточний знімок цілої програми, але зроблений у значно ефективніший спосіб, ніж просте копіювання всіх файлів проекту. Після підтвердження правки (commit) Git запам'ятовує точний стан всіх ваших директорій та файлів, що в майбутньому може бути використано для відкату проекту до цього стану.
4) Проте перед тим, як підтвердити зміни (to commit), ви захочете перевірити, що саме було змінено від часу останнього підтвердження. В Git для цього є команда status, яка показує список всіх останніх змін: які файли було редаговано, які файли було створено, або які були видалені.
5) Але факт самої зміни стану проекту, ще не говорить, що всі зміни потрібно підтвердити. По-перше, підтверджувати краще вже закінчені, робочі зміни, тобто код, який відлагоджено і який функціонує. По-друге, підтвердження змін краще розділити на логічні частини і підтверджувати (to commit) їх окремо. Наприклад, протягом останніх днів роботи було додано новий метод до існуючого класу, та створено новий клас. Якщо ці події не пов'язані між собою логічно, то краще запам'ятати їх окремо. Таким чином, ми будемо мати два окремих стани проекту, куди у разі необхідності ми зможемо повернутися.
В термінології Git ми говоримо, що додаємо (add) обрані поточні зміни до тимчасової зони (staging area).
6) Додавши до тимчасової зони набір певних змін, ми власне можемо перейти до підтвердження цих змін. Програма попросить додати коротке текстове повідомлення, яке опише суть змін. Після цього зміни (commit) будуть збережені у вашому локальному Git-репозитарії, являючи собою нову версію проекту.
7) Час від часу ви захочете переглянути історію вашого проекту. Для цього існує команда "log", яка покаже всі підтверджені зміни в хронологічному порядку.
8) Також важливим є поняття розгалуження (branching). Ідея розгалуження полягає в тому, щоб працювати над різними аспектами одного і того ж проекту в різних, паралельних вимірах. Наприклад, ви одночасно можете працювати над новим функціоналом, або над альтернативним варіантом старого функціоналу, чи виправляти виявлені помилки, разом з тим, потрібно інтегрувати в проект розробки ваших колег... Кожна така задача являє собою окремий контекст роботи. Якщо все це робитив в одному процесі, то рано чи пізно виникнуть певні проблеми. Наприклад, ви інтегрували код ваших колег, але він спричиняє помилки. Або ви розробили новий функціонал, а замовнику він вже не потрібний. Оптимізація, яку ви виконували, зайшла в глухий кут. Як вирішити кожну окрему задачу, щоб при цьому не довелося втручатися і розбиратися у всьому створеному до цього коді?
Якраз ідея розгалуження зможе дати відповідь на ці питання.
На кожній гілці (branch) ви працюєте окремо від інших гілок. Критичні помилки, які там виникають, не вплинуть на загальну картину проекту. Якщо ви більше не маєте потреби в певній частині коду, то ви просто видаляєте відповідну гілку, не переймаюись, як це може вплинути на інші частини проекту.
9) Наступне поняття - об'єднання (merging) паралельних гілок. Логічно, що рано чи пізно, ви захочете об'єднати ваші напрацювання в інших гілках з головною гілкою, щоб отримати цілісну програму.
10) Два наступних процеси пов'язані з роботою із віддаленим сховищем (репозитарієм). По-перше, вам потрібно завантажити останні зміни з віддаленого репозитарію - команда
git pull.11) По-друге, потрібно свої зміни також записувати до спільного сховища, щоб інші могли їх використовувати -
git push.12) Ну і, нарешті, одна з ключових функцій VCS - відкат до попередніх версій проекту. Для цього існує кілька команд:
-
git commit --amend -m модифікувати останній коміт;-
git checkout -- шлях/до/файлу - відкат до останнього коміту стосовно вказаного файлу;-
git reset --hard HEAD - схоже до попердньої команди, тільки відміняє всі поточні зміни, стосовно цілого проекту;-
git revert хеш_номер_коміту - відмінити вказаний коміт поточної гілки;-
git reset --hard 2be18d9 - відкат програми до вказаного коміту в поточній гілці.
Немає коментарів:
Дописати коментар