2

約 40 の開発者と 35,000 のファイルを持つ Gitolite を介して Git リポジトリを管理しています。私たちは CVS から切り替えたばかりなので、多くの人が違いに順応するのに苦労しています。

このような問題が発生すると、ユーザーは作業に Eclipse と EGit を使用します。CVS では、すべてのマージは Team Sync を介して行われ、競合は 3 方向差分ツールを介して解決されます。EGit では、マージの競合はマーカーで装飾されているため、開発者はこれらのマーカーを忘れたり、何らかの方法で削除されたと想定したりする可能性があります。競合はバッチ ファイルまたは構成ファイルにある可能性があるため、これらの問題のすべてがコンパイル エラーとして表示されるわけではありません。

<<<<<<<ツールの経験を積めば、これらの問題のほとんどは解決できるかもしれませんが、プッシュされた .java、.bat、.xml、または .properties ファイルをチェックして、正確に で始まる行、======= または>>>>>>>その後に他の行が続く行をチェックするフックを Gitolite に追加したいと思います。問題とそれが含まれるファイルを強調表示する警告メッセージをユーザーに追加します。

そうすれば、彼らがエラーを見つけ、すぐに修正し、間違いから学ぶことを願っています。別の方法では、一部のコードが正しく実行されない理由を考えながら何時間も無駄にする可能性があります。

正規表現は十分に簡単だと思い^>>>>>>>[^>]ます。では、Gitolite がこれを許可するかどうか、およびそのようなスクリプトをテストして作成するために必要な労力が問題になるのでしょうか? これを行うスクリプトの例を誰かが持っていますか?

当面はユーザーに警告するだけですが、スイッチを切り替えて、後でコミットを完全に拒否したいと思います。

4

1 に答える 1

1

必要なのは、VREF を定義することだけです (これは単純な更新フックのようなものです)。

次に、レポ内の他の R/W gitolite ルールと同様に、この VREF ルールを適用できます (このルールを特定の人/ブランチ/フォルダー/ファイルにのみ適用できます)。

このフックのように、プッシュされているファイルのコンテンツを簡単に解析できます。

#!/bin/bash

while read old_sha1 new_sha1 refname; do
    echo "ns: " $new_sha1;
    echo "os: " $old_sha1;

    echo "----"

    git ls-tree -r $new_sha1 | cut -f 3 -d ' ' | cut -f 1 | while read file; do
        git cat-file blob $file
        # do your grep here
    done; 


done
于 2013-10-22T11:40:11.480 に答える