2

これまで主に Windows 開発に使用されていた Git リポジトリがあります。Git EOL の問題 (LF と CRLF) のほとんどの側面は重要ではなく、開発は支障なく進行しました。
CMake ビルド環境に移行したので、UNIX/Linux/MacOS でコードをビルドしたいと考えています。コード自体は移植可能ですが、過去の経験といくつかの初期の実験から、Git が変更されていないファイルのディレクトリ全体を変更済みとしてマークし、ファイル内の変更されていないように見える行を検出し、大文字と小文字を区別しないファイル/フォルダー名を台無しにするなど、移行は多少面倒です。

さらに、Git 1.7.2 の時点で、Git には、各プラットフォームでの各使用が設定されるべき.gitattributesユーザーごとのグローバルではなく、ローカルのプロジェクトごとのチェックインに基づく新しい EOL システムがあるようです。.gitattributes

これらすべての問題なしに Linux でファイルをプルしてコミットできるようにするレポ準備パス/プロセス (Windows の場合) を誰かが提案できますか?

ここなどの部分的な提案を見ることができますが、それは強引すぎて、.gitattributes特にそのままにしておくことを意図したファイルを考慮していません(例*.sln)

4

2 に答える 2

0

一般に、VCS に保存する前にデータを自動的に変換しないでください (git IIRC では autocrlf=false)。そうしないと、データが変更されていないときに変更されたという誤検知が発生します。データが何を意味するかの「解釈」は、VCS の外部のツール (エディタなど) に任せてください。

偽の改行変更を防ぐには、次のことを考慮してください。

  • 書き換えられた改行のみで構成される変更を含むコミットを拒否する、ある種の pre-commit フックを設定します。
  • 改行の変更の影響を受けやすい少数のファイル (.sln、.vc* ファイルなど) のみを保護します。
  • チームが使用しているエディターを把握し、改行を偽って書き換えないように全員がそれらを構成していることを確認します。(ほとんどのエディターは、デフォルトで既にこのように設定されています。そのため、誰かがエディターに書き直してもらうまで、問題はありません。)
于 2013-08-19T05:44:50.717 に答える
0

私は Notepad2 を使用しています。これにより、デフォルトの行末を Linux (LF) に変更できます。

私の理解が正しければ、ソース ファイルを Windows マシンで LF に変更する必要はありません。Git は LF でチェックインしますが、Windows では CRLF でチェックアウトできます。

私にとって、これは大したことではありません。git を使用する場合、レポの内容を正確に確認したいと思います。適切な Windows テキスト エディタでデフォルトの行末を選択できる場合、git convert 行末を使用する理由がわかりません。私は、git が行末をいじることを許可しませんし、今後も許可しません。

于 2012-12-08T20:41:51.083 に答える