問題タブ [git-rewrite-history]

約 60000 件のコミットで構成されるかなり大きなコードベースがあります。git 履歴を保持しながら、すべての .java ファイルを再フォーマットしたいと考えています。そのため、私たちが取ったアプローチは、履歴をそのまま維持しながら git filter-branch --tree-filter を使用してコードベース全体を再フォーマットすることです。しかし、私が答えを見つけることができないいくつかの質問があります。

1. --tree-filter を適用し、ルート ディレクトリ内のすべての .java ファイルを再フォーマットするコマンドを渡すと、書き換えが行われますが、最後に、ステージング領域内のすべての .java ファイルが表示されます。書き換えのすべてのステップでコミットが必要ですか、それとも自動的に行われますか?

2. git filter-branch はさまざまなコミットを行うように見えるため、失敗した場合にすべての書き換えと再開の前にコミット ID を保存できるかどうか疑問に思いました。プロセス全体が完了するまでに数日かかる場合があるため (強力なコンピューティング インスタンスであっても)、再開は重要です。

3. コードベース全体を再フォーマットする目的で、 --index-filter は機能しますか?

更新: 説明

• コード ベースは約 220 万行の Java コードです。git の書き換えを行わないと、コードベースの約 10% ～ 12% が間違った作成者に帰属することになります。これは約 20 万行の Java コードであり、これは回避したかったことです。Git の書き換えにより、変更を加えた人が正しい方法で変更したように見えます。

コマンドを使用してレポをスリムにしようとすると:

コンソールに出力が表示されます。

large_files.txt は、削除するファイルのリストを含む単なるテキスト ファイルです。私はそれを所有しており、すべての権限を持っています。

.git-rewrite がリポジトリにない (削除された) ことを確認しましたが、強制フラグは役に立ちませんか?

これは正確にはどのような権限ですか？ファイルシステムのアクセス許可、Git リモートのアクセス許可、またはその他? それは私のレポです。私はそれに完全にアクセスでき、sudoで試してみましたが、何も役に立ちません。ところで: large_files.txt は、削除するファイルのリストを含む単なるテキスト ファイルです。

ここで何が欠けているのか教えてもらえますか?

大きな SVN リポジトリを GIT に移行しましたが、同じ作成者の同じメッセージで大量の連続したコミットがあります。

ここで、コミットを 1 つのコミットに自動的に修正したいと思います。

考え？

私のチームは Git への移行を準備しており、小さなリポジトリから始めたいと考えています。git-svn によって作成される最初の Git リポジトリは、バイナリ ファイルと数百のバージョン ブランチのために、約 10 GB の大きさです。

大きなファイルをクリーンアップするのは簡単ですが、難しいのはブランチの数のようです。

git 移行では、特定の (最新の) ブランチのみを使用して、特定の時点 (X) から開始したいと考えています。 「トランク」はありませんが、代わりに、長期間にわたって維持されるさまざまなバージョンのブランチがあります。

履歴から大きなブロブを消去する方法を簡単に見つけました (BFG、git filter-branch)。

私の質問：

いくつかの特定のブランチを除くすべてのブランチを履歴から削除して、新しいリポジトリにブランチ「バージョン 3」のみを含めるにはどうすればよいでしょうか? 理想的には、このブランチが作成された開始コミットから履歴を開始したいと考えています。

これを行う方法git filter-branchまたは別の可能性はありますか?

それで、私はこれを行う正しい方法を午前中ずっと探していましたが、それを理解するためのコマンドラインに精通していません。

大量のアセットを含む git リポジトリがあります。それは大罪のようなものです、私は知っています。

レポが大きくなりすぎました。リポジトリの履歴全体から、HEAD に存在しなくなったすべてのファイルをプログラムで削除できるように、クリーンアップしたいと思います。ファイル パスを指定してこれを行う方法を見てきましたが、実際には、最終製品から削除された 1000 以上のファイルのように話しています。

更新: そもそもそこにあるはずのないすべてのアセットのレポをクリーンアップしました。私は実際にそこにソースコードとそこにあるべきいくつかの資産を持っているだけです. すべてのソースコードのすべての履歴を保持したいので、現在存在する履歴を保持しながら、削除されたファイルを履歴から破棄したいと考えています。それが目標です。を使用して実行できると確信していますがgit filter-branch、十分に理解していません。

git リポジトリの commit と push に 1 GB のムービーを追加するとします。次に、プッシュしたコミットを元に戻し、それをプッシュします。現在、最新のヘッドには 1 GB のファイルが含まれていません。

コミットを元に戻したばかりですが、1 GB のファイルが git 履歴の一部として永久に残るのは正しいですか? 1 GBのファイルなしで最新のヘッドに取り組んでいるにもかかわらず、レポはまだ1 GB大きく、それは永遠に残るということですか?

さておき

行末の git リポジトリを正規化する方法があります。リポジトリにさまざまな行末 (Mac、Unix、Windows) がある場合、それらが邪魔になることがあります。git-filter-branchしたがって、私が以前に行ったことは、ここで説明されている方法を使用して、それらすべてを Unix スタイルの行末に正規化することでした: http://blog.gyoshev.net/2013/08/normalizing-line-endings-in-git-repositories/

そうしても、履歴のデルタが大幅に台無しになった場所に侵入するほどの変更ではなかったという意味で、履歴は変更されませんでした。blame誰がコード行を変更したかgit-bisectを調べたり、いつどこで何が問題だったのかを調べるなどのツールを今でも使用できます。

今やりたいこと

コードベース全体を再フォーマットして、PSR 準拠のフォーマットを使用することを提案します。つまり、コードベース全体を再フォーマットし、それをリポジトリにコミットします。git-blame同様のツールはgit-bisect、その後おそらく動作を停止し、すべて同じ PSR 準拠のコミットを指します。私が楽しむようになったgitの力を阻害するので、私はそれが好きではありません。

質問

git-bisectやのような git パワーツールを壊すことなく、コーディング標準に関してリポジトリ全体を PSR に準拠させるにはどうすればよいgit-blameですか?

プレビュー ボタンが表示されなかったので、README.md を何度も編集しました。今、私のコミット履歴は役に立たないコミットでいっぱいです。

それらのいくつかを削除するか、少なくとも非表示にすることはできますか?