Система контролю версій – яка краща? Система контролю версій git, svn та інші, порівняння. Що таке

Усі ви знаєте систему Git. Хоча б чули – це напевно. Розробники, які користуються системою, її або люблять, або лають за складний інтерфейс та баги. Система управління версіями Git де-факто є стандартом у промисловості. Розробник може мати думки про переваги Mercurial, але найчастіше доводиться миритися з вимогою вміти користуватися Git. Як у будь-якої складної системи, у неї безліч корисних і необхідних функцій. Однак, до геніальної простоти дістаються не всі, тому існуюча реалізація залишала простір для вдосконалення.

Простими словами - хитромудрим додатком було важко користуватися. Тому в лабораторії Масачусетського Технологічного Інституту взялися за покращення та відсікли всі «проблемні елементи» (адже те, що для одного проблема, для іншого легко може бути перевагою). Поліпшену та спрощену версію назвали Gitless. Її розробляли з урахуванням 2400 питань, пов'язаних з Git та взятих із сайту розробників StackOverflow.

Що не так з Git

приклад

Більшість користувачів Git застосовують його для невеликої кількості команд, а одиниці, що залишилися, знають платформу на більш глибокому рівні. Виходить, що в основному платформа потрібна для базових функцій, А великий пласт можливостей залишається для вузького кола. Це говорить про неправильну роботу Git.

Коротке порівняння базових функцій із попередньою версією

Функція stashing ховає чорнову роботу в робочому каталозі - файли, що відстежуються, які були змінені і зберігає все в стек із незавершеними змінами. Усі зміни можна застосувати пізніше, коли буде зручно. Це потрібно, коли ви працюєте в одній гілці і в ній все в безладному стані, а потрібно терміново перейти на іншу гілку. Ви не хочете вивантажувати код із частково зробленою роботою в першій гілці на час паузи.

Функція staging індексує зміни, внесені у файл. Якщо ви помітили файли staged, Git розуміє, що ви підготували їх до розвантаження.

У Gitless немає концепції stashing. Уявіть таку ситуацію. Ви перебуваєте в розпалі розробки проекту і повинні перейти в іншу його гілку, але ви ще не вивантажили в систему свою наполовину виконану роботу. Функція stashing бере зроблені вами зміни та зберігає їх у стек із незакінченими змінами, які ви можете відновити пізніше.

Автор посібника з Gitless повідомляє, що проблема з'являється при перемиканні між гілками. Може бути складно запам'ятовувати який з stashes де знаходиться. Та й вершиною всього цього стало те, що функція не допомагає у випадку коли ви в процесі мерджу, що включає конфліктні файли. Така думка Переза ​​де Россо.

Завдяки Gitless ця проблема вирішується. Гілки стали повністю автономними по відношенню одна до одної. Це робить роботу набагато простіше і дозволяє розробникам уникати плутанини, коли потрібно постійно перемикатися між завданнями.

Збереження змін

Крім цього, ви можете змінити класифікацію будь-якого файлу на значення: відстежуваний, не відстежуваний або ігнорований. Не має значення, існує цей файл у заголовку чи ні.

Розгалуження процесів розробки

Простіше кажучи, у версії Gitless вам не потрібно пам'ятати про незавантажені в систему зміни, які перебувають у конфлікті зі змінами у гілці призначення.

Також ви зможете відкласти вирішення конфліктної ситуації, якщо у вас є середина мержда або fuse. Конфлікт залишиться доки ви не перемкнетеся назад.

Робота з віддаленими репозиторіями

Ще одна перевага нової версії – можливість перемикатися до старої без втрати коду. При цьому ваші колеги можуть бути навіть не в курсі того, що ви користуєтеся іншим ПЗ.

Посібник з роботи з Gitless ви можете вивчити на офіційному сайті програми. У документації описано таке: як створювати репозиторій, зберігати зміни; як працювати з гілками; як користуватися тэгами, працювати з віддаленими репозиторіями.

Що в результаті

Проект використовував суворі методи створення програмного забезпечення. Це необхідно для відокремлення недоліків в одному з найбільш широко застосовуваних у всьому світі програмних проектів. У минулому безліч користувачів наводили смішні аргументи як за, так і проти Git, але вони не були засновані на науковому підході.

Під час роботи над проектом його учасники часто стикаються з проблемами синхронізації та ведення історії файлів, вирішити які допомагають системи керування версіями (СУВ). Мета цієї серії статей – познайомити читача з принципами роботи СУВ та докладно розглянути одну з них, а саме Git. Чому Git? У Останнім часомця система набирає популярності, і її важливість для вільного ПЗ (і для проекту GNU/Linux, зокрема) важко переоцінити.

Ми послідовно, в загальних рисах, Розберемо характеристики систем контролю, розповімо про їх архітектуру та основні особливості розглянутого додатка. Крім того, зробимо огляд існуючих інтерфейсів для роботи з Git.

Автор свідомо опускає термінологію функцій, ключів та інших тонкощів, щоб чітко, ясно та у загальному вигляді уявити вам картину. Ця стаття передбачає, що читач знайомий з Unix-подібними операційними системами (ОС), а також має базові знанняв галузі алгоритміки та інформатики в цілому.

У наступних матеріалах ми заглибимося в структуру та філософію Git, специфіку цієї системи та тонкощі практичної роботи з нею. Завершить цикл стаття про взаємодію Git з іншими СУВ (такими як Subversion, CVS, Mercurial та ін.).

2. Git – це...

Git – це розподілена система керування версіями файлів. Код програми написано в основному мовою С. Проект був створений Лінусом Торвальдсом у 2005 році для управління розробкою ядра Linuxі, як і GNU/Linux, є вільним програмним забезпеченням (ПЗ), при цьому стороннє використанняпідкоряється ліцензії GNU GPL версії 2. Коротко цю угоду можна охарактеризувати як програмне забезпечення з вільним кодом, яке має розвиватися відкрито, тобто. будь-який програміст має право продовжити вдосконалення проекту на будь-якому його етапі. За свій недовгий час існування дана системабула запроваджена багатьма провідними розробниками. Git використовується в таких відомих Linux-спільноті проектів, як Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Системи керування версіями

Системи керування версіями (Version Control Systems) – це програмне забезпечення, яке покликане автоматизувати роботу з історією файлу (або групи файлів), забезпечити моніторинг змін, синхронізацію даних та організувати захищене сховище проекту. Коротше кажучи, основне завдання систем управління версіями - спростити роботу з інформацією, що змінюється. Розберемо загальний виглядрозробки з прикладу.

Припустимо, є проект, який ви розробляєте, кілька відділів програмістів і ви – координатор (або керівник). По відношенню до системи контролю, чи то сервер (якщо йдеться про централізовану систему) чи локальна машина, будь-який розробник проекту обмежений лише правами доступу на зміну та/або читання версій файлів даного сховища. У будь-який момент ви можете зробити відкат даних до необхідної версії. Ви, як координатор, можете обмежити доступ певним користувачам оновлення версії файла. Також СУВ надає інтерфейс спостереження та пошуку версій файлів. Наприклад, можна створити запит: “Де і коли змінювався цей шматок коду?”.

Система передбачає захищене зберігання даних, тобто. будь-який блок, що зберігається в ній, має безліч клонів. Так, наприклад, при пошкодженні будь-якого файлу ви можете замінити його копією. Для зменшення обсягу даних проекту часто використовується дельта-компресія – такий вид зберігання, у якому зберігаються самі версії файлу, лише зміни між послідовними ревізіями.

4. Відмінності розподілених систем керування версіями

Розподілені системи управління версіями – це СУВ, головною парадигмою яких є локалізація даних кожного розробника проекту. Іншими словами, якщо в централізованих СУВ усі дії так чи інакше залежать від центрального об'єкта (сервер), то в розподілених СУВ кожен розробник зберігає власну гілка версій всього проекту. Зручність такої системи в тому, що кожен розробник може вести роботу незалежно, іноді обмінюючись проміжними варіантами файлів з іншими учасниками проекту. Розглянемо цю особливість, продовжуючи попередній приклад.

Кожен розробник на машині має свій локальний репозиторій – місце зберігання версій файлів. Робота з даними проекту реалізується над вашим локальним репозиторієм, і цього необов'язково підтримувати зв'язок з іншими (нехай навіть і головними) гілками розробки. Зв'язок з іншими репозиторіями знадобиться лише за зміни/читання версій файлів інших гілок. При цьому кожен учасник проекту ставить права власного сховища на читання та запис. Таким чином, усі гілки у розподілених СУВ рівні між собою, і головну з них виділяє координатор. Відмінність головної гілки лише в тому, що на неї подумки дорівнюватимуть розробники.

5. Основні можливості та особливості Git

Варто сказати, що система якщо і не викликала фурору, то трохи сколихнула співтовариство в області СУВ своєю новизною і запропонувала новий шлях розвитку. Git надає гнучкі та прості у використанні інструменти для ведення історії проекту.

Особливістю Git є те, що робота над версіями проекту може відбуватися не хронологічно. Розробка може вестись у кількох паралельних гілках, які можуть зливатися та розділятися у будь-який момент проектування.

Git – досить гнучка система, і область її застосування обмежується як сферою розробки. Наприклад, журналісти, автори технічної літератури, адміністратори, викладачі вузів цілком можуть використовувати її у своїй діяльності. До таких завдань можна віднести контроль версій документації, доповіді, домашніх завдань.

Виділимо основні відмінності Git від інших розподілених та централізованих СУВ.

Архітектура Git

SHA1 (Secure Hash Algorithm 1) – це алгоритм криптографічного хешування. Кожен файл вашого проекту в Git складається з імені та змісту. Ім'я – це перші 20 байтів даних, воно наочно записується сорока символами у шістнадцятковій системі числення. Цей ключ виходить хешуванням вмісту файлу. Так, наприклад, порівнявши два імені, ми можемо майже зі стовідсотковою ймовірністю сказати, що вони мають однаковий зміст. Також імена ідентичних об'єктів у різних гілках (репозиторіях) – однакові, що дозволяє безпосередньо оперувати даними. Хорошим доповненнямсказаному вище служить ще те, що хеш дозволяє точно визначити пошкодження файлів. Наприклад, порівнявши хеш вмісту з ім'ям, ми можемо точно сказати, пошкоджені дані чи ні. Далі під ім'ям ми розумітимемо ім'я файлу, а рядок символів називатимемо SHA1-хеш.

Варто згадати про так звані колізії. "Цілком точно визначити пошкодженість" означає, що існують такі файли, різні за змістом, SHA1-хеш яких збігається. Імовірність таких колізій дуже мала, і по попередньої оцінкидорівнює 2 -80-го ступеня (~ 10 -25-го ступеня). Точної оцінки немає, оскільки на Наразісвітовій спільноті не вдалося ефективно розшифрувати цю криптографічну схему.

Об'єкти Git

Роботу з версіями файлів у Git можна порівняти зі звичайними операціями над файлової системой. Структура складається з чотирьох типів об'єктів: Blob, Tree, Commit та References; деякі з них, своєю чергою, поділяються на подобъекты.

Blob (Binary Large Object) – тип даних, який містить лише вміст файлу і власний SHA1-хеш. Blob є основним та єдиним носієм даних у структурі Git. Можна провести паралель між даним об'єктом та інодами (inodes) у файлових системах, оскільки їх структура та цілі багато в чому схожі.

Дерево (Tree)

• власний SHA1-хеш;
• SHA1-хеш blob'ів та/або дерев;
• права доступу з Unix-систем;
• символьне ім'я об'єкта (назва для внутрішнього використанняв системі).

По суті об'єкт є аналогом директорії. Він визначає ієрархію файлів проекту.

Commit– тип даних, що містить:

• власний SHA1-хеш;
• посилання на одне дерево;
• посилання на попередній commit (їх може бути кілька);
• ім'я автора та час створення commit'у;
• ім'я комітера (commiter – людина, яка застосувала commit до репозиторію, вона може відрізнятися від автора) та час застосування commit'а;
• довільний шматок даних (блок можна використовувати для електронного підписуабо, наприклад, для пояснення змін commit'а).

Цей об'єкт покликаний зберігати знімок (версію) групи файлів у певний час, можна порівняти його з контрольною точкою. Commit'и можна об'єднувати (merge), розгалужувати (branch) або, наприклад, встановити лінійну структуру, відбиваючи тим самим ієрархію версій проекту.

Reference – тип даних, що містить посилання на будь-який із чотирьох об'єктів (Blob, Tree, Commit та References). Основна мета його – прямо чи опосередковано вказувати на об'єкт і бути синонімом файлу, який він посилається. Тим самим підвищується розуміння структури проекту. Дуже незручно оперувати безглуздим набором символів у назві, посилання ж, на відміну від SHA1-хеша, можна назвати так, як зручніше розробнику.

З посилань, своєю чергою, можна назвати ряд подобъектов, мають деякі відмінності: Гілка, Тег. Розглянемо їх.

Гілка (Head, Branch)– символьне посилання (Symbolic link), яке вказує на останній у хронології commit певної гілки та зберігає SHA1-хеш об'єкта. Є типом даних файлових систем, що журналуються. Даний вид об'єкта визначається не в самому Git, а успадковується від операційної та файлової систем. Гілка використовується як синонім файлу, який вона посилається, тобто. Git дозволяє оперувати нею безпосередньо. Можна дозволити собі не замислюватися про те, чи працюєте ви з останньою версієючи ні.

Тег (tag)- тип даних, який на відміну від гілок незмінно посилається на той самий об'єкт типу blob, tree, commit або tag. Його, у свою чергу, можна розділити на легковажний (light tag) та великоваговий або анотований (annotated tag). Легкий тег, крім незмінності посилання, нічим відрізняється від звичайних гілок, тобто. містить лише SHA1-хеш об'єкта, на який посилається, усередині себе. Анотований тег складається з двох частин:

• перша частина містить власний SHA1-хеш;
• друга частина складається з:
  • SHA1 об'єкта, на який вказує анотований тег;
  • тип об'єкта, що вказується (blob, tree, commit або tag);
  • символьне ім'я тега;
  • дата та час створення тега;
  • ім'я та e-mail творця тега;
  • довільний шматок даних (цей блок можна використовувати для електронного підпису або для пояснення тега).

Іншими словами, проект у Git є набором blob'ів, які пов'язані мережею дерев. Отримана ієрархічна структура може, залежно від часу, бути відображена у вигляді commit'ів – версій, а для розуміння їхньої структури в Git є такі об'єкти, як посилання. Виключаючи дії з посиланнями, майже всю роботу з об'єктами системи максимально автоматизовано зсередини. Відштовхуючись від механізму посилань, ми приходимо до наступної ідеї працювати саме над групами файлів. На думку автора, думка є ключовою у філософії Git. Задавши, наприклад, операцію для даного commit'у, вона рекурсивно відпрацює свою частину по дереву, на яке посилається. Як розширення загальноприйнятого погляду “дія над кожним файлом”, нововведення спрощує реалізацію і підхід з боку програміста над повсякденними завданнями СУВ, такими як злиття/поділ гілок, знову ж таки рекурсивно автоматизуючи процес. Даний підхід простий для розуміння, швидко працює і гнучкий у реалізації своїх цілей. Багато з цих характеристик досягаються завдяки Unix-орієнтованості системи, тобто. оперуючи стандартними пристроями, Git спирається на вже наявні в операційній системі рішення.

Проясним момент зберігання даних. Зміст файлів різних версійу хронології займає чимало пам'яті. Так, наприклад, у проекті з двадцяти файлів двадцяти версій архів важитиме в 20 разів більше (можливо, близько сотні мегабайтів), а що буде, якщо кількість і тих та інших у 10 разів більша (начебто б не набагато)? Розмір зайнятого простору зросте у 100 разів (тобто приблизно 1 ГБ). У реальних задачахшвидкість зростання пам'яті далеко не лінійно залежить від часу. Для вирішення цієї проблеми існує кілька оптимізацій:

• кожен об'єкт Git зберігається як звичайного архіву (tar.gz);
• для всієї ієрархії файлів використовується послідовна дельта-компресія.

Розберемо з прикладу.

У вас є трирічна історія вашого проекту, в ній близько тисячі файлів та ста версій. Якщо у певний момент потрібно буде звернутися до самої ранньої версії, Git доведеться розархівувати дельта-компресію всієї історії файлу. Невтішно, але цей процес може піти до полудня. Git пропонує робити звані контрольні точки, тобто. зберігати тиждень-архівований файл через кілька версій, яке назвемо глибиною компресії. Тоді в нашому прикладі вся історія звужується до деякої наперед заданої кількості дельта-компресій, розархівувавши які можна поглянути на будь-яку версію в хронології. Зауважимо, що дельта-компресію найбільш доцільно використовувати над одними видами найближчих об'єктів в ієрархії, для цього репозиторій необхідно відсортувати відповідно за типом і розміром. Цей ряд операцій, описаних у цьому пункті, виконує функція git-repack (і git-gc, що її містить).

Злиття та поділ гілок

Це дуже трудомісткий і насичений, у зв'язку з чим введемо поняття злиття і поділу лише у загальних рисах. Знову звернемося, наприклад.

Уявімо момент розробки проекту, коли головною метою є швидкість роботи програми. Один із можливих тактичних варіантів рішення – розбити розробників на дві групи, кожна з яких вирішуватиме одне й те саме завдання. При цьому гілка історії проекту має роздвоїтися. Ця процедура називається розгалуження (branch). Дія розгалуження гілки – це просте створення її копії, яка згодом матиме свою історію.

Нехай ми отримали два вже закінчені результати одного і того ж завдання, над яким працювали дві групи програмістів. Як нам бути? Подивитися, чий код швидше та надійніше? Це надто просто, але не завжди найкращий вихід. Хороше рішення– це, трохи розібравшись у коді та файлах, розбити їх на підзавдання чи блоки коду. І тільки тоді вже виявляти сильні та слабкі сторониданих шматочків. Звичайно, цей варіант підходить тільки в тому випадку, коли ви передбачили, що згодом зможете зібрати всі ці частинки воєдино. Випадок, коли ви самі розробляєте код, покращуючи та виправляючи деякі помилки, рівнозначний наведеному прикладу. Цей процесоб'єднання двох цілих одне називається злиття (merge). Процес об'єднання двох версій є ключовим моментом ведення проекту. Як би там не було, варто уникати автоматизованого виконання цієї операції. Відмінна риса Git – це максимально достовірний та досить швидкий спосіброзв'язання задачі розгалуження.

До переваг системи можна віднести:

1. Unix-орієнтованість.
2. Ідеологічна витриманість (дотримуючись правил використання системи, дуже складно потрапити в безвихідь або отримати те, чого ви не очікували).
3. Висока продуктивність (це одна з найбільш явних переваг системи, плата за яку є «Ідеологічна витриманість» і «Unix-орієнтованість»).
4. Інтеграція Git зі сторонніми СУВ, такими як Subversion, Mercurial, …
5. Керування групою файлів (системі немає необхідності розглядати зміни в кожному файлі окремо, вона запам'ятовує будь-які зміни всього проекту, і якщо раптом вам знадобиться простежити поодинокі зміни, вона видасть ту частину, яка пов'язана з даним файлом).
6. Операція злиття (максимально автоматизована реалізація складного завдання).

До недоліків віднесемо:

1. Unix-орієнтованість (варто відзначити відсутність зрілої реалізації Git на Unix-системах).
2. Необхідність періодичного виконання команди git-gc (пакує групи файлів та видаляє ті, які не пов'язані посиланнями).
3. Колізії хешування (збіг SHA1 хеша різних за змістом файлів).

6. Інтерфейси Git

"Скільки людей стільки й думок". Спробуємо виділити низку типів інтерфейсів до роботи з системою. Для певних цілей по-своєму краще кожен із наведених нижче видів додатків.

Для людей, які не займаються розробкою впритул, для «консерваторів» – тих, хто любить “кнопочки та галочки” і свідомо хоче захистити себе від надмірних зусиль запам'ятовування функцій, ключів та багатьох тонкощів, більше підійде варіант у стилі TortoiseGit або Git Extensions – прості інтерфейсів. Вони дозволяють діяти переважно мишею та працюють у звичній для багатьох ОС Windows.

Рівно протилежний тип інтерфейсу. Для програмістів, яким постійно необхідно взаємодіяти зі співробітниками, вирішувати типові завдання контролю саме коду, для людей, які звикли працювати в Unix-like системах, використовуючи термінал, найкраще підійде консольний вид програм. Вони так само прості в користуванні, трохи швидше і функціональніше, але їм доведеться приділити час, щоб розібратися у використанні.

Можна виділити і третій тип інтерфейсів - змішання перших двох. Тобто. у вас є консольна програма, наприклад, “рідна” оболонка git. Ви можете використовувати додаткові утиліти, такі як Gitk або QGit, для відображення дерев, спрощення огляду ієрархії версій, відмінностей між версіями, пошуку потрібних об'єктів.

7. Висновок

Отже, читачі вже уявляють собі, як працюють сучасні системиконтролю версій Крім того, нами було розглянуто архітектуру однієї з найпопулярніших систем – Git. У наступній статті ми спробуємо на практиці познайомитись з деякими її особливостями – розглянемо функції та ключі до них. У статті буде надано ряд наочних прикладів ведення історії файлів, а також викладено філософію розподілених систем. Автор спробує показати читачам, як можна правильно використовувати Git та розгляне деякі типові помилкивикористання цієї СУВ.

Знадобилося мені нещодавно навчити азам Git кількох моїх співробітників, які тільки вивчають програмування та намагаються працювати. Пошукавши в інтернеті статті для новачків, я зіткнувся з тим, що більшість з них про те, як використовувати консольний Git або про його необхідність і перевагу перед іншими подібними системами. Новачок зазвичай не дуже сильний у всіх цих справах. Я вважаю, що йому для початку і знати це все не обов'язково. Адже можна використовувати Git для своїх проектів і вчитися всій його красі паралельно з вивченням програмування. Але,рекомендую сприймати цю статтю як ознайомлювальну і в майбутньому вивчити Git докладніше.

Загалом, під катом стаття, як використовуючи SmartGit та BitBucket можна поліпшити своє життя розробника-початківця.

М аленький план того, що ми робитимемо:

1. Створення репозиторію на Bitbucket.
2. Клонування репозиторію (додавання його до SmartGit).
3. Створення комітів.
4. Скасування змін.
5. Створення гілок.
6. Проштовхування гілок на дистанційний репозиторій (аплоад гілок на віддалений сервер).
7. Злиття гілок.

Поїхали. Створення репозиторію дуже просте завдання. Ми будемо для цього користуватися BitBucket, тому вам потрібно мати там обліковий запис. Після реєстрації тиснемо кнопку Create і заповнюємо необхідні поля. Схиляємо репозиторій за допомогою SmartGit. Візьмемо посилання на наш репозиторій.

Тепер запустимо SmartGit, виберемо "Project" - "Clone" (або Ctrl + Alt + O) і заповнимо необхідні поля:

Система запросить ваш логін та пароль від Bitbucket:

У наступному вікні доступні дві опції клонування "Include Submodules" та "Fetch all Heads and Tags". Git дозволяє окремі модулі програми зберігати у різних репозиторіях. Якщо ви позначите опцію "Include Submodules" - SmartGit автоматично підвантажить усі модулі. Якщо відзначити опцію "Fetch all Heads and Tags", то SmartGit після створення папки проекту скачає всі гілки та теги для даного репозиторію:

Наступне вікно - ім'я проекту SmartGit:

Якщо ви клонували порожній репозиторій(як у цій статті), побачите наступне вікно:

Йдемо далі. Створимо коміт. Що таке коміт? Це фіксація змін. Кожен коміт «запам'ятовує», що саме ви змінили і в будь-який момент часу можна повернути колишній стан файлів. Раджу вам після кожної значущої зміни, наприклад, виправлення бага у функції, робити коміт. Щоб створити коміт, потрібно щось змінити в проекті. Додайте кілька файлів у папку з проектом:

Тепер можна побачити зміни нашого проекту у SmartGit:

Виберемо обидва файли і натиснемо спочатку "Stage", а потім "Commit". Навіщо потрібно натискати Stage? Кнопка «Stage» додає до поточного індексу вибрані файли. Якщо ви хочете створити коміт для двох файлів, а змінили, припустимо цілих 5, достатньо вибрати ці два файли, натиснути "Stage", що додасть їх до індексу, а після "Commit". Таким чином, лише вибрані два файли потраплять у коміт.

Після чого з'явиться віконце, де потрібно буде запровадити коментар коміту. Зазвичай туди пишуть те, що було змінено, додано, видалено тощо:

Після цього слід натиснути кнопку «Commit». Кнопка «Commit & Push» робить те саме, але ще й проштовхує (заливає) зміни у віддалений репозиторій (у нашому випадку це Bitbucket). Поки що не варто цього робити. Проштовхуванням ми займемося далі. Внизу, у списку гілок, з'явиться локальна гілка"master". Це основна гілка коду програми. Що таке гілки, розповім трохи пізніше. А зараз зробимо щось із нашим проектом, а потім відкотимо зміни. Я видалю файл readme.txt, відредагую файл index.php і додам новий файл confic.cfg:

А тепер відкотимо зміну після коміту. Зайдемо в Log:

Виберемо коміт, до якого хочемо відкотитись і натиснемо «Reset»:

У наступному вікні нам пропонують вибрати який саме "Reset" ми хочемо зробити:

Поясню. Згадайте, що при створенні коміта, ви спочатку додаєте файли до індексу (stage). Це дозволяє закомітити лише проіндексовані файли. Soft reset скидає лише коміти. Індекс та фізичні зміни у файлах залишаються. Mixed reset працює так само, як і програма, але ще видаляє індекс файлів. Hard reset видаляє коміти, індекс та фізичні зміни у файлах. Акуратно використовуйте hard resetщо ненароком не видалити зайвого.

Я зробив hard reset для наочності:

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

Тепер трохи про створення гілок. Навіщо вони взагалі потрібні? Гілка дозволяє зберегти поточний станкоду, та експериментувати. Наприклад, ви пишете новий модуль. Логічно робити це в окремій гілці. Дзвонить начальство і каже, що в проекті баг і терміново потрібно пофіксувати, а модуль не дописаний. Як заливати неробочі файли? Просто перейдіть на робочу гілку без модуля, пофіксуйте баг і заливайте файли на сервер. А коли «небезпека» минула – продовжіть роботу над модулем. І це один із багатьох прикладів користі гілок.

Спробуємо створити свою гілку. У нас вже є одна, це master. Вона створюється автоматично (якщо відсутня) коли ви робите перший коміт. Створимо ще одну гілку та назвемо її «new_future1». Натисніть F7 або правим кліком внизу у вкладці «Branches» на напис «Local Branches» і у списку виберіть «Add branch»:

Натисніть «Add branch & Switch» щоб відразу перейти на створену гілку. Тепер ви можете створювати нові коміти, змінювати файли та не турбуватися. Так як у вас завжди є гілка майстер, до якої можна повернутися. Коли ви перемикаєте гілку, Git змінює локальні файли на ті, які є в гілці. Тобто, якщо ви створите нову гілку, поміняєте щось у файлі index.php, а потім перейдіть на гілку master, то всі зміни, зроблені вами будуть видалені. Якщо ж перейти назад у створену гілку - зміни повернуться.

Досі ми працювали локально. Спробуємо залити працю нашої роботи на сервер. Створимо якийсь коміт у гілці new_future1. Якщо репозитарій порожній, а він порожній, тому що ми створили його деякий час тому і на сервер нічого не залили, Bitbucket основний призначає ту гілку, яку залили першою. Тому перейдемо на гілку «master» і натиснемо кнопку «Push»:

Далі SmartGit запитає чи налаштувати відстеження гілки (cofigure tracking). Відстеження дозволяє автоматично оновлювати відповідні гілки, коли ви завантажуєте або завантажуєте оновлення коду. Тому сміливо тисніть "Configure":

Тепер перейдіть на іншу гілку і проробіть те саме. Зайдемо на Bitbucket і подивимося, що змінилося в розділі Commits:

Як бачите, все потрапило на віддалений сервер.

Тепер зіллємо гілки. Навіщо це потрібно? Візьмемо той самий приклад із модулем. Рано чи пізно ви допишіть його і вам потрібно буде додати код модуля до основного коду програми. Достатньо просто злити гілки. Для цього перейдіть на гілку, в яку хочете злити код. У нашому випадку це майстер. Після чого натисніть правим кліком на гілку, з якою хочете злити код і виберіть "Merge":

А тепер залишилося проштовхнути зміни гілки master на сервер. Заливаємо зміну на сервер так само, як ми робили це раніше, і отримуємо:

Ось і все цього разу. Через картинки стаття вийшла великою. Ставте свої відповіді. Пишіть запитання.

Цей розділ про те, як почати роботу з Git. Спочатку вивчимо основи систем контролю версій, потім перейдемо до того як запустити Git на вашій ОС і остаточно налаштувати для роботи. Наприкінці розділу ви вже знатимете, що таке Git і чому їм слід користуватися, а також отримаєте остаточно налаштовану для роботи систему.

Про систему контролю версій

Що таке "система контролю версій" і чому це важливо? Система контролю версій - це система, яка записує зміни у файл або набір файлів протягом часу і дозволяє повернутися пізніше до певної версії. Для контролю версій файлів у цій книзі як приклад використовуватиметься вихідний кодпрограмного забезпечення, хоча насправді можна використовувати контроль версій практично для будь-яких типів файлів.

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

Локальні системи контролю версій

Багато людей як метод контролю версій застосовують копіювання файлів в окрему директорію (можливо навіть директорію з позначкою за часом, якщо вони досить кмітливі). Даний підхід дуже поширений через його простоту, проте він неймовірно сильно схильний до появи помилок. Можна легко забути, в якій директорії ви знаходитесь, і випадково змінити той файл або скопіювати не ті файли, які ви хотіли.

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

Figure 1. Локальний контрольверсій.

Однією з найпопулярніших ВКВ була система RCS, яка і сьогодні поширюється з багатьма комп'ютерами. Навіть популярна операційна система Mac OS X надає команду rcs після встановлення Developer Tools. RCS зберігає на диску набори патчів (відмінностей між файлами) у спеціальному форматі, застосовуючи які вона може відтворювати стан кожного файлу в певний час.

Централізовані системи контролю версій

Наступна серйозна проблема, з якою стикаються люди, - необхідність взаємодіяти з іншими розробниками. Для того щоб розібратися з нею, були розроблені централізовані системи контролю версій (ЦСКВ). Такі системи, як: CVS, Subversion і Perforce, мають єдиний сервер, що містить всі версії файлів, і кілька клієнтів, які отримують файли з цього централізованого сховища. Застосування ЦСКВ було стандартом протягом багатьох років.

2. Централізований контроль версій.

Такий підхід має безліч переваг, особливо перед локальними ВКВ. Наприклад, усі розробники проекту певною мірою знають, чим займається кожен із них. Адміністратори мають повний контроль над тим, хто і що може робити і набагато простіше адмініструвати ЦСКВ, ніж оперувати локальними базами даних на кожному клієнті.

Незважаючи на це, цей підхід теж має серйозні мінуси. Найочевидніший мінус - це єдина точка відмови, представлена ​​централізованим сервером. Якщо цей сервер вийде з ладу на годину, протягом цього часу ніхто не зможе використовувати контроль версій для збереження змін, над якими він працює, а також ніхто не зможе обмінюватися цими змінами з іншими розробниками. Якщо жорсткий диск, На якому зберігається центральна БД, пошкоджений, а своєчасні бекапи відсутні, ви втратите все - всю історію проекту, крім одиничних знімків репозиторію, які збереглися на локальних машинах розробників. Локальні ВКВ страждають від тієї ж проблеми - коли вся історія проекту зберігається в одному місці, ви ризикуєте втратити все.

Децентралізовані системи контролю версій

Тут у гру вступають децентралізовані системи контролю версій (ДСКВ). У ДСКВ (таких як Git, Mercurial, Bazaar або Darcs), клієнти не просто завантажують знімок усіх файлів (стан файлів на певний момент часу): вони повністю копіюють репозиторій. У цьому випадку, якщо один із серверів, через який розробники обмінювалися даними, помре, будь-який репозиторій клієнта може бути скопійований на інший сервер для продовження роботи. Кожна копія репозиторію є повним бекапом всіх даних.

3. Децентралізований контроль версій.

Більше того, багато ДСКВ можуть одночасно взаємодіяти з кількома віддаленими репозиторіями, завдяки цьому ви можете працювати з різними групами людей, застосовуючи різні підходи одночасно в рамках одного проекту. Це дозволяє застосовувати відразу кілька підходів у розробці, наприклад, ієрархічні моделі, що неможливо в централізованих системах.

Бажаєте працювати над командними проектами з ІТ-розробки вдвічі швидше? Пройдіть наш новий авторський курс та навчитеся використовувати всі переваги Git!

Git – розподілена система керування версіями (VCS). Це універсальний, вільний і зручний інструментдля командної роботипрограмістів над проектами будь-якого рівня. Git дозволяє кільком розробникам працювати одночасно над своїми підзадачами, створюючи рівноправні гілки. При цьому кожне збереження (комміт) у Git не перезаписує попереднє, і будь-якої миті Ви зможете повернутися до вихідної версії коду.

Саме тому мільйони програмістів використовують Git у своїй роботі щодня. Git полегшує життя розробникам мобільних додатків, комп'ютерних ігор, СПО, веб-програмістам. Git підкорив ІТ-світ надійністю, високою продуктивністю, зручністю роботи з гілками та незалежністю від сервера.

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

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

Пройдіть цей унікальний курс - і будь-який Ваш командний проект з ІТ-розробки буде ефективним!