Одиночная рабочая ветка с Git

Question

Краткое описание награды

Существует ли портативный способ использования одного хранилища с несколькими проверками ? Как альтернатива несколько клонов, где слишком много служебной информации (нажатие / извлечение / синхронизация ...) и риск перезаписи жестких ссылок .git/objects (что даже не работает в Windows).

---

Новичок в git и любопытно слышать мысли от опытных пользователей git.

Существует ли концептуальная причина, по которой git одновременно работает только с ОДНОЙ ветвью? Кажется абсолютно нецелесообразным переключаться назад и вперед между ветвями, когда большую часть времени мне нужно работать как минимум над двумя разными ветвями одновременно, например, здание, работающее параллельно a.s.o.

Хорошо, так что, возможно, разработчику действительно не нужно работать одновременно над двумя ветками. Но проверка другой ветви не несет автоматически игнорируемые вещи, такие как выходные файлы сборки. Поэтому требуется новое восстановление a.s.o.

Существует этот сценарий git-new-workdir, который должен разрешать несколько рабочих веток, но, с одной стороны, он не является частью git-релиза, хотя он существует уже около 3 лет, поэтому я не верю, что он сохранит мой файлы соответствуют. А во-вторых, я не могу найти его в составе дистрибутива Windows, который является одной из машин, которые я использую для разработки.

Таким образом, единственным официальным вариантом является создание нового «клона» для каждой ветви, что кажется неправильным, поскольку каждый клон является полноценным хранилищем. Я бы даже не знал, как называть каталоги клонов - я использую имя репозитория или имя ветви, или и то и другое? Что если я создам еще одну ветку из этой ветви, a.s.o.

Обновление кейса для реального использования (@ предложение Филиппа)

Я обычно работаю над двумя основными / второстепенными выпусками, причем функции работают одновременно. Существует также случайная ветка разработки, в которую входят экспериментальные функции, прежде чем они будут объединены с каким-либо будущим выпуском.

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

Таким образом, более удобный и естественный подход заключается в сохранении нескольких так называемых «активных» ветвей, каждая из которых проверяется в своем собственном каталоге со своими скомпилированными двоичными файлами. Это также сэкономило бы время компиляции и время от времени локальную настройку (то есть файлы конфигурации, которые необходимо менять после каждой проверки, чтобы запустить продукт).

Answer 1

Ветвь при извлечении - это только указатель на коммит ( в графе коммитов ).
Таким образом, Git не может проверить два коммита этого графа одновременноtime .

На самом деле, смотрите " Несколько рабочих каталогов с Git? ".
С Git 2.5+ (Q2 2015) вы можете иметь несколько рабочих деревьев для одного репозитория git, с git checkout --to=<path>.

Это позволяет вам извлекать ветку в отдельном рабочем каталоге на <path>.Новый рабочий каталог связан с текущим репозиторием.

Эта ссылка является «переносной» (т.е. работает даже в Windows), поскольку она записана в главном каталоге репо $GIT_DIR/worktrees.

---

Оригинальный ответ (2011):

(Источник: Скотт Чейсон, книга ProGIT, http://progit.org/book/ch3-1.html, CC-BY-NC-SA)

Если вам нужно работать над двумя разными ветками одновременно, просто клонируйте репо и выберите (git checkout) другую ветку в этом клоне.Вы можете использовать имя ветви в качестве имени корневого каталога для этого клона.
И вы можете создавать ветви в любом из этих репозиториев.

---

Так что вопрос в том, почемуGit не может иметь ДВА указателя, по одному для каждого каталога?-

Как упомянуто в " Популярность Git / Mercurial / Bazaar по сравнению с рекомендациями ", Git по своей сути управляет контентом .Каждый коммит представляет полный моментальный снимок репо.
Невозможно просмотреть два содержимого в одном контейнере (рабочем каталоге), даже если вы можете хранить ссылки на столько указателей (ветвей), сколько хотите.

Вы заполняете рабочий каталог только one content.

Answer 2

Если у вас git clone с локальным путем, все, что находится под .git/objects (то есть, большинство коммитов и данных в вашем хранилище), по возможности, жестко связано со старым репо и занимает почти свободное место на диске. Так что, если вам нужны две разные рабочие директории, просто клонировать свое хранилище не очень дорого. Попытка управлять двумя разными рабочими каталогами из одного репозитория может сработать, но это того не стоит.

В общем, запустите git clone /path/to/old/repo new_repo и все будет просто работать.

Answer 3

То, что вы хотите, называется alternates , что позволяет одному репо зависеть от другого в отношении своих объектов.Его использование не очень распространено, потому что дисковое пространство дешево, и вы должны быть осторожны, чтобы случайно не удалить объекты, в которых нуждается зависимое хранилище.

Answer 4

Если вы хотите это сделать,

Я бы на 100% рекомендовал написать собственное приложение ¹ , которое управляет этим процессом надежным способом.

Отправной точкой может быть

GIT_WORK_TREE=/worktrees/stable   git checkout -f origin/stable
GIT_WORK_TREE=/worktrees/unstable git checkout -f origin/unstable

и т.д.

Я бы конкретно позаботился о , чтобы ни одна из ваших рабочих копий не выглядела (удаленно) как обычный репозиторий, чтобы обычные команды git не применялись.

Использование обычных команд git (sub) - это путь к катастрофе, потому что однажды вы столкнетесь с скриптом, который не использует GIT_DIR, GIT_WORK_TREE, GIT_INDEX так, как это должно (или вы ожидали).

---

¹ (возможно, на основе NGit или аналогичных привязок Git для Python, Ruby - независимо от того, что переносимо в вашей вселенной)

Answer 5

На самом деле, git-new-workdir был создан именно для этой проблемы.У меня та же проблема, и я использую ее без проблем.О ваших бронированиях:

Существует этот скрипт git-new-workdir, который должен разрешать несколько рабочих ветвей, но, с одной стороны, он не является частью релиза git, хотя он был около3 года, поэтому я не доверяю тому, чтобы мои файлы оставались согласованными.

Ну, я (и многие другие) использовал его годами, и я не сталкивался ни с какими ошибками, ниЯ слышал о каких-либо реальных проблемах (кроме незначительных ограничений, см. Ниже).Это может звучать не так уж и много, но даже с самим git (или любым другим проектом без SW), единственная реальная гарантия, которую вы получаете, это «никто еще не нашел проблему».Я не знаю, почему git-new-workdir все еще участвует, но я не думаю, что это должно вас сдерживать.

А во-вторых, я не могу найти его как часть дистрибутива Windows, который является одной из машин, которые я использую для разработки.

Это может быть только из-за вашего дистрибутиварешили не включать contrib/.

Если вы используете git в Cygwin, вы можете просто скачать и использовать оригинальный скрипт git-new-workdir.Работает нормально, сам пользуюсь.Если вы используете msysGit, доступны порты: https://github.com/joero74/git-new-workdir/blob/master/git-new-workdir.cmd и https://github.com/dansmith65/git/blob/master/contrib/workdir/git-new-workdir-win.Я не знаю об их качестве, хотя.

Ограничения git-new-workdir

Просто для полноты, вот ограничения, которые я знаю:

• Если вы извлекаете одну и ту же ветку в обоих рабочих каталогах, а затем фиксируете что-то в одном рабочем каталоге, состояние другого будет запутано: git-new-workdir: фиксация в рабочем дереве Aвызывает фиктивные изменения в дереве B
• Очевидно, вам не следует использовать git-new-workdir для копирования рабочего каталога, уже созданного git-new-workdir.Просто всегда копируйте оригинальный клон.На самом деле, я полагаю, что последние версии скрипта обнаружат эту ситуацию и сообщат об ошибке.
• git prune неправильно учитывает записи reflog

Answer 6

Если я правильно понимаю, вы ищете возможность CopyOut для определенной главы ветки или фиксации в ветке, в независимом каталоге, для целей исследования и сравнения, при этом все еще проверяя текущую ветку разработки / исправления ошибокв качестве вашего основного мерзавца "ссылка".

Вы ожидаете, что независимый «скопированный» каталог вряд ли будет перенаправлен непосредственно в git.

Непроверенный подход заключается в использовании команды base git с ее [--git-dir=<path>] [--work-tree=<path>] опций, и, с помощью тщательного сценария, настройте / исправьте вашу HEAD / Index, как вы делаете CopyOut и вернитесь к текущей ветке.

Обычные предостережения применяются..

1. Создать новый work_dir
2. Запустить git, указывающий на work_dir
3. Сохранить текущий HEAD
4. Оформить требуемый переход / коммит (он должен идти вwork_dir)
5. Установить HEAD обратно на сохраненное значение (это хак и может не работать без шагов, чтобы сохранить индекс правильно!)
6. закрыть git, чтобы «забыть» настройку work_dir
7. перезапустите git обратно в старый каталог и связанную с ним ветку

Это определенно потребует тщательного тестирования и, вероятно, потребует корректировки вокруг шагов 3 и 5, так что шаг 6-7 будет верным.

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

UPDATE --------------------------------
Инструкции clunx основаны на представлении пользователя Windows.

# this is run from your main work dir (that contains .git)
Copy .git/HEAD MyBackup
# HEAD will contain the line similar to "ref: refs/heads/master"
mkdir <path>
# the path should be 'somewhere else', not in your existing directory
# If the path doesn't exist the following checkout will fail
Git --work-tree=<path> checkout <branch>
# this will extract the latest commit on that branch to the work tree path
# or use a commit sha1 instead of <branch>, if you want an exact commit
# Note: your index will be updated to reflect the checked out files, as will HEAD.
Copy MyBackup .git/HEAD
# set the HEAD back to where it was
Git reset
# reset the index appropriate for the previous Head.
# note we dropped the --work-tree parameter

Аналогичный метод можно использовать для получения любых ревизий изизвлек путь, указав --work-tree в нужном месте в нужное время и убедившись, что индекс установлен правильно.Не забывайте обычные предостережения [резервное копирование, резервное копирование и резервное копирование].

Это сработало для меня на тестовом репо, которое у меня есть.Некоторые действия были в Windows.

Answer 7

Может быть, подмодули могли бы помочь вам иметь независимые каталоги?