Gitマージと2つのブランチを持つ混合スペースとタブの修正
私はいくつかの同様のSOQを試してみましたが、このケースに対する適切な解決策を見ていません。
多くのファイルで、インデントに使用されるタブとスペースのあいまいな組み合わせがあることに気づきました。私たちが従うコーディング標準では、現在タブに4つのスペースを使用しています。
この問題は発生時に対処されているはずですが、今検討する必要があり、遭遇したファイルを修正したいと考えています。問題は、コードの異なるブランチを使用する2つのチームがあり、最終的にそれらのブランチをマージする必要があることです。ブランチのすべてのファイルを正しいフォーマットに変更してマージしようとするとどうなりますか？最終的にそうするのは難しいでしょうか？それは私にたくさんの対立を示しますか？理想的には、空白を無視するためのgit mergeのようなidですが、どのバージョンを選択するのかを知る方法がわかりません。
対応の観点から見たより良い解決策はありますか？
これは主に技術のリーダーシップ、コードリント、コードレビューの問題ですが、私は現在、その立場やケースではありません。これは簡単に修正できますか？ （違反者にマージを処理させることは、残念ながら問題外です！）
デフォルトでは、gitは行のインデントの各違いを変更として認識します。そのため、はい、株式のマージを行うと大量の競合が発生する可能性があります。
ただし、-sオプションで使用するマージ戦略を選択できます。
git merge -s recursive -Xignore-space-change
このコマンドは、再帰的な戦略を使用し、ignore-space-changeオプションを使用します。 git-merge docs は、これがマージにどのように影響するかをよく説明しています。
- それらのバージョンが行に空白の変更のみを導入する場合、私たちのバージョンが使用されます。
- 私たちのバージョンが空白の変更を導入しているが、それらのバージョンに大幅な変更が含まれている場合、それらのバージョンが使用されます。
- それ以外の場合、マージは通常の方法で進行します
いくつかの追加オプションを付けてdiffを使用してマージを行う前に、gitが何を変更したかを確認することも賢明です。 diff docs を見ると、これらのオプションが最も役立つと思われます。
-b
-ignore-space-change空白の量の変更を無視します。これは行末の空白を無視し、1つ以上の空白文字の他のすべてのシーケンスを同等と見なします。-w
-ignore-all-space行を比較するときに空白を無視します。これは、一方の行に空白があり、もう一方の行には空白がない場合でも、違いを無視します。
少なくとも3つのブランチ（たとえば、「master」、「team1」、「team2」）があると仮定して、「master」ブランチをすべての正しい間隔/インデントで更新し、各チームに「master」からの変更を取り込みます。その後、各チームは、すべての新しいコード/ファイルが標準のコーディング方法に適合することを確認する必要があります。
両方のコードベースを indent で実行し、両方のブランチで同じスタイルを使用しないのはなぜですか？時間がかかりません。
そうすれば、空白や他の問題（異なるブロックスタイルなど）がなくなります。そうでなければ、はい、それらのブランチをマージするのは難しいでしょう。
もちろん、Cでコーディングするとします。
「 Git：空白の競合なしのマージ 」で述べたように、git merge -Xignore-space-changeは
- 競合がある空白だけでなく、ファイル内の空白の変更をすべて無視します。
- ただし、結果としてマージされたファイルは空白を取り戻します。
- を使って
pre-commitフックとそのマージ戦略を併用すると、末尾の空白を完全に削除できます。