Миграция большого, отклоняющегося проекта команды TFS на Git

Question

У меня есть проект команды большого размера с TFS.

После битвы с Git-TFS (у нас есть некоторые фанки в нашем проекте Team TFS) У меня есть полное локальное репо.

Он слишком большой, чтобы вписаться в мягкий предел BitBucket 1GB.

Проект команды содержит ветви, которые являются разнородными продуктами.

- Базовый продукт (магистральный)
--- Клиент продукта (от ствола)
--- Клиент B Продукт (из ствола)
---- Client B Функция Branch (от B)
--- Клиент C Project
---- Клиент D Project (от C) (от ствола)
----- Клиент E Project (из D)

Как вы можете видеть, мы убежище» я был добр к себе, когда ветвялся в TFS.

Выполнение мелкого клонирования показывает, что одна фиксация для любой ветки составляет около 150-200 МБ. Полная история для какой-либо данной отрасли составляет чуть меньше 1 ГБ.

Я предлагаю сделать git repo на каждую ветку и просто нажимать историю ветвей с момента фиксации ветки. Это означало бы, что ни одна ветвь не имеет общего предка, заставляя необоснованные слияния, когда хочет слить филиал с перекрестными TFS. Я также предлагаю хранить полное историческое репо только для чтения, делая агрессивный GC и удаляя некоторые большие объекты, что позволяет мне сжать всю партию в единый репо. Это, по крайней мере, открывает возможность выполнения трансплантата или замены + rebase, чтобы присоединиться к «текущему» репо с историческим в какой-то момент в будущем.

Я не могу очистить историю (и переустанавливать) в любой точке, чтобы обеспечить разумную общую родословную и запас репо под пределом 1 ГБ.

Может ли кто-нибудь помочь с лучшей стратегией перехода?

ОБНОВЛЕНИЕ 1: подтекст на этот вопрос ... Когда продукты расходятся, насколько важна структура ветви. Существенная проблема, которую мы имеем, это отношения фиксации слияния между филиалами. Если я обрезаю историю, это также заставляет меня распоряжаться историей фиксации слияния в некоторых случаях (потому что мы сделали брокеры слияния с ранних частей одной ветви на поздние части другой)

ОБНОВЛЕНИЕ 2: У меня есть другая стратегия, которая распределяет всю историю слияния, но сохраняет исходную родительскую ветвь. Быстрый клон Git TFS с опцией -c для создания начальной точки в нужный момент времени. Git TFS тянуть --rebase --all Затем инициализации нисходящей ветви Git TFS филиал --init [имя ветви] Затем потяните снова и т.д.

Это дает общее происхождение и дозирует слияния совершить историю, которая учитывает меньшее репо, но за счет истории слияния.

Answer 1

Трудно ответить, не зная, что у вас в вашем хранилище, и что вы хотите сохранить.

Но если у вас есть рабочий каталог около 100-200 МБ, у вас должно быть много двоичных файлов.

Я уверен, что первый шаг, чтобы удалить все двоичные файлы можно с помощью очень хороший и простой в использовании инструмент, bfg report cleaner

Тогда вы увидите, если размер вашего хранилища по-прежнему является проблемой ,

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

редактировать: в самом деле, я гугл об этом пределе на BitBucket и найти this page 2 очень интересных ссылки: How to handle big repositories with git и Reduce repository size