GrAndSE's blog

Перший крок в Git

Практично рік вже минув з того моменту, як я писав про git. Тоді я ще користувався svn і лише цікавився тим, що ж таке створив Лінус Торвальдс. А тепер ось спробував попрацювати з git і отримую задоволення від роботи з ним. Та що там казати, в мене практично ейфорія від того, як швидко він працює, як все просто робити, наскільки менше проблем виникає порівняно з тим самим svn. І ось думаю, а що ж мені заважало розібратись з git раніше? Відповідь тривіальна: не знайшов нормального мануала. Серія статей чудово розповідає про внутрішню кухню в git, про те там відсутнє головне: як почати працювати.

Я людина доволі лінива і самому розбиратись мені довгий час було лінь. Завжди знаходилась купа термінових справ, непрочитаних статей, книжок, ненаписаного коду та бажання просто відпочивати. Ну все ж знайшов час і ще раз скажу, що отримую задоволення від роботи з цим інструментом. Хочу поділитись своїм досвідом про перший крок з Git. Для тих хто сумнівається, чи слід читати далі пропоную переглянути "промо" Why Git is Better Than X

Крок перший

Git - розподілена система контроля версій. Тобто для початку роботи, немає жодної необхідності налаштовувати якийсь сервер, достатньо лише git, встановленого на клієнтській машині. Зараз відстуні проблеми встановленням git (в усякому разі під будь-якою *nix-системою). Наприклад, в будь-якій Debian-based системі можна виконати команду:

Тепер достатньо перейти в директорыю з файлами проекту та ініціалізувати git-репозиторій:

Маємо отримати повідомлення про те, що новий пустий репозиторій git було створено. Теперь можна додати всі файли проекту до репозиторія:

Тут зупинюсь трошки детальніше. Опція -A змушує додати чи оновити всі файли в тому, числі які вже були додані чи могли бути проігноровані. Ну а опція -v звична для всіх *nix команд і вмикає розширений вивід. Таким чином ми побачимо всі дії виконані з файлами. Ну а параметр . вказує який файл слід додавати в репозиторій. Оскільки в прикладі це директорія, то всі файли будуть додані.

Припустимо необхідно додати лише один файл, тоді команда матиме вигляд:

Ну що ж, файли додано, тепер можемо зробити перший комміт.

В реузльтаті отримаємо отримаємо щось на зразок:

Опція -a вказує на те що необхідно автоматично додати зміни для всіх змінених чи виделених файлів. Слід врахувати, що нові файли, що не були додані до проекту за допомогою git add не будуть враховані. Опція -m дозволяє до комміту додати коментар. Вважаю, що досить розумно додавати коментарі з короткими поясненнями, які зміни відбулись.

На цьому перший крок можна вважати завершеним.

Крок другий

Ну що ж. Перший крок зроблено. Настав час рухатись далі і попрацювати з гілками. Що таке гілки? Це рвідгалудження від основної лінії розробки. В рамках головна гілка називається master.

Які переваги це дає? Наприклад, в стабільному напрямі проекту, тобто master, відбувається пуступове накопичення функцій, додання нового функціоналу, що не чіпляє старий код. Тут все йде лінійно та за планом. Так зазвичай працюють з svn. Однак, якщо в процессі розробки виникає ситуація, коли до раніше написаного коду потрібно внести досить великі зміни чи додати одну експерементальну функцію не припиняючи внесення змін до основною гілки? Зупинити весь проект, дочекатись поки не будуть завершені зміни до раніше написаного коду? Неефективно, тому-що вносити зміни в старий код в ряді випадків може тільки одна людина, тоді всі інші мають чекати. Робити одночасно зміни в старому коді та додавати нові функції? Може статись так, що замість тільки що доданий функціонал буде несумісним з тими змінами, що відбулись в попередньо написаному коді.

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

Здавлося б в subversion такі можливості теж є. Однак, наскільки мені відомо всі, хто користуються цією системою контроля версій уникають використання гілок. Причиною тому є складність у роботі з гілками та ще необхідність постійно звертатись до серверу, що значно сповільноє роботу системи (навіть у локальній мережі час передачі файлів та виконання операцій порівняння займає багаточасу порівняно з операціями на локульній файловій системі). Особисто я лише раз зіштовхнувся з гілками та svn з моменту свого знайомства з ним (а це відбулось майже три роки тому, восени 2006). І враження залишились у мене далеко не найкращі.

Давайте створимо гілку для нашого проекту:

Перейдемо до нової гілки:

Тепер створимо новий файл в гілці new-feature з іменем test, додамо його в гілку та зробимо комміт:

Тепер порівняємо зміст гілки з основною.

На даному етапі ми мали б зробити попереднє подолання конфліктів, однак оскільки таких намеє то можна перейти до основної гілки та зробити злиття гілок:

Ну тепер можна подивитись лог змін:

Так ми отримаэмо лог змін з кольоровою підсвіткою.

Крок третій

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

Успіхів у використанні Git. Сподіваюсь він Вам сподобається не менше ніж мені. Та звичайно ж дякую всім за увагу!