私が取り組んでいる会社では、ニーズに合わせて小さな開発プロセスを定義しました。コミットする前に、コミットコメントで問題について言及する必要があります。これにより、CIの内部フックがトリガーされ、ベータ環境で問題をテストできるようになります。
私たちのプロジェクトは現在GitHubでホストされており、適切に構成されたJenkinsCIサーバーもあります。疑問は、「コミットする前に、開発者に問題について言及させるにはどうすればよいか」です。。Git Hooksが役立つかどうか疑問に思っていましたが、フックは開発者のマシン上でローカルになっているようです。
誰かがこれで私たちを助けることができる何かを知っていますか？
あなたのアプローチには微調整が必要だと思います。Git は、頻繁にコミットする場合に最適になるように設計されています。たとえば、複数のファイルへの小さな変更を個別のコミットとしてコミットすることがよくあります。後の変更は、押しつぶしたり、チェリーピックしたり、リベースしたり、再配置したりできます。しかし、すべてのコミットを問題に関するものにすることを強制すると、コミットが少なくなり、開発者にとっては良くありません。
さらに、コードにはバックアップが必要です。リモート サーバーにプッシュする場合は、コードを 2 つの場所に配置し、開発中に他のユーザーと "共有" する簡単な方法です。別のブランチである限り、コードの問題を解決する優れた方法です。
私が知る限り、あなたの問題は粒度と「メイン」リポジトリとしてのgithubリポジトリの概念にあります。特定の問題に対処するコミットのブロックを一般的にテストするためにのみデプロイしたい場合は、マスターへのコミットごとに中央の github リポジトリのコピーをプルするが、統合をトリガーするだけの git リポジトリを用意します。コミット コメントに記載されている問題がある場合のデプロイからテストへのプロセス。このようにして、開発者は必要に応じて中間コミットをプッシュでき、特別なことを意味することなく必要に応じて開発ブランチをプッシュでき、問題を修正するコミット ブロックのみが展開/統合を引き起こします。
コミット メッセージを強制的に特定の形式にしようとしている場合 (つまり、常に特定の形式で問題が発生している場合)、事前受信フックが唯一の方法である可能性があります。
私たちのチームは最近、チケット番号を参照していない価値のないコミット メッセージという同じ問題に遭遇しました。
これに対処した方法は 2 つあります。
メッセージの解析に正規表現を使用するローカル フックのインストールを開発者に強制することを検討しましたが、開発者が (stash ではなく) すばやくコミットしたい場合があり、後でリベースでき、ローカルでフォーマットに従う必要がないため、このアプローチを採用しないことにしました。