Що означає "розгалуження безкоштовне" в Git?

Що означає "розгалуження безкоштовне" в Git?

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

У мене не було можливості (?) Спілкуватися з іншими ( SVN тощо), тож як розгалуження "дорого" у інших?

Твердження, що "розгалуження є вільним у git", - це спрощення фактів, оскільки воно не є "вільним" як таке. Якщо ви шукаєте під кришкою, більш правильним є твердження, що розгалуження натомість дешево дешеве , оскільки гілки в основному посилаються на коміти . Я визначаю тут "дешевизну" як менший накладні витрати, тим дешевше.

Дозволяє розібратися, чому Git настільки "дешевий", вивчивши, які його накладні витрати:

Як реалізуються гілки в git?

Репозиторій git, в .gitосновному, складається з каталогів з файлами, що містять метадані, якими користується git. Щоразу, коли ви створюєте гілку в git, наприклад git branch {name_of_branch}, декілька речей:

• Посилання створюється на місцевому відділенні за адресою: .git/refs/heads/{name_of_branch}
• Журнал історії створюється для місцевого відділення за адресою: .git/logs/refs/heads/{name_of_branch}

В основному це, створено пару текстових файлів. Якщо ви відкриєте посилання у текстовому файлі, вміст буде ідентифікатором комісії, на яку вказує гілка. Зауважте, що розгалуження не вимагає від вас жодних комісій, оскільки вони є іншим типом об'єктів. І гілки, і комітети є "першокласними громадянами" в git, і один із способів - думати про взаємозв'язок між гілкою та зобов'язаннями як сукупність, а не як склад. Якщо ви видалите гілку, коміти все ще існуватимуть як "звисаючі". Якщо ви випадково видалили гілку, ви завжди можете спробувати знайти фіксацію з git-lost-foundабо git-fsck --lost-foundстворити гілку на ша-ід, який ви вважаєте, що висіло (і доки git ще не зробив жодного збору сміття).

То як Git відстежує, над якою галуззю ви працюєте? Відповідь - .git/HEADфайл, який виглядає приблизно так, якщо ви на masterгілці.

ref: refs/heads/master

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

Як це порівнюється в інших системах управління версіями?

У Subversion гілки - це віртуальні каталоги в сховищі . Тож найпростіший спосіб відгалуження - це зробити віддалено, однолінійним svn copy {trunk-url} {branch-url} -m "Branched it!". Що буде робити SVN:

• Скопіюйте вихідний каталог, наприклад trunk, у цільовий каталог,
• Введіть зміни для завершення дії з копіювання.

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

Команда для перемикання гілок у SVN , тобто svn switchнасправді є svn updateмаскуванням. Завдяки концепції віртуальної директорії команда є трохи гнучкішою у svn, ніж у git. Підкаталоги у вашій робочій області можна вимкнути, щоб відобразити іншу URL-адресу сховища. Найближчим із них буде використання, git-submoduleале використання цього семантично сильно відрізняється від розгалуження. На жаль, це також дизайнерське рішення, яке робить перемикання трохи повільнішим у SVN, ніж у Git, оскільки воно має перевіряти кожен каталог робочої області, у якому віддаленому URL-адресі воно відображається. На мій досвід, Git швидше перемикає гілки, ніж SVN.

Розгалуження SVN коштує, оскільки він копіює файли і завжди повинен бути доступним для загального доступу. Як описано вище, гіти є "лише посиланнями" і можуть зберігатися у вашому локальному сховищі та публікуватися на ваш розсуд. На мій досвід, проте, SVN все ще надзвичайно дешевший і ефективніший, ніж, наприклад, ClearCase.

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

Як інший приклад, у Mercurial розгалуження почалося дещо інакше як DVCS та створення / знищення названих гілок, необхідних окремих комітетів. Пізніше розробники Mercurial впровадили закладки розробки, щоб імітувати ту саму модель розгалуження git, хоча headsвони називаються tipsі замість цього branchesзнаходяться bookmarksв термінології mercurial.

Реальна вартість філії - це її злиття. Git робить це простіше, ніж деякі інші системи управління джерелами. Див. Запитання про переповнення стека. Як і / або чому злиття в Git краще, ніж у SVN? .

У Git філія є лише посиланням на зобов'язання місцевого репо. Створити це дуже дешево, взагалі немає мережі. Не зовсім вільний (ти маєш набрати команду), але чортів поруч.

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

У поважних CVS, з іншого боку, розгалуження ДУЖЕ дороге. В основному, гілки CVS передбачають додавання тегу, але в CVS це означає, що ВСІЙ ФАЙЛ ВПЛИВ має бути змінений. Кожен файл перезаписується для включення нового тегу. Це жахливо дорого. І якщо ваше сховище велике, воно також жахливо повільне. Насправді, якщо ви працюєте на великому проекті, це досить повільно, що деякі люди прагнуть уникати створення гілок, якщо можуть.

Розгалуження SVN таке ж вільне, як і Git. Це лише трохи даних ведення господарства, які говорять, де починається відділення, ніяких змін у збережених файлах. "Копія" у SVN - це як додавання символьного посилання до каталогу Unix. Зауважте, що відділення SVN не потребуватиме мережевої поїздки, поки ви не зробите зміни в робочій копії (але не дуже важливо мати SCM, якщо ви не вчинили місцеве місце в якийсь момент).

Зауважте, що гілка Git також передбачає деяке ведення господарства - наприклад, додавання цього тегу всередину - яке доведеться зберігати десь під час здійснення зобов’язань. Це взагалі не велика справа, саме тому її називають "вільною".

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

Гілки git, по суті, є мітками, які вказують на коміт і таким чином уникають вищезазначених питань.

Інший аспект "вільного / дешевого / дорогого" - це пов'язане з тим, скільки коштують кошти з точки зору ресурсів розробника для подолання наслідків розгалуження вниз за течією; тобто процес злиття змін із гілок.

І тут об’єднувати гілки в таких системах DVCS, як Git і Mercurial, простіше, ніж у старих системах ... тому що системи DVCS виконують набагато кращу роботу щодо відстеження історії графіків на графіку; тобто там, де відбулося попереднє розгалуження об'єднання. Це робить злиття більш точними, зменшує непотрібні конфлікти і ... робить об’єднання суб'єктивно "простішим" або "менш страшним" для залучених розробників.