Git. Швидкий старт з використання основних операцій із поясненнями

Почнемо, природно, із завантаження. Сподіваємося, яка у Вас операційна система, Ви знаєте. І відразу попередимо новачків: не плутайте git і GitHub – це різні речі. Нас цікавить саме git, а GitHub (чи йому подібні сервіси ніби Bitbucket або GitLab) – це, по суті, хостинг для проектів, які використовують git.

 

Репозиторій

Отже, ось у Вас вже є git. Тепер треба створити сховище версій для нього. Запам’ятайте, це сховище називається репозиторій (англ. repository) – при нагоді можете вставити де-небудь це слово. Залежно від того, яка у Вас оболонка, відповідною командою створіть нову директорію, відкрийте її (у командному рядку, вона ж оболонка, а не провідником або чимось подібним) і виконайте:

git init

Все, локальний репозиторій в цій теці створений. Те, що тут зараз зберігається, буде бекапом, тому, щоб його не зіпсувати, створимо робочу копію (англ. check out) локальної версії:

git clone [url]

Де [url] – це шлях до клонованого репозиторія. Ми розбираємо зараз випадок, коли Ви створюєте робочу копію власного репозиторія, тому як [url] тут Вам треба вказати шлях до директорії, для якої ми виконували git init.

Але якщо Ви вже працюєте з видаленим сервером, то ось така команда буде саме для Вас:

git clone username@host:/path/to/repository

Ліс git ‘а

Трохи теорії. Git у своїй роботі керує трьома структурами, які називаються деревами. Перше – це робоча директорія, в ній зберігаються файли, з якими Ви зараз працюєте. Вона ж робоча, тому логічно. Друге – це Index, отакий чек-поінт, який дозволяє Вам вносити зміни і нічого не псувати. А третє – це HEAD, який вказує на останній зроблений Вами коміт (не заплутайтесь у термінології: коміт (англ. commit) – це збереження стану проекту в репозиторії. Вважайте, нова версія).

Так от, щоб Ви не заблукали в цих трьох соснах, запам’ятаєте дві команди: add і commit. Вони дозволять Вашій роботі спокійно переміщуватись по git’у, зберігаючись, куди потрібно. Якщо Ви придумали щось геніальне і тут же внесли зміну в робочу копію проекту, то не поспішаєте відразу комітити! Спочатку випробуйте в Index’е, для цього виконаєте:

git add [ім'я_файлу]

якщо Ви внесли зміну тільки в один файл, або

git add *

якщо Ви добре попрацювали: поміняли відразу багато первинників. Зміни позитивні? Добре потестили? Тоді швидше комітить:

git commit - m "Commit message"

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

Ось Вам, до речі, пояснююча картинка:

Тепер файл (-и) міцно влаштувалися в HEAD Вашої робочої локальної копії. Звідти їх не вигнати, але у Вашому видаленому репозиторії їх все ще немає. Давайте розмістемо їх ще й туди! Використайте:

git push origin master

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

Для працюючих із серверами (якраз тут доречно говорити про GitHub, наприклад), команда буде такою:

git remote add origin [сервер]

Галуження (або бранчування)

Англійською branching – краще як слід вивчіть це питання і прочитайте про галуження докладніше, я Вас з ним тільки ознайомлю. Галуження використовується для одночасної і незалежної розробки різних фічів (або накопичення більшої кількості багів, адже вихідного коду стає більше). Основною гілкою є master – вона з’являється при створенні репозиторія. Інші гілки – це пісочниці, коли досхочу в них награєтеся, злийте в єдине ціле в master. Зараз поясню, як це робиться.

Створення нової гілки

Ось Ви вирішили опрацювати якусь нову фічу. Створіть для неї нову гілку:

git checkout - b [нова_гілка]

Ах так, фантазія-то у Вас, напевно, відмінна, проте обмежте її у справі найменування гілок: назвати гілку можна тільки ім’ям, допустимим для змінної у Вашій улюбленій мові.

Перемикання між гілками

Потрібно зробити перерву в роботі з цією фічею і перемкнутися на іншу гілку? Використайте (якщо працюєте з локальним репозиторієм, то вказувати його ім’я не обов’язково):

git checkout [репозиторій]/[гілка]

Ну, а якщо Ви вже зовсім не хочете з нею працювати, то видаліть її зовсім:

git branch - d [гілка]

Зі своєю гілкою Ви можете робити будь-що: її ніхто не побачить, поки Ви самі її не відправите у віддалений репозиторій командою:

git push origin [гілка]

Злиття гілок

Щоб злити гілку в ту, з якою Ви зараз працюєте, використайте:

git merge [гілка]

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

git add [ім'я_файлу]

До речі, гілки можна порівняти:

git diff [одна_ветка] [друга_гілка]

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

git pull

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

git tag [tag] [перші_десять_символів_відповідного_коміта]

Ви не знаєте, які перші символи в імені потрібного коміта? Не біда, дивіться в історію репозиторія – його лог:

git log

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

Я не те змерджив!

Ну, а тепер давайте розповім Вам, як виправляти свої помилки, хоча Ви впевнені, що їх не робитимете. Якщо проблема тільки в одному файлі, то ось вам Ctrl+Z для HEAD’a:

git checkout --[ім'я_файлу]

Але якщо проблема знаходиться в локальному репозиторії, то “зачистіть” там все і поверніть версію із сервера:

git fetch origin git reset --hard origin/master

Так, тут все по-hard ‘овому. Це git.

Фічі git ‘а

Якщо Ви ледачий, і Вам не хочеться все писати в оболонці своєї ОСі, то можете використати GUI git ‘а:

gitk

У джерелі знайдете ще багато інших GUI.
Якщо Вам стандартне виведення git ‘а здається нудним, розфарбуйте його:

git config color.ui true

Ну, і є інтерактивне індексування. Коли у Вас буде великий проект, то стиснути представлення index ‘а в log ‘е можна буде так:

git add - i

Сподіваюся, це керівництво допоможе Вам на ранніх етапах не заплутатися в роботі з git ‘ом і Ви, нарешті, навчитеся стежити за своїми бекапами.

За матеріалами rogerdudler.github.io