Для чого я буду використовувати git-worktree?

Я читав пост Гітхуба на git-worktree . Вони пишуть:

Припустимо, ви працюєте в сховищі Git у відділенні під назвою feature, коли користувач повідомляє про помилку з високою терміновістю master. Спочатку ви створюєте пов’язане робоче дерево з новою гілкою, hotfixперевіряєте відносно головного […] Ви можете виправити помилку, натиснути виправлення та створити запит на витяг.

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

З іншого боку, використання git-worktree має свої обмеження:

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

Чому я вибрав би складніший робочий процес для вирішеної проблеми?

Чи щось із git-worktreeцього не можна було зробити заздалегідь, що виправдовує всю цю нову складну особливість?

Для мене git worktree - найбільше вдосконалення з давніх часів. Я працюю в розробці програмного забезпечення для підприємств. Там дуже часто трапляються такі версії, як те, що випустили 3 роки тому. Звичайно, у вас є відділення для кожної версії, щоб ви могли легко перейти до неї та виправити помилку. Однак перемикання коштує дорого, тому що ви тим часом повністю реструктурували сховище і, можливо, побудували систему. Якщо ви перемкнетесь, ваш IDE буде з розуму намагатися адаптувати налаштування проекту.

За допомогою робочого дерева ви можете уникнути цієї постійної конфігурації. Перевірте ці старі гілки в окремих папках за допомогою робочого дерева. Для кожної філії ви отримали незалежний проект IDE.

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

Я можу побачити для цього використання.

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

Тому git-worktreeя міг би створити другу ідею для іншої галузі, яка там працює.

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

Третім випадком використання буде порівняння файлів за допомогою інших інструментів, ніж git-diff, як звичайно diff, між двома каталогами, а не двома гілками.

Одне очевидне використання - одночасне порівняння поведінки (не джерела) різних версій - наприклад, різних версій веб-сайту або просто веб-сторінки.

Я спробував це локально.

• створити каталог page1.

• всередині створити каталог srcі git initце.

• в srcстворенні page1.htmlз невеликим вмістом і його фіксації.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• в srcмайстер додайте більше тексту page1.htmlі введіть його.

• $ git branch sty1

• відредагуйте page1.htmlу sty1гілці (додайте якийсь характерний стиль CSS) та додайте її.

• $ git worktree add ../S1 sty1

Тепер ви можете використовувати веб-браузер, щоб одночасно відкривати та переглядати ці 3 версії:

• ..\page1\src\page1.html // що б git не було поточним

• ..\page1\V0\page1.html // початкова версія

• ..\page1\S1\page1.html // експериментально стильова версія

1. Є законні причини, через які ви можете бажати / потребувати декількох робочих місць у файловій системі одночасно.

   • маніпулювання перевіреними файлами при необхідності внесення змін десь в іншому місці (наприклад, компілювання / тестування)

   • розмежування файлів за допомогою звичайних інструментів різниці

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

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

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

2. Деякі люди запитують "чому б не зробити кілька локальних клонів". Це правда, що з "- локальним" прапором вам не доведеться турбуватися про додаткове використання місця на диску. Це (або подібні ідеї), що я зробив до цього моменту. Функціональними перевагами пов'язаних робочих груп над локальними клонами є:

   1. З місцевими клонами ваші додаткові робочі місця (які є в локальних клонах) просто не мають доступу до походження або гілок вище за течією. "Походження" в клоні не буде таким самим, як "походження" у першому клоні.

      • Біг git log @{u}..або git diff origin/feature/other-featureможе бути дуже корисним, і це або неможливо більше, або складніше. Ці ідеї технічно можливі з локальними клонами за допомогою ряду методів вирішення проблем, але кожен спосіб, який ви могли б зробити, робиться краще та / або простіше через пов'язані робочі місця.

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

tl; dr: Будь-який час, коли ви хочете, щоб дві робочі дерева перевірили одночасно з будь-якої причини, git-worktreeце швидкий і просторовий спосіб зробити це.

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

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

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

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

У мене досить незвичний: я займаюся розробкою Windows та Linux на одній машині . У мене у вікні Windows VirtualBox під управлінням Linux. VirtualBox монтує деякі каталоги Windows і використовує їх безпосередньо всередині машини Linux. Це дозволяє мені використовувати Windows для управління файлами, але будувати в Linux. Це проект крос-платформи, тому він будується як для Windows, так і для Linux з однієї структури каталогів.

Проблема полягає в тому, що системи побудови Linux та Windows врізаються одна в одну при використанні в одному каталозі; є кілька складних етапів збирання для завантаження бібліотек тощо, які використовують однакові назви каталогів. Версія Windows системи збирання завантажує специфічні для Windows бібліотеки, а версія Linux для системи завантаження завантажує специфічні для Linux бібліотеки.

В ідеальному світі система збирання буде модифікована таким чином, щоб Windows і Linux могли співіснувати в каталозі, але наразі проблема вирішується робочими колесами. Папка "Linux" може створювати специфічні для Linux артефакти збірки, а папка "Windows" може генерувати специфічні для Windows артефакти збірки. Хоча це навряд чи ідеальне рішення, воно робить приємний зупинку під час очікування усунення помилок системи збирання.

Правда, робоче дерево не було призначене для цього; Мені потрібно тримати версію Windows та версію Linux на окремих гілках, хоча я дійсно вважаю за краще, щоб вони були на одній гілці. Тим не менше, це робить свою роботу і є дещо нетрадиційним випадком роботи, що рятує день.

У новому для мене проект я створив функцію. Але деякі технічні характеристики провалилися. Для порівняння результатів masterя створив work-treeрепо. Я порівнював результати крок за кроком у коді запуску, поки не зрозумів, що пішло не так.

Я використовую git worktreeдля розвитку машинного навчання.

У мене є основний функціональний код, і тоді я хочу розділити гілки різних експериментів (різні алгоритми та різні гіперпараметри). git worktreeдозволяє мені інтегрувати dvc поряд із різними версіями мого коду, що спеціалізуються на різних алгоритмах. Після виконання всіх навчальних завдань я оцінюю підсумкові показники та зливаюся, щоб опанувати найкращу галузь / модель.