
Дізнайтесь більше про нові кар'єрні можливості в EchoUA. Цікаві проекти, ринкова оплата, гарний колектив. Надсилайте резюме та приєднуйтеся до нас.
Почнемо, природно, із завантаження. Сподіваємося, яка у Вас операційна система, Ви знаєте. І відразу попередимо новачків: не плутайте 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
Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?