Единая рабочая ветвь с Git

Ответ 1

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

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

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

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

и др.

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

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

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

Ответ 2

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

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

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

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

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

(Источник: Scott Chason, ProGIT Book, http://progit.org/book/ch3-1.html, CC-BY-NC-SA)

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

Итак, вопрос в том, почему Git не имеет двух указателей, по одному для каждого каталога? -

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Если вы используете git под Cygwin, вы можете просто загрузить и использовать оригинальный git-new-workdir script. Он отлично работает, я сам использую его. Если вы используете 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: Commit in working tree A вызывает ложные изменения в дереве B
• По-видимому, вы не должны использовать git-new-workdir для копирования рабочего каталога, уже созданного git-new-workdir. Просто скопируйте исходный клон. На самом деле, я считаю, что последние версии script обнаружат эту ситуацию и ошибку.
• git prune не соблюдает должным образом записи reflog

Ответ 6

Возможно, submodules может помочь вам иметь независимые каталоги?

Ответ 7

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

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

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

Применяются обычные оговорки.

• Создать новый рабочий_dir
• Начать git, указывая на work_dir
• Сохранить текущий HEAD
• Оформить требуемую ветку/фиксацию (она должна перейти в work_dir)
• Установите HEAD обратно на сохраненное значение (это взломать и может не работать без шагов, чтобы держать индекс вправо!)
• закрыть git, чтобы "забыть" параметр work_dir
• перезапустите git обратно в старый каталог и связанную с ним ветку

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

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

ОБНОВЛЕНИЕ --------------------------------
Инструкции 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.