私が働いている会社は、Java プロジェクトを CVS から Git に移行するプロジェクトを私に与えてくれました。いくつかの理由から、彼らは Eclipse 以外のツールを使用したくありません。だから私たちはEGitにこだわっています。
コードをフォーマットするように Eclipse を構成できることは知っています。しかし、誰かがコードをフォーマットする独自の方法を使用することを妨げるものはないようです。
私の質問は、コードが正しくフォーマットされていない場合、EGit でコミットを拒否することは可能ですか? この質問の背後にある理由は、CVS で非常に大きな問題だったコード形式による競合を回避したいからです。
ありがとうございました
コミット中にコードをチェックする代わりに、レビューシステムとしてgerritが使用されるシナリオがあります。開発者は、コードをgitリポジトリに直接コミットするのではなく、gerritにコミットします。その後、GerritはJenkins / Hudsonサーバーでビルドジョブをトリガーでき、そのビルドジョブはCheckStyleまたはその他の任意の形式チェックツールを実行できます。
チェックが成功すると、Jenkinsは変更を検証してgitリポジトリにマージすることもできます（ほとんどのプロジェクトでは、Jenkinsがコードの正当性のみを検証することを好み、人間は後でコードを確認する必要があります）。チェックに失敗したコミットはgerritのままになります（そしてメールは開発者に送られます）。
このアプローチの利点は、コミットごとにスタイルチェックだけでなく、特に単体テスト、静的コード分析、コードカバレッジを実行できることです。主な欠点は、単なるgitフックよりも多くのツールをセットアップする必要があることです。
フォーマッターと保存アクションを設定して、コードをプロジェクト固有の構成としてフォーマットすることをお勧めします。.settings次に、Git でディレクトリを追跡します。
プロジェクトとバージョン管理で構成されているため、開発者は Eclipse を自分で構成する必要はなく、自動的に構成されます。
私たちはいくつかのプロジェクトでこれを行ってきましたが、最初からこれを行うと、不適切な形式のコードやそれに関する議論が発生することはありません。
開発者が本当に消極的で、プロジェクト固有のフォーマッタのチェックを外して別のフォーマッタを使用することさえする場合は、話し合う必要があるかもしれません。
(ちなみに、フォーマッタで推奨されるオプションは、すでにラップされている行を結合しない です。これは、フォーマッタが奇妙なラッピングを行う場合があるためです。このオプションにより、ラッピングを制御できます。)
コードが正しくフォーマットされているかどうかを判断する方法がわかっている場合は、フック pre-commit でこれを実装できます。
このフックは .git/hooks に配置する必要があります
git には pre-commit.sample と呼ばれるサンプルが付属しており、既に hooks ディレクトリにあるか、/usr/share/git-core/templates/hooks/ (Ubuntu の場合) にあります。