Для чего я буду использовать git-worktree?

Я прочитал пост Github на git-worktree . Они пишут:

Предположим, вы работаете в Git-репозитории над веткой, которая называется feature, когда пользователь сообщает об ошибке срочности master. Сначала вы создаете связанное рабочее дерево с новой веткой, hotfixизвлеченное относительно мастера […]. Вы можете исправить ошибку, нажать исправление и создать запрос на извлечение.

Когда я работаю над веткой с именем feature, и сообщается о какой-то серьезной ошибке в master, я обычно прячу все, над чем работаю, и создаю новую ветку. Когда я закончу, я смогу продолжить работу. Это очень простая модель, я работал так много лет.

С другой стороны, использование git-worktree имеет свои ограничения:

Например, нельзя одновременно проверять одну и ту же ветку в двух связанных рабочих деревьях, потому что это позволит изменениям, зафиксированным в одном рабочем дереве, вывести из синхронизации другое.

Почему я выбрал бы более сложный рабочий процесс для проблемы, которая уже была решена?

Есть ли что-то, git-worktreeчто нельзя было бы сделать заранее, и это оправдывает всю эту новую, сложную функцию?

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

С worktree вы можете избежать этой постоянной реконфигурации. Оформите эти старые ветки в отдельных папках, используя рабочее дерево. Для каждой ветви вы получили независимый проект 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. Некоторые люди спрашивают «почему бы не сделать несколько локальных клонов». Это правда, что с флагом --local вам не нужно беспокоиться о дополнительном использовании дискового пространства. Это (или похожие идеи) - то, что я сделал до этого момента. Функциональные преимущества связанных рабочих деревьев перед локальными клонами:

   1. С локальными клонами ваши дополнительные рабочие деревья (которые находятся в локальных клонах) просто не имеют доступа к исходной или восходящей ветвям. «Происхождение» в клоне не будет таким же, как «происхождение» в первом клоне.

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

   2. Вы можете делиться ссылками между рабочими деревьями. Если вы хотите сравнить или позаимствовать изменения в другом местном филиале, теперь вы можете.

tl; dr: Каждый раз, когда вы хотите, чтобы по каким-либо причинам одновременно проверялись два дерева работ, git-worktreeэто быстрый и экономичный способ сделать это.

Если вы создаете другое рабочее дерево, большинство частей репо (т.е. .git ) будет использоваться совместно, то есть если вы создадите ветку или получите данные, находясь в одном рабочем дереве, оно также будет доступно из любых других рабочих деревьев, которые у вас есть. Скажем, вы хотите запустить свой набор тестов на ветке foo, не нажимая его куда-нибудь, чтобы клонировать его, и вы хотите избежать хлопот с клонированием вашего репо локально, используя git-worktreeхороший способ создать просто новую проверку некоторого состояния в отдельное место, временно или постоянно. Как и в случае с клоном, все, что вам нужно сделать, когда вы покончили с ним, это удалить его, и ссылка на него через некоторое время будет собрана мусором.

Первоначально я наткнулся на этот вопрос, задаваясь вопросом, для чего можно использовать эти причудливые рабочие деревья. С тех пор я интегрировал их в свой рабочий процесс, и, несмотря на мой первоначальный скептицизм, я нашел их весьма полезными.

Я работаю над довольно большой кодовой базой, на компиляцию которой уходит довольно много времени. У меня обычно есть текущая ветка разработки на моей машине вместе с веткой функций, над которой я сейчас работаю, плюс ветка master, которая представляет текущее состояние работающей системы.

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

У меня довольно необычный вопрос: я занимаюсь разработкой Windows и Linux на одной машине . У меня есть VirtualBox под управлением Linux внутри моей коробки Windows. VirtualBox монтирует некоторые каталоги Windows и использует их непосредственно внутри компьютера с Linux. Это позволяет мне использовать Windows для управления файлами, но строить в Linux. Это кроссплатформенный проект, поэтому он основан на Windows и Linux из одной и той же структуры каталогов.

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

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

По общему признанию, worktree не был разработан для этого; Я должен держать версию Windows и версию Linux в разных ветвях, хотя я действительно предпочел бы, чтобы они были в одной ветке. Тем не менее, это делает работу, и это несколько необычный случай, когда рабочее дерево спасает день.

В новом проекте для меня я создал функцию. Но некоторые спецификации не удалось. Для сравнения результатов masterя создал work-treeрепо. Я шаг за шагом сравнивал результаты выполнения кода, пока не понял, что пошло не так.

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

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