Використання Git
Софт, вихідники та фото
Я давно вже збирався спробувати якусь розподілену систему контролю версій, але очі розбігалися між Bazaar, Mercurial та Git. Однак, колись на хабрі комрад VlK написав чудову статтю, яка й підштовхнула мене спробувати насамперед саме Git. Коли читав цю статтю, то виникали питання, відповіді на які знаходилися простими експериментами чи читанням документації. Саме тому я вирішив написати цю статтю, щоб іншим користувачам, які вирішили використовувати Git, було простіше. Тим більше, що сам я користуюся Windows, а це трохи впливає на використання Git, про що також буде написано.
А тепер це вже друга версія статті, оскільки з виходом Git 1.7 багато змінилося, в тому числі і на краще. :)
Розподілені системи контролю версій
Класичні системи контролю версій, такі як CVS, SVN або, не до ночі буде згаданий, SourceSafe розроблялися таким чином, що завжди є головний репозиторій, який містить усі зміни в коді, який через нього пройшов. У класичних системах контролю версій поняття репозиторію та робочої копії вихідників жорстко розділені. У робочій копії розробників знаходиться зліпок із поточного стану вихідних кодів у репозиторії.
На противагу цьому, у розподілених системах контролю версій у кожного розробника є свій репозиторій, причому папка з репозиторієм і є папка з вихідними джерелами (начебто останнє твердження справедливе не для всіх розподілених систем, але для Git це так). Понад те, у випадку може бути якогось одного головного репозиторію, проте вони можуть бути рівнозначні. Інше питання, що насправді є один репозиторій, який вважається головним, і куди потрапляють вихідники дляостаточного складання. Проте розподілена система дозволяє будувати ієрархії репозиторій, коли розробник відправляє зміни до одного репозиторію, який йому вважається головним, та був зміни з кількох таких головних репозиторіїв відправляють до найголовніший репозиторій.
Крім того, розподілені системи зручні в тому випадку, якщо розробник не має постійного доступу до головного репозиторію. У цьому випадку алгоритм його роботи буде наступним:
- Розробник клонує вихідний репозиторій собі на комп'ютер
Спочатку Git створювався Лінусом Торвальдсом (ага, тим самим) з метою створити таку систему контролю версій, в якій можна було б легко створювати відгалуження від основної гілки вихідних джерел, а також щоб максимально полегшити обмін змінами через звичні (особливо в лінуксі) патчі. Адже погодьтеся, що зручно відправляти свої зміни звичайною електронною поштою, не маючи доступу до запису в репозиторій.
Початок роботи
Вважатимемо, що Git ви вже встановили. Для того щоб розібратися як з ним працювати, не будемо використовувати жодні графічні оболонки. Але для демонстрації стану репозиторію та гілок я робитиму скріншоти з програми QGit, яка дуже наочно все показує.
Почнемо розбиратися з Git на такому прикладі. Створимо в окремій папці (у мене вона називатиметься demo) два файли. Один з них з ім'ям hello.py (скрипт на Python, але в даному випадку це не важливо) буде мати такий вміст:
А другий файл поки що буде порожнім і називатиметься опис.txt, щоб подивитися як Git працює з файлами, що містять українські літери в назві.
Таким чином, структура папок у нас на даний момент така:
Тепер, щоб створити репозиторій дляпапки demo, увійдемо до неї і виконаємо в командному рядку наступну команду:
Після цього консолі буде виведено повідомлення про те, що порожній репозиторій створений.
Initialized empty Git repository in. /demo/.git/
Тут замість ". " у вас буде написано повний шлях до вашої папки demo.
Після цієї команди у папці demo буде створена підпапка .git, яка зберігає всі версії змін. На відміну від CVS і SVN, ця папка буде одна і не розмножуватиметься в кожній вкладеній папці.
Тепер наше дерево папок виглядає так:
Давайте не звертати уваги на вміст папки git.
Репозиторій створено, але він, як говорилося, поки порожній, створені нами файли у нього не додані. Щоб побачити, в якому стані знаходиться репозиторій, у тій же папці demo виконаємо команду
В результаті побачимо наступний текст:
Тут Git каже нам, що ми знаходимося на даний момент у головній галузі репозиторію (On branch master) у початковому коміті. Не знаю як можна перекласти слово commit (фіксація?), щоб було зрозуміло контекст, тому давайте використовувати надалі такий жаргон.
Також Git пише, що два у нас є два файли, які не знаходяться в репозиторії, імена їх hello.py і якийсь \356\357\350\361\340\355\350\345.txt. Як можна здогадатися, останнє ім'я – це файл опис.txt. За промовчанням для символів, які не потрапляють у перші 128 символів кодової таблиці ASCII, Git виводить їх коди. Давайте відключимо цю особливість.
Налаштування Git
Усі налаштування Git зберігає у текстових файлах. Таких файлів кілька, формат їх однаковий, відмінності цих файлів полягає у сфері їх дії.
Другий файл лежить у папці профілю користувача, наприклад, у Windows XP це файл C:\Documents and Settings\USERNAME\.gitconfig.
А третій файл налаштувань лежить у кожному репозиторії у папці .git та носить ім'я config.
Пріоритет налаштувань виглядає так. У першу чергу переглядається файл налаштувань у поточному репозиторії, для не вказаних там налаштувань читається файл у профілі користувача, а вже для налаштувань, що залишилися, переглядається системний конфіг в папці Git\etc\.
Таким чином, ми можемо гнучко налаштовувати роботу з репозиторіями і в той же час загальні налаштування для різних репозиторіїв можемо виносити на більш високий рівень, щоб не налаштовувати їх у кожному репозиторії.
Усі налаштування поділені на розділи, а формат файлів config виглядає так:
Тепер повернемось до нашого репозиторію. Давайте відключимо подання українських букв у вигляді їхніх кодів. Для цього достатньо встановити параметр quotepath з розділу core у значення false.
Відкриємо файл config у папці .git, яку ми створили, і додамо до розділу [core] наступний рядок
Тепер наш файл налаштувань виглядає так: