問題タブ [gitattributes]

製品固有の問題について議論する場所ではないことは承知していますが、Git GUI 製品で発生する Git 固有の質問をするようにしています。

Phing PHP ライブラリのソース コード ヘッダーには $id$ 表記があり、Git GUI 製品はこれらのファイルに SHA-1 gitattribute フィルターを拡張し続け、変更されたバージョンとして表示します。これがどのように見えるかは、以下のスクリーンショットをご覧ください。

誰かが gitattribute ファイルでこの組み込みフィルターを無効にできますか? PHP ファイルにのみ適用できます。

.gitattributesファイルで次の行を見つけました

どういう意味ですか？

.gitattributes を使用して、親のディレクトリを無視し、子のディレクトリを含めるにはどうすればよいですか?

たとえば、/configディレクトリを考えてみましょう。ルートには/configディレクトリがあり、そこにもディレクトリがあります/app/config

追加する

ルートの問題を解決します/configが、サブディレクトリも削除し/app/configます。

サブディレクトリを保持するにはどうすればよい/app/configですか?

最初に、私はこの質問を知っています特定のファイルで競合するマージのために常にローカルバージョンを選択するようにgitに指示するにはどうすればよいですか? しかし、この投稿は役に立たず、私の評判のためにコメントを追加することはできません.

http://git-scm.com/book/en/Customizing-Git-Git-Attributesは、カスタム マージ ドライバーを設定する代わりに、パスのマージ戦略を私たちのものに設定することを提案しています。

終了コード 0 を返すカスタム マージ ドライバを追加する利点と違いは何ですか?

リポジトリの最上位に .gitattributes ファイルがあります。

しかし、pom.xml ファイルが変更された 2 つのブランチをマージすると、マージを解決できません。

そして、標準のマージ競合の結果が得られます。

私は何を間違っていますか？

汚れ/きれいなフィルターに関連する多くの関連する質問があります-私はそれらを読んで、さまざまなオプションを試してみましたが、まだ失敗しています. 自分に合った答えが得られるように質問できればと思います。

具体的には、これらの回答のほとんどが次のページにリンクしているページを読みました。

• Git のカスタマイズ - Git 属性

---

tl;dr

詳細な質問ですが、要約は次のとおりです。

• スマッジ/クリーン フィルタを使用してファイルを管理するために、DEBUG = falseあるブランチのファイルと別のブランチにファイルを保存できますか? DEBUG = trueそしてどうやって？

---

バックグラウンド

bitbucket でホストされているさまざまなリモート リポジトリがあります。リモートリポジトリをラップトップに複製するために、Win8でSourceTreeを使用しています。開発、機能、リリースなどのためにさまざまなブランチを作成します (良くも悪くも成功した Git ブランチ モデルに従います)。

Dbug.javaコード内のさまざまなデバッグログ、モックなどの機能をオン/オフするブール値を含むAndroid Java クラスがあります。

この値をfalse「本番」(マスター) ブランチにtrue置き、フィーチャー ブランチに置きたいと思います。

• これはフィルターを使用して可能ですか、それともユースケースをすでに誤解していますか?
• ローカルでホストされている同じリポジトリの 2 つのブランチ間でフィルターがこのように機能するのか、それともフィルターが 2 つのリポジトリ間でのみ機能するのかはわかりません。

---

フィルターの作成

ローカルで作業し、プロダクション ブランチを調べました。debug_flag.txt次の内容で呼び出されるテスト ファイルを作成しました。

というローカル リポジトリのルートにファイルを作成し、.gitattributesそれにフィルター参照を追加しました。

.git/configフィルター定義でファイルを更新しました。

• 私の理解では、これにより、本番環境では常にファイルの値が false になるはずですが、本番環境から分岐すると true の値になります。
• これは正しい理解ですか？

---

フィルタのテスト

test以下を使用して新しいブランチを作成しました。

ファイルの内容を確認しました：

• trueファイルに値が表示されることを期待していました
• ファイルをチェックアウトしたときに「汚れ」フィルターが実行されているはずではありませんか?

ファイルに新しい行を追加し、コミットしました。その後、本番ブランチに戻りましたが、ここで奇妙なことが起こりました。

SourceTree でファイルを見ると、このブランチは作成されてから変更されていません。唯一の変更は別のブランチで行われたため、それは私が期待することです。

ターミナルまたは Notepad++ でファイルを見ると、値が変更されていることがわかります。

私はまだテスト ブランチから変更をマージしていません。プロダクション ブランチでコミットしていませんが、ファイルが変更されています。

• このブランチ内のファイルに対してスマッジ フィルタが実行されたようですが、ブランチ間では実行されませんでした。

---

パズルの重要なピースが欠けています。できれば、これを行った経験のある人が見つけられる単純なものであることを願っています。

私の賭けは、これは概念の単純な誤解です。

欠落している情報がある場合は、プロンプトを表示してください...

---

VonC の返信に基づく更新

基本的なフィルターの設定は非常にうまくいきました。configファイル内のフィルターを次のように定義しました。

新しいブランチを作成すると false -> true が修正され、マージ バックすると true -> false に変更されます。

変更を本番 (マスター) ブランチだけに限定するには、実行元のブランチを認識するカスタム スクリプトが必要でした。したがって、configファイルは次のようになりました。

master_clean.sh:

master_smudge.sh:

この時点で、デバッグ ファイルの内容について、SourceTree で表示されているものと Notepad++ で表示されているものとの間に矛盾が生じています。SourceTree には変更が表示されていますが、Notepad++ には表示されていません。

私が提起した基本的な質問に答えているので、VonCの答えを受け入れています。

ただし、解決しようとしている根本的な問題を (私にとっては) 簡単な方法で解決するため、私が書いたソリューションを実装する可能性があります: 別のブランチに別の構成ファイルを保持します。

Windows ボックスと git リポジトリの 1 つで実行されている TeamCity (8.1) に問題があります。少数のファイル (1000 のうち 2 - *.bytes 拡張子、バイナリ) は、TeamCity チェックアウトで開発者マシンよりもサイズが大きくなります。「行末を CRLF に変換」をオフにすると、これらのファイルのサイズは同じになりますが、プロジェクトの残りの部分は正しくビルドされません + 開発者のマシンには core.autocrlf=true があります。

.gitattributes で *.bytes をバイナリとして設定しようとしましたが、これは TeamCity によって無視されているようです (?)。

これを機能させる方法を知っている人はいますか？

ありがとう

マージの競合によってファイル全体が競合するという問題がありました。これは、マージ時にローカル ファイルの改行がすべて unix スタイルの改行 (LF) になることになりました (マージ前に、開発ブランチと機能ブランチの両方がチェックアウト時に CRLF 改行を持っていました)。

走ったら

git status に変更は表示されません。しかし、.gitattributesファイルを削除して別のファイルをすべて削除/追加すると、特定のファイルが別の新しい行で更新されました。たとえば、100 行のファイルの場合、100 行が削除され、100 行が追加されます。両方のブランチに対してこれを行った後、マージは問題ありませんでした。

.gitconfigautocrlf = trueが設定され、.gitattributes ファイルにはこれらの行しかありませんでした。以下の行は、マージ戦略にのみ影響すると思います。

この .gitattributes が新しい行のコミット方法を変更するのはなぜですか?

また、autocrlf を true に設定すると、.gitattributes 内の何かがそれをオーバーライドしていない限り、なぜマージが LF と CRLF を比較するのかわかりません。

---

https://help.github.com/articles/dealing-with-line-endingsから

必要に応じて、特別な .gitattributes ファイルを構成することで、リポジトリごとに Git が行末を管理する方法を構成できます。このファイルはリポジトリにコミットされ、個々の core.autocrlf 設定をオーバーライドして、Git 設定に関係なく、すべてのユーザーに対して一貫した動作を保証します。.gitattributes ファイルの利点は、ライン構成がリポジトリに関連付けられていることです。

これにより、.gitattributes が autocrlf をオーバーライドできることは明らかですが、eol 変換を実行するように指示する設定はありません。おそらく、暗黙的に使用されるデフォルトがいくつかあります。