私たちのチームでは通常、すべてのタスクを別々のブランチにプッシュし、その後、リリースマネージャーがそれらのブランチを確認して「マスター」ブランチにマージします
チームメンバーが（プッシュする前に）ブランチをマスターブランチとマージするのを忘れることがあります-だから私がやろうとしているのは-ユーザープッシュの後に「マスターとマージしてください」というメッセージを出力する-私はポストで何かをチェックする必要があると思います-リモートの受信フック..いくつかの例はありますか？..または基本的に何をすべきですか？
更新：これの主な理由-潜在的な競合の数を最小限に抑えます（コミッター（リリースマネージャーではない）がそれらを解決するため）
出力がある場合git cherry new-branch master、誰かがプッシュする前にリベースしませんでした。
これを行う良い方法は本当にありません。かなりの数の問題がありますが、最も明白なのは、マスターからのリベース/マスターへのプッシュ操作がアトミックではないことです。つまり、誰かがその間に何かをプッシュする可能性があります。むしろ、リリースマネージャーの作業をはるかに簡単にするGitoriousなどの外観をお勧めします。彼はコミットに含まれるものを簡単に確認でき、コミットを簡単に受け入れ/拒否できます。
しかし、 git-wtfが役立つかもしれません。それでも自動化されたソリューションを試すことを主張する場合は、ローカルリポジトリとリモートリポジトリを比較する方法を示しています。
「マスターとのマージ」とは、実際にはマスターの上にリベースすることを意味すると思います。
すべての開発者は次のことを行う必要があります。
リリースマネージャーが早送りできるようにするには、ブランチを確認した後でのみマージします。
何らかの競合が発生した場合は、同じリリースマネージャーが開発者に通知し、（再び）マスターをプルしてリベースするように依頼する必要があります。
そうすれば、リリースマネージャーではなく、開発者だけが競合の解決を担当します。
リベースとマージを参照してください
自動プロセスの場合、マスターへのマージを実行しようとする中央更新フックを使用して、「早送り」がコマンドの出力の一部であるかどうかを確認します。そうでない場合、フックは。で失敗しgit send-emailます。
現在、そのようなスクリプトの例はありません。
あなたは本当に交差するマージを維持したくありません。トピックブランチをマスターにマージするか、ブランチを分離したままにしてマスターからマージする必要があります。
おそらくあなたが探しているのは、プッシュされる前のブランチがマスターに基づいてリベースされることです。これにより、コントリビューターがすでにほとんどの競合を解決しているため、潜在的な競合の数が最小限に抑えられます。