Удалите большие коммиты из git

Мы запускаем центральный репозиторий git (gforge), который каждый извлекает и толкает. К сожалению, некоторые неумелые коллеги решили, что толчок нескольких файлов размером 10-100 МБ в репо был хорошей идеей. Вследствие этого на нашем сервере, который мы используем много, закончилось дисковое пространство.

Мы только осознали это, когда было слишком поздно, и большинство людей вытащили новое огромное репо. Если бы проблема не была нажата, тогда мы могли бы просто сделать rebase, чтобы вырезать эти огромные коммиты и исправить ее, но теперь все вытащили из нее, что лучший способ удалить эту фиксацию (или сделать перестановку просто удалите большие файлы), а затем это не вызовет хаос, когда каждый хочет вытащить/нажать из/в репо?

Он должен быть небольшим репо для скриптов, но теперь он имеет размер около 700 М: - (

Ответы

Ответ 1

Отметьте https://help.github.com/articles/remove-sensitive-data. Здесь они пишут об удалении конфиденциальных данных из вашего репозитория Git, но вы можете очень хорошо использовать его для удаления больших файлов из ваших коммитов.

Ответ 2

Самый простой способ избежать хаоса - предоставить серверу больше диска.

Это непросто. Для удаления файлов требуется также удалить их из истории, которая может быть выполнена только с помощью git filter-branch. Эта команда, например, удалит <file> из истории:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch <file>' \
--prune-empty --tag-name-filter cat -- --all

Проблема заключается в том, что это перезаписывает хэши SHA1, что означает, что всем в команде понадобится reset к новой версии ветки или рискует серьезной головной болью. Это все хорошо и хорошо, если никто не работает, и вы все используете ветки темы. Если вы более централизованы, ваша команда большая, или многие из них хранят грязные рабочие каталоги, пока они работают, нет никакого способа сделать это без немного хаоса и раздора. Вы могли потратить довольно много времени, чтобы все локальные работали правильно. То, что написано, git filter-branch, вероятно, лучшее решение. Просто убедитесь, что у вас есть план, ваша команда это понимает, и вы убедитесь, что они создают резервные копии своих локальных хранилищ на случай, если какая-то важная работа будет потеряна или запущена.

Один из возможных вариантов:

  • Получить команду для создания патчей своей работы, что-то вроде git diff > ~/my_wip.
  • Получить команду для создания патчей для их совершенной, но не разделенной работы: git format-patch <branch>
  • Запустите git filter-branch. Удостоверьтесь, что команда знает, что не тянет, пока это происходит.
  • Задайте команду git fetch && git reset --hard origin/<branch> или попросите их повторно клонировать репозиторий.
  • Примените их ранее выполненную работу с помощью git am <patch>.
  • Примените свою работу в git apply, например. git apply ~/my_wip.

Ответ 3

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

Ранее мы делали такие вещи, в том числе запрещали определенные идентификаторы фиксации из-за определенных пользователей, которые просто не могли получить зависание "сохранить вашу работу в ветке temp, reset и потянуть, и повторно применить ваша работа, минус гигантский файл".

Обратите внимание, что крюк pre-receive работает в довольно интересном контексте: файлы фактически загружены, а именно, что ссылки (обычно ветки ветки) еще не изменились. Вы можете предотвратить изменение заголовков ветвей, но вы все равно будете использовать (временное, до gc'ed) дисковое пространство и пропускную способность сети.

Ответ 4

Использовать ветвь фильтра!

git filter-branch --tree-filter 'find . -name "*.jar" -exec rm {} \;'

Затем просто очистите все коммиты, у которых нет файлов в них:

git filter-branch -f --prune-empty -- --all

Ответ 5

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

  • Начиная с GForge 6.3, администраторы сайта могут определять проекты, в которых используется слишком много дисков, а также старые и осиротевшие проекты. Это может помочь вам избежать ситуаций с полным диском, особенно если у вас много отдельных команд и проектов.
  • Реализация git перехватчиков (в основном, SCM-крючков) в GForge. Администраторы сайта могут настраивать любое количество команд перехвата, и люди уровня проекта могут затем выбирать, какие крючки они хотят для своего проекта. Добавление крюка, который предотвращает определенные типы (или размеры?) Файла, будет подходящим для этой функции.