". Я Subversion навіть триметровим багром чіпати не буду."
- Linus Torvalds
Створення нового сховища
Створення нового сховища - це напевно перша із завдань, з якою стикається будь-який розробник. Створюємо відкритий репозиторій, з яким зможуть працювати інші люди. Припустимо, що у вас є якийсь сервер example.com і ваша робоча машина.
Далі вам треба створити репозиторій. Припустимо що ви будете зберігати всі git-репозиторії в / var / git:
Тепер у вас є порожній git-репозиторій. Це, власне кажучи, всі команди, які потрібно виконати на сервері.
Тепер йдемо на вашу робочу машину і пишемо:
Цими командами ми створили новий репозиторій, зв'язали його з основною гілкою example.git, закомітілі туди файл changelog і відіслали це на сервер. В результаті виконання цих команд, ви повинні побачити щось приблизно таке:
Отримання і оправлення сховища
Зрозуміло, після створення сховища розумно дізнатися "а як же отримати ці дані на свій комп'ютер?".
Для даної операції використовується команда clone. Вона створює повну копію віддаленого сховища у вас. Під повною копією розуміється саме повна копія, з усіма гілками, віддаленими файлами і т.д.
Зрозуміло, / var / git може змінюватися, в залежності від того, де розташовуються файли даного сховища на віддаленій машині.
Ефективно використовувати час
З таким локальним репозиторієм можна працювати довгий час, однак, колись у вас все ж виникне необхідність передати зроблені вами зміни в віддалений репозиторій, щоб результатами вашої праці могли скористатися інші учасники розробки, і отримати з віддаленого сховища нову версію. Для цього служать команди pull і push.
Дана команда отримує оновлену версію з віддаленого сховища, при цьому вона перевіряє на наявність різних проблем при об'єднанні репозиторіїв і повідомляє про це.
Дана команда цілком передає всі зроблені вами зміни, вже закоміченние в локальний репозиторій, в віддалений репозиторій. Для передачі тегів необхідно використовувати аргумент -tags
базові операції
Для базової роботи з будь-якою системою контролю версій потрібно не особливо великий набір операцій: додавання файлу в репозиторій, видалити файл зі сховища, комит змін в репозиторій, скасування незакоміченних змін і отримання списку змін.
Додавання списку файлів в комит:
Додавання всіх недобавленних файлів в комит:
Видалення файлу з коміта:
Видалення файлу з коміта і з жорсткого диска:
Коміт в локальний репозиторій (треба відзначити, що в такому випадку закомітятся тільки файли, які були оброблені за допомогою git add / rm):
Коміт всіх змін в локальний репозиторій:
Створення Діфа щодо останнього коміта:
Використання гілок
Рано чи пізно в будь-якому проекті виникає ситуація, коли потрібно заморозити зміни, але продовжувати працювати, а на заморожені зміни накладати тільки баг-фікси. Для цієї мети служать гілки (branch)
У гіті можна створити гілку від будь-якого місця. Для створення гілки від основного дерева треба виконати наступну команду:
В результаті цієї команди ви побачите приблизно таке повідомлення
Це означає, що в локальному репозиторії у вас створилася нова гілка.
Якщо в цій команді замінити origin / master на origin / remote_branch_name то ви створите гілку від іншої гілки.
Щоб ваша гілка була видна всім, її потрібно пропхати в віддалений репозиторій. Робиться це так:
Зрозуміло, треба також уміти і отримувати гілки в своє розпорядження
В результаті ви отримаєте шукану гілку після наступного повідомлення
Робота з тегами
Як правило, крім гілок розробники використовують теги - щоб запам'ятати стан коду в якийсь момент. Тег - це своєрідний зліпок, точно ідентифікує стан коду. Гіт вміє працювати з підписаними GPG тегами і з підписаними. Тут я розгляну тільки непідписані теги.
Для створення такого тега необхідно виконати команду
Щоб прибрати тег необхідно виконати
Для того, щоб тег стало видно всім, необхідно відправити його в віддалений репозиторій
Щоб отримати версію з конкретного тега необхідно створити від нього локальну гілку і расчекаутіть цю гілку:
Зрозуміло, в майбутньому цю гілку можна буде зробити глобальної і вислати в віддаленій репозиторій.
Налаштування git
Для прискорення деяких операцій і збільшення зручності роботи можна провести пару налаштувань:
Налаштування кольорового висновку:
Прискорюємо діфи і скасовуємо обмеження на кількість потоків упаковки при push:
замість висновку
Git - дуже потужна і зручна система контролю версій. Для неї існує кілька GUI утиліт, які можуть полегшити роботу, кілька веб інтерфейсів для моніторингу поточного стану. Останнім часом все більшу кількість проектів переходять на використання git, і це показник того, що git успішно розвивається і відповідає останнім вимогам в області систем контролю версій.
Велике у документації по використанню git можна знайти в мережі, в тому числі і на офіційному сайті
