24

「Droid XX-XX-XX」という 1 つのディレクトリに 5 つの異なるソース ファイルで構成される小さなスクリプト プロジェクトがあります。ソース ディレクトリの新しいバックアップ コピーを作成するたびに、日付を X に入れます。したがって、異なる日付から約 15 の異なるバージョンがあります。これらのそれぞれを、新しい Git リポジトリに最も古いものから追加したいと考えています。

しかし、私はいくつかの問題に遭遇しました。

  1. 問題の 1 つは、インデントにタブを使用するファイルとスペースを使用するファイルがあることですが、タブとスペースの問題だけが異なる場合でも、Git は行全体を異なるものとして扱います。Git にインデントの書式設定を無視させるにはどうすればよいですか?

  2. もう 1 つの問題は、一部のファイル名にはスペースがなく、単語間にスペースが含まれているものもあるということですが、Git はそれらを別のファイルとして扱います。さらに悪いことに、本当の理由もなく、ファイル名が別のものに変更されることがありました (「PatrolPlan」が単に「Patrol」に変更されたなど)。新しいファイル セットを追加するとき、ファイル名が異なっていても、実際には特定の古いファイルの新しいバージョンであることを Git に伝えるにはどうすればよいですか? またはさらに良いことに、これが発生したときに自動検出するように設定できますか?

  3. 最後の問題は、開発中の特定の時点で、2 つのソース ファイルを 1 つにマージしたり、1 つを 2 つに分割したりしたことです。しかし、Git は類似点を自動的に検出して何が起こったかを推測しません。何が起こったのかを Git に伝えるにはどうすればよいですか? さらに良いことに、2 つのソース ファイルが結合されたとき、または 1 つが分割されたときに自動検出するように設定するにはどうすればよいですか?

質問 (2) と (3) は関連性が高いと思います。ご協力ありがとうございます。

4

3 に答える 3

39

開発プロセスのより多くの制御と標準化が必要なようです。変更をコミットするのは、ファイルを変更するのと同じ人でなければなりません。または、少なくともコミッターは何が変わったかを正確に知っている必要があります。

の出力を注意深く調べgit diff、フラグを使用して-wスペースを無視します。行内の違いを表示するオプションもあります。以下の行内の差分を参照してください。

コミット時にスペースの変更をスキップするようにgitに指示することはできないことに注意してください。GitX（「brotherbard」フォークが好きです）を使用することをお勧めします。これにより、コミットする前にハンクをインタラクティブに破棄できます。

コミットするときは、説明メッセージを使用してください。たとえば、ファイルが分割されている場合は、そのように言います。コミットを小さくします。長いコミットメッセージを書いていることに気付いた場合は、コミットを小さな部分に分割してください。そうすれば、後でログを調べるときに、何が変更されたかがよりわかりやすくなります。

行内の差分

Gitには、「単語」の違いを1行で表示する機能があります。最も簡単な方法は、を使用することgit diff --color-wordsです。

ただし、構成を使用して「単語」の意味をカスタマイズするのが好きdiff.wordRegexです。plainまた、違いがどこにあるかをより明確に示すため、word-diff形式も気に入っています（色の使用に加えて、変更の前後に角かっこを挿入します）。

指示：

git diff --word-diff=plain

私の設定でこれと一緒に：

[diff]
        wordRegex = [[:alnum:]_]+|[^[:alnum:]_[:space:]]+

この正規表現は、これらを「単語」として扱います。

  • 英数字とアンダースコアの連続した文字列
  • 非英数字、非アンダースコア、および非スペースの連続した文字列（演算子の検出に適しています）

gitを使用するには、の最新バージョンが必要wordRegexです。git-configオプションがリストされているかどうかを確認するには、マニュアルページを参照してください。

アップデート

ファイルの名前を変更するために使用する場合git mv（別のツールまたはOSを使用して名前を変更するよりも望ましい）、gitが名前の変更を検出していることがわかります。ファイルの内容の編集とは関係なく、名前の変更をコミットすることを強くお勧めします。これは、gitが実際に名前を変更したという事実を保存しないためです。つまり、ファイルがどれだけ変更されたかに基づいてヒューリスティックを使用して、同じファイルであるかどうかを推測します。rename-commit中に変更する回数が少ないほど、良い結果が得られます。

ファイルの内容を少し変更した場合は、-Cparam togit diffを使用git logして、コピーと名前の変更を検出するためにさらに努力することができます。パーセンテージ（例-C75%）を追加して、gitが違いについてより寛大になるようにします。パーセントは、コンテンツが一致と見なされるためにどれだけ類似している必要があるかを表します。

于 2012-09-14T16:26:43.930 に答える
3

Git について多くのことを知ったので、自分自身の質問に答えることができます。

  1. プロジェクトの異なるバージョン間ですべてのファイル間の空白を標準化するために、正規表現を使用してグローバル検索置換を実行することをお勧めします。これにより、それらが順次コミットされたときに、空白の変更がコミットを必要としなくなります。そうは言っても、Atlassian SourceTree の diff ツールを使用すると、空白の変更を非表示にできるため、少なくともそれらは表示されません。

  2. ファイル名の変更に対処するための鍵は、ファイルの名前のみが変更されるコミットを作成することです (他の変更をステージングしないでください)。次に、その内容が変更されるコミットを行います。そうすれば、大量のヒューリスティックや詳細な調査を行わない通常の差分ツールで、何が起こったのかを理解できます。問題は、名前や多くのコンテンツなど、ファイルに関する変更が多すぎる場合、ほとんどの差分ツールがそれを要約削除および新しいファイルとして扱うことです。（正解で述べたように）

  3. これはより難しい問題であり、これを回避する良い方法はありません。ファイルを 2 つに分割したり、2 つをマージしたりすると、差分が見にくくなります。分割と同時に多くの変更を加えないようにしてください。分割とその後の変更は別のものになります。

于 2016-03-09T01:54:55.380 に答える
2

  1. gitは各ファイルのハッシュを作成し、ハッシュが異なる場合はファイルが異なると見なされるため、gitにタブ/スペースを無視させることはできません。

  2. Gitはツリー（ディレクトリ）をファイルと同じように扱います。それらの内容が変更された場合、それらは異なるツリーのものです。

ただし、これらの変更について心配する必要はないと思います。それらは開発中に発生します。あなたにとって最善のアプローチは、gitを使用して開発を再生することだと思います。言い換えれば、最初のバージョンから始めて、（最初に行ったように）必要な変更を加えると、gitはあなたが何をしているかを記憶します。

オプション：変更の日付/時刻を大まかに最初に行われたものに記録する場合は、--dateコマンドラインオプションを使用してgit commit、これらの変更がいつ行われたかをgitに通知できます。

于 2012-09-14T15:49:19.667 に答える