Git checkout ветвь и удаление всего, что связано с предыдущей проверкой (включая git-lfs осталось) - PullRequest
Новая
       97

Git checkout ветвь и удаление всего, что связано с предыдущей проверкой (включая git-lfs осталось)

0 голосов
/ 27 января 2019

У меня есть репо суперпроекта с количеством подмодулей. множество файлов в Git LFS.

Репо поставляется с несколькими долгоживущими ветвями релиза.

Проблема

Полный клон передает 20 ГБ объектов Git и Git LFS.

Checkout of master снижает общий объем репо до 40 ГБ, это объекты и файлы рабочего дерева вместе.

Давайте рассмотрим три отдельных клона как канонический способ создания три рабочих экземпляра, по одному на долгоживущий филиал: 

git clone --branch master      --recursive --jobs 8 https://repo repo_master
git clone --branch release/1.0 --recursive --jobs 8 https://repo repo_release1
git clone --branch release/2.0 --recursive --jobs 8 https://repo repo_release2

Я пытаюсь разработать оптимизированный для сети эквивалент вышеупомянутого: - клонировать один раз с проверенным мастером по умолчанию - сделать несколько копий клонированного репо - оформить выпуск веток

Вопросы

  1. Как извлечь существующую ветку, извлеченную из удаленного, удалить предыдущую ветку и очистить все остатки?

  2. Как убрать все что связано с ранее выписанным master и его рабочее дерево, любые кешированные предыдущие загрузки LFS и т. д.?

Но, чтобы сохранить историю происхождения / мастера.

Решение Прототип

Вот что я придумал для оптимизированного для сети рабочего процесса: 

git clone --branch master --recursive --jobs 8 https://repo repo_master

cp -a repo_master repo_release1
cp -a repo_master repo_release2

cd repo_release1
git checkout -b release/1.0 --track origin/release/1.0

git pull
git submodule update --init --recursive --jobs 8

git branch -D master

git lfs prune
git submodule foreach --recursive git lfs prune

git lfs checkout
git submodule foreach --recursive git lfs checkout

Вопросы к прототипу

Выглядит ли это правильно или какие-либо шаги отсутствуют / избыточны?

Имеет ли смысл запускать какие-либо из них, в какой момент? 

git gc --aggressive --prune=now
git submodule foreach --recursive git gc --aggressive --prune=now

Пожалуйста, примите во внимание, что между git clone --branch master ... и cp -a repo_master ....

( Проблема также была опубликована в Git Ling рассылки и Git LFS на GitHub )

Ответы [ 2 ]

0 голосов
/ 05 февраля 2019

Пока что удовлетворительный ответ на вопрос не поступил в список рассылки Git (ссылка на вопрос) или здесь.Единственный полученный ответ был , данный Брайаном из проекта Git LFS на GitHub.Я копирую это ниже.

Я думаю, что этот подход кажется хорошим.Я не думаю, что здесь необходимо запускать git gc, и, скорее всего, это не даст никакого эффекта из-за рефлога.

Благодарю Брайана за подтверждение моего рабочего процесса.

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

0 голосов
/ 30 января 2019

Я не очень хорошо разбираюсь в LFS, поэтому извините, если мой ответ не совпадает.

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

...