Вибачте, якщо це дублікат, я подивився.
Ми рухаємось до Git. У програмі Subversion я звик мати папки \ trunk, \ гілки та \ теги.
Що стосується Git, перемикання між гілками замінить вміст робочого каталогу, тому я маю рацію припустити, що спосіб, з яким ми працювали, просто не застосовується до Git?
Я здогадуюсь, що я мав би папку repo з можливо gitignore та readme.txt, потім папки для проектів, які складають репо, і все.
Відповіді:
У вас буде "стовбур", тепер його називають "майстер", у вас будуть "гілки", які зараз називаються "голови", і у вас будуть "теги", які ще називаються "тегами", але вони не будуть папками , вони будуть " refs ", мітки на версії, що живуть в окремому просторі імен всередині сховища.
Subversion і Git мають різні способи розгалуження. Основна модель підривної роботи - мати дерево каталогів з єдиною глобальною шкалою часу, і якщо ви хочете розгалужити, ви скопіюєте піддерево в інший каталог.
З іншого боку, Git має дерево каталогів з редакціями, які визначають батьки, але кожна редакція може мати декількох батьків (злиття) та декількох дітей (гілок). Тож замість того, щоб мати каталоги для галузей, ви отримуєте самостійно створені версії. "Refs" - це лише імена, пов'язані з останньою редакцією для даної "гілки".
Ця різниця є основоположною для управління розподіленими версіями. Git (та інші розподілені системи) не мають жодного центрального повноваження зберігати історію лінійно, тому редакції можна створювати незалежно у кількох сховищах, не знаючи один про одного, і система повинна їх вмістити. Виявляється, узагальнення набагато полегшує розгалуження та злиття.
Зауважте, що в Git, редагування не є жодною гілкою. Вони просто є і гілки містять їх. Але як тільки гілка об’єднана або виявиться мертвою алеєю, ви можете просто видалити "ref", що вказує на неї, і зовсім забути про неї (якщо ви відмовитесь від старих випробувань, з часом вони будуть зібрані сміттям git gc). Це допомагає вам не завалитися в старих експериментах, і ніхто більше не пам’ятає, про що вони йшли.
Просто подумайте про Git як на 3D-вигляд тих самих даних, які ви бачите у 2D у SVN - тобто за допомогою SVN ви розгалужуєте свій корінь, і він виглядає як копія, показана як нова папка у дереві. Коли ви розгалужуєте Git, він відображається як копія, показана як "шар" на вершині вашого існуючого дерева. Після того як ви зрозумієте, що досить просто зрозуміти різницю.
З SVN ви все ще можете працювати так само, як і Git - перемикання між гілками замінить єдиний вид кодової бази розгалуженим видом, це стосується того, чи використовуєте ви комутатор svn або git checkout.
Очевидно, ви можете отримати копію гілки в SVN, перевіривши гілку до її папки, що є тим же, що клонують git repo в інше місце на вашому диску.
Те ж стосується тегів - ви можете позначати версію git або ви можете зробити гілку для випуску. SVN-теги такі ж, як і гілки, єдина умова, що їх називають "тегами". Ви можете мітити (добре записати номер редакції) репортажу SVN, щоб отримати також знімок релізу.
Відмінності між git та svn більше пов'язані з тим, як відбуваються реєстрація та реєстрація, а не з основами контролю джерел. Перегляд коду може бути різним (ви ніколи не побачите єдиного виду дерева коду, що включає гілки в git, і ви можете розгалужувати часткове сховище у SVN, але це, зрештою, незначні відмінності)