Truncate GIT History (с 2 постоянными ветвями)

Question

У нас есть хранилище git с 13.08.2012, с более чем 4000 коммитов, занимающих почти 7 ГБ дискового пространства. (GIT Version: 2.9.0.windows.1)

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

Как и многие другие, мы хотели бы «консолидировать» историю с определенной даты. Предположим, мы хотим «сквош» вместе все, что было старше 6 месяцев, чтобы стать одним большим фиксатором.

Основным препятствием является то, что мы получили мульти-ветви структуру, и, очевидно, мы хотим сохранить его:

• Мастер филиал (бессрочное)
• Развитие отрасли (бессрочное)
• Характеристика отрасли (один для каждой задачи, удаленных после слияния)

в примере, Это как история выглядит сейчас:

How the history looks now

Это то, что нам нужно:

What we need

Мы пытались несколько таких подходов "Rebase", "Вишневый выбрать", "клон" с "глубиной" ... но ничего не кажется способный делать то, что нам нужно. Это наиболее значимые вещи я пытался:

• Rebase и вишневый выбрать (с помощью TortoiseGit 2.1.0.0) С обеих команд я пытался «сквош» старейшей совершает, но каждый объединить результаты в диалоге " какой родитель вы хотите выбрать? parent1/parent2 ", то независимо от того, что я выбираю: все файлы становятся помечены как« конфликты », и поэтому их нужно разрешить« вручную ». Я просто не могу обрабатывать все эти конфликты вручную (и не воспроизводить одну и ту же последовательность для ветвей Master и Develop).

• Клон с глубиной (с помощью Git-Баш) Я выполнил эту команду: «мерзавец клон limitedRepo --depth = 1000», что правильно «сквош» все старше совершает, но в результате репо имеет только одну ветвь.

Так что я попробовал эту команду, чтобы получить обратно Develop ответвления от происхождения:

«мерзавец удаленного набора-ветвь происхождения„*“» «мерзавец принести -vvv»

но сгружена ветвь содержит всю историю, а не «раздавленную» нам.

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

Любая идея?

Answer 1

Возможно, это не количество фиксаций, занимающих дисковое пространство, а, возможно, это несколько версий больших файлов, которые существуют в истории вашего репозитория, но с тех пор были удалены из текущей версии вашего кода.Pro Git имеет раздел Removing Objects, который позволяет удалять большие файлы из истории Git.

There are a lot of great things about Git, but one feature that can cause issues is the fact that a git clone downloads the entire history of the project, including every version of every file. This is fine if the whole thing is source code, because Git is highly optimized to compress that data efficiently. However, if someone at any point in the history of your project added a single huge file, every clone for all time will be forced to download that large file, even if it was removed from the project in the very next commit. Because it’s reachable from the history, it will always be there.

(внимание, шахта)

... Be warned: this technique is destructive to your commit history. It rewrites every commit object since the earliest tree you have to modify to remove a large file reference. If you do this immediately after an import, before anyone has started to base work on the commit, you’re fine – otherwise, you have to notify all contributors that they must rebase their work onto your new commits.

Теперь все, что вам нужно сделать, это find large files in your repository history.

Связанное StackOverflow сообщение: Remove old commit information from a git repository to save space

Независимо от того, как вы сделаете это, команда широкого git rebase не в будущем.