GITヒストリを切り捨てる（2つの永続的なブランチを持つ）

Question

私たちは、約7 GBのディスク容量を占める4000以上のコミットを持つ、2014年8月13日からgitリポジトリを持っています。 （GITバージョン：2.9.0.windows.1）

これらの年の間、プロジェクトはかなり進化しました。したがって、最も古いコミットはもう役に立たなくなりました。

ほかにも、特定の日付の履歴を「統合」したいと考えています。 6カ月以上経過したものを「スカッシュ」して1つの大きなコミットにしたいとしましょう。

メインのハンディキャップは、我々は多枝構造を得たことで、明らかに我々はそれを維持したい：

• マスターブランチ（永久）
• （永久）
• 機能ブランチ（支店を開発
  ：各タスクの一つは、これは歴史が今どのように見えるかです 、例で

）マージ後に削除しました

How the history looks now

これは、我々が必要とするものである：

What we need

私たちは、 "深さ" を持ついくつかのアプローチなど "リベース"、 "チェリーピック"、 "クローン" を試してみました...しかし、何も思いません私たちが必要とすることをすることができます。 これらは私が試した最も有意義なものです：「私は「スカッシュ」の最も古いコミットしようとしたが、それぞれが対話の中で結果をマージ両方のコマンドで （tortoiseGit 2.1.0.0を使用して）

• リベースとチェリーピックどちらの親を選びたいのですか？parent1/parent2 "、どのファイルを選んでも問題ありません。すべてのファイルが"競合 "としてマークされ、"手動で "解決する必要があります。 私は、このすべての競合を手動で処理することはできません（マスターブランチと開発ブランチで同じシーケンスを再現することはできません）。すべての古いコミットが、結果のレポは単一の枝を持って正しく「スカッシュ」 「gitのクローンlimitedRepo --depth = 1000」：（Gitの-バッシュ経由）の深さの

• クローン 私は、このコマンドを実行します。

  「gitのリモート設定ブランチの起源 『*』」

  が、フェッチされたブランチを「gitの-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ワイドチームは、あなたの将来にはありません。