Как уменьшить размер удаленного репо, удалив ветвь с большими размерами?

Question

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

В нашем случае нас не волнует, что ветвь больше существует и прекрасно справляется с ее удалением (вместе с ее историей и т. Д.). Мы можем взять на себя эту работу и подтвердить ее в другой ветке. Поскольку ветвь не была объединена с ее главной, мы можем полностью удалить ветку. Предполагая, что ссылки содержатся в ветке на зафиксированные двоичные файлы, есть ли более простое решение?

Из исследования, следующие решения были вызваны:

• BFG Repo-Cleanerx
• Интерактивная перебазировка
• git filter-branch

Однако они предполагают, что читатель хочет сохранить историю и, таким образом, удалить поврежденные двоичные файлы, переписать историю и / или что проблема все еще локализована в локальном хранилище. Если проблема удаленная, необходимо исправить локальную проблему, а затем нажать --all на удаленную.

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

Answer 1

Удаление ветки - это, в общем, правильный ответ. Но здесь есть много маленьких ручек. С некоторыми из них вы можете просто подождать (около месяца) и не связываться с ними. Если вы не хотите ждать, пока различные копии хранилища уменьшатся сами по себе:

В этом случае мы уже удалили ветку и возобновили работу над новой веткой, но размер еще не изменился...

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

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

Непосредственной следующей проблемой является то, что Git по своей природе "хочет" делать больше копий всего. Коммиты похожи на некоторые вирусы или болезни: подключите один Git к другому Git, и Git, у которого не было коммитов, теперь имеет их. У Git, у которого были коммиты, все еще есть они. Когда вы, наконец, удалите коммиты, скажем, из шестнадцати клонов, любому, где бы то ни было, кому-то есть коммиты в своих клонах, будет нелепо легко случайно представить их фиксированным клонам, из которых они распространятся обратно. для всех остальных. Это не означает, что вы не можете избавиться от коммитов - и то, как вы их сейчас получаете, "достижимо только из одной ветви", значительно упростит вещи, так как вам просто нужно убедиться, что нет кто-то еще восстанавливает или сливает эту ветвь со своего клона.

Для получения дополнительной полезной информации я рекомендую прочитать и поработать через веб-сайт Think Like (a) Git. После того, как вы переварили, что там есть, способ уменьшить ваш репозиторий:

• Убедитесь, что коммит (ы) с большими файлами недоступны. В вашем конкретном случае удаление имени ветви дает вам большую часть пути: они были доступны по имени этой ветви и через журналы этой ветви. Удаление ветки удаляет и ее повторные журналы, так что теперь путь очищен.

  Место, из которого эти коммиты (вероятно) еще могут быть достигнуты, находится в вашем HEAD reflog. Бег git reflog покажет вам все HEAD reflog records (действие по умолчанию show и по умолчанию reflog, чтобы показать, что для HEAD). Вы можете выборочно удалить каждую такую ​​запись reflog, например, с помощью git reflog delete, но проще всего удалить все свои HEAD Перепишите записи с:

  git reflog expire --expire=now --expire-unreachable=now
  

  Обратите внимание, что это удаляет все ваши возможности для восстановления в противном случае случайно потерял HEAD коммиты, так что будьте уверены, что вы в порядке с этим, прежде чем сделать это. Вы можете оставить --expire=now поскольку коммиты для удаленной ветви не должны быть доступны из вашей текущей ветви - здесь я показываю вариант команды "nuke it from orbit".

• Затем беги git gc --prune=now, Это последний шаг "контрольного списка для сокращения хранилища" из git filter-branch документация

Это позаботится обо всех различных элементах, необходимых для перекомпоновки файлов пакета и / или отбрасывания незакрепленных объектов, в которых хранятся большие файлы, которые более недоступны ни по одному внешнему имени. То есть никакое внешнее имя не указывает прямо или косвенно на какой-либо коммит, который через свое дерево или одно из поддеревьев дерева указывает на объект blob, содержащий файл. Таким образом gc команда организует другие команды (git repack а также git prune) который удалит ненужные объекты.

(Примечание: если вы используете .keep файлы, чтобы сохранить старые пакеты, вам придется удалить те .keep файлы и позволяют эти пакеты будут уничтожены. Если вы делаете это, вы, вероятно, не задаете этот вопрос в первую очередь.)