Цей контент є частиною серії: Git для користувачів Subversion
Слідкуйте за виходом нових статей цієї серії.
Для тих, хто не знайомий з безкоштовними VCS з відкритим кодом, слід сказати, що Subversion фактично стала стандартом некомерційної VCS, який замінив стару і добру CVS (Concurrent Versions System). Системи CVS все ще відмінно підходять для обмеженого використання, але Subversion приваблює тим, що для її роботи потрібно практично тільки невелика настройка Web-сервера. Subversion має деякі проблеми, які ми тут обговоримо, але в більшості випадків вона відмінно працює.
Так чому ж нам потрібно ще щось? Система Git (з великої "G"; тому git - це інструмент командного рядка) багато в чому спроектована так, щоб бути краще Subversion. Вона є однією з багатьох розподілених VCS. Особисто мені довелося працювати з Arch / tla, Mercurial, Bazaar, darcs і деякими іншими. З багатьох причин, про які я буду розповідати, коли вони будуть ставати важливими для нашої розповіді, Git стала популярною і часто вважається одним з двох лідерів (поряд з Subversion) серед персональних і корпоративних VCS.
Є дві причини, за якими ви, будучи користувачем Subversion, можете зацікавитися Git.
- Ви плануєте перейти до використання Git, так як Subversion вас в чому-небудь обмежує.
- Вам цікаво дізнатися про Git і ви хочете порівняти її з Subversion.
Хоча, можливо, є і третя причина: Git - це відносно нова технологія, яку ви хочете вказати в своєму резюме. Я сподіваюся, це не є вашою головною метою; вивчення Git - це одна з найбільш корисних речей, які може зробити розробник. Навіть якщо ви не використовуєте Git зараз, концепції і робочий процес, реалізовані в цій розподіленої VCS, напевно стануть важливими знаннями для більшості сегментів ІТ-індустрії в наступні 10 років, оскільки галузь переживає великі зміни в своїх кордонах і географічній структурі.
Нарешті, хоча це може і не бути вагомою причиною, якщо ви не займаєтеся розробкою ядра Linux, - Git використовується для супроводу ядра і безлічі інших важливих проектів. Тому, якщо ви плануєте внести свій вклад в будь-якої з відкритих проектів, вам потрібно познайомитися з цією системою.
У частині 2 цієї серії ми обговоримо продінутие прийоми використання Git: злиття гілок, генерація файлів відмінностей і інші типові завдання.
Основи Subversion і Git
Далі замість "Subversion" я буду використовувати абревіатуру "SVN", щоб менше зношувати клавіші U, B, E, R, S, I і O на моїй клавіатурі.
Можливо, ви чули про git-svn - інструменті, що дозволяє використовувати Git при роботі з репозиторієм Subversion. У деяких ситуаціях він може бути корисний, але використовувати клієнт від розподіленої системи при роботі з централізованої VCS - це все-таки не перехід на розподілену VCS.
Отже, чим же хороша SVN? Можливо, ви вже знаєте, що головним в VCS не є файли, а зміни. SVN, що працює на центральному сервері, додає зміни в свій репозиторій даних і може надати вам копію цих даних після кожної зміни. Ця копія має номер версії; номер версії дуже важливий для SVN і для людей, які працюють з нею. Якщо ваше зміна слід після мого, ваш номер версії гарантовано буде більше мого.
Git має схожу мету - відстеження змін, - але не має централізованого сервера. Це дуже важлива відмінність. SVN - система централізована, а Git - розподілена, тому в Git не може бути зростаючого порядку версій, так як в ній немає "останньої версії". Однак в ній все ж є унікальні ідентифікатори версій, просто самі по собі вони не так корисні, як номери версій (ревізій) в SVN.
Робота з Директорією в SVN
Лістинг 1. Налаштовуємо директорію для роботи в SVN
Що це нам дає? Тепер ми можемо отримувати з репозиторію останні версії будь-яких файлів в цій директорії, видаляти файли, перейменовувати їх, створювати нові файли і директорії, фіксувати зміни в існуючих файлах і т.д:
Лістинг 2. Прості файлові операції в SVN
Ми не будемо тут докладно вивчати ці команди, а просто їх запам'ятаємо. Щоб ознайомитися з базової довідковою інформацією по кожній з цих команд, наберіть svn help COMMAND. а для отримання детальної інформації звертайтеся до керівництва користувачів.
Робота з Директорією в Git
Я буду діяти таким же чином, як і в прикладі з SVN. Як і раніше, я припускаю, що у вас є директорія з даними.
В якості віддаленого сервера я використовував безкоштовний сервіс github.com, але ви, звичайно ж, можете використовувати будь-який інший сервер. GitHub це простий спосіб спробувати попрацювати з віддаленим Git-репозиторієм. На момент написання статті обсяг даних для безкоштовної облікового запису обмежений 300 МБ, крім того, репозиторій повинен бути публічним. Я завів обліковий запис з ім'ям "tzz" і створив публічний репозиторій "datatest"; можете його використовувати. Я надав свій публічний SSH-ключ. Якщо у вас ще немає свого ключа, слід його згенерувати. Також можна спробувати сервери Gitorious або repo.or.cz. В Wiki-розділі сайту git.or.cz є великий список сайтів, що надають послуги хостингу репозиторіїв Git (див. Посилання в розділі схожі теми).
GitHub хороший тим, що він доброзичливий до користувачів. Він повідомляє, які саме команди слід використовувати, щоб налаштувати Git і підготувати до роботи репозиторій. Виконаємо ці дії разом.
Лістинг 3. Базова настройка Git
Далі я настрою файли даних і не започатковано ними свій репозиторій. (GitHub також може імпортувати їх з репозиторію SVN, що може виявитися корисним.)
Лістинг 4. Налаштування директорії і перша фіксація
Git виводить інформацію про режими доступу до файлів; 100644 є восьмеричним поданням бітів прав доступу до цих файлів. На них можна не звертати уваги, а ось повідомлення про 2371 вставці може здатися загадковим. Адже ми змінили всього 2 файли, чи не так? Насправді це число позначає кількість вставлених рядків. І, звичайно ж, ми не видалили жодного рядка.
Лістинг 5. Публікація змін в віддаленому репозиторії
Тут OpenSSH видає попередження, пов'язане з тим, що раніше машина github.com була йому невідома. Не звертайте на нього уваги.
Повідомлення, що видаються Git, надзвичайно докладні. На відміну від легких для розуміння повідомлень SVN, в Git повідомлення написані присвяченими і призначені для присвячених. Якщо ви родом з Дюни Герберта Френка і навчені як біокомп'ютер, можливо ви зрозумієте їх, хоча тоді, можливо, ви вже написали свою власну версію Git. Ну а іншим повідомлення про дельта-стисненні і кількості використовуваних їм потоків просто не дуже важливі (і можуть викликати головний біль).
Перенесення змін був зроблений через SSH, але також можна використовувати інші протоколи, такі як HTTP, HTTPS, rsync і file. Більш детальну інформацію див. В довідці: git push --help.
Ми підійшли до найголовнішого відмінності між SVN і Git. У SVN операція commit вказує: «треба скопіювати це на центральний сервер». У SVN ваші зміни залишаються невловимими, поки ви їх не зафіксуєте (commit). У Git фіксація змін є локальною. у вас є локальний репозиторій, якому немає діла до того, що відбувається на віддаленій стороні. Можна відкотити назад зміна, гілка, зафіксувати зміну в галузі і т.д. без будь-якої взаємодії з віддаленим сервером. Публікація змін (push) в Git по суті є синхронізацією стану вашого сховища віддаленим сервером.
Добре, наостанок давайте подивимося, як те, що ми тільки що зробили, відображається в журналі Git:
Лістинг 6. Журнал Git
У журналі є запис тільки про фіксацію змін (зверніть увагу, що тут, на відміну від номера ревізії в SVN, фігурує довгий випадковий ідентифікатор операції фіксації). Немає жодної згадки про синхронізацію, що проводиться по команді git push.
Спільна робота за допомогою Git
До сих пір ми використовували Git в якості заміни SVN. Звичайно, щоб зробити все цікавіше, необхідно мати декількох користувачів і кілька наборів змін. Давайте працювати з нашим репозиторієм з ще однієї машини (я буду використовувати машину з Ubuntu GNU / Linux; на ній пакет, який треба встановити, називається не git. А git-core):
Лістинг 7. Налаштовуємо ще один екземпляр Git і завантажуємо в ньому вміст сховища
OpenSSH знову видає попередження про те, що раніше ця машина не працювала через SSH з GitHub. Команда git clone схожа на команду SVN checkout, але тут замість отримання певної версії вмісту ми отримуємо весь репозиторій цілком.
Я вивів тут вміст директорії datatest / .git і її піддиректорії hooks, щоб показати, що ми отримали дійсно все. За замовчуванням Git не таїть ніяких секретів, на відміну від SVN, яка за замовчуванням зберігає репозиторій в таємниці і надати їм доступ тільки до копій вмісту.
До речі, якщо ви хочете налаштувати для свого Git-сховища будь-які правила, які б виконувалися, наприклад, при кожній фіксації змін, це можна зробити за допомогою сценаріїв в директорії hooks. Це звичайні сценарії оболонки, багато в чому схожі на "пастки" в SVN, які відповідно до стандартів UNIX повертають нуль в разі успіху і що-небудь інше в разі помилки. Я не буду тут вдаватися в деталі сценаріев- «пасток», але якщо ви збираєтеся використовувати Git в командній роботі, вам безумовно слід їх детально вивчити.
Отже, користувач "The Other Ted" хоче додати новий файл в головну гілку (яку можна грубо співвіднести з гілкою TRUNK в SVN), а також створити нову гілку з деякими змінами в файлі gdbinit.
Лістинг 8. Додаємо файл і створюємо нову гілку
Це був довгий приклад, і я сподіваюся, що ви не заснули, читаючи його. Якщо ж ви заснули, я сподіваюся, вам снилися репозиторії Git, що синхронізуються в нескінченному вальсі наборів змін (о, не хвилюйтеся, вам буде це снитися).
Спочатку я додав і зафіксував файл (encode.pl, всього з одного рядка). Після фіксації віддалений репозиторій нічого не знав про те, що я зробив зміни. Потім я створив нову гілку empty-gdbinit і переключився в неї (також це можна було зробити командою git checkout -b empty-gdbinit). У цій галузі я додав порожній файл gdbinit і зафіксував цю зміну. І, нарешті, я переніс зміни на віддалений сервер.
Якщо переключитися в головну гілку, ми не побачимо в журналі записи про «empty gdbinit». Тобто кожна гілка має власний журнал, що видається логічним.
Лістинг 9. Переглядаємо журнали різних гілок
Коли ми виконали команду push, Git повідомив серверів GitHub: «Гей, подивіться, додався новий файл з ім'ям encode.pl»
Лістинг 10. Публікуємо всі зміни
Інтерфейс для мислителів знову постає у всій красі. Але ми зможемо розібратися в тому, що відбувається, чи не так? Можливо, ми не великі мислителі, але наш здоровий глузд підкаже нам, що 0000000000000000000000000000000000000000 - це якась спеціальна початкова мітка. Також з журналу, показаного в лістингу 9. ми можемо помітити, що мітка 5512d0a4327416c499dcb5f72c3f4f6a257d209f є останньою (і єдиною) фіксацією в галузі empty-gdbinit. Все інше для більшості користувачів могло бути написано і арамейською, так як їм до цього немає ніякого діла. Тепер в GitHub відображається нова гілка і її зміни.
Також є команди git mv і git rm. за допомогою яких можна відповідно переміщати і перейменовувати файли.
висновок
У цій статті я розповів про базові концепціях Git і організував з її допомогою управління версіями в простій директорії, порівнюючи її з ходу розповіді з Subversion. На простому прикладі я продемонстрував роботу з гілками.
З іншого боку, Git є дуже багатою DVCS; дізнавшись більше про її можливості, ви майже напевно станете їх використовувати для спрощення і поліпшення свого стилю роботи з VCS. Також, можливо, ви побачите пару снів про Git-репозиторіях.