プログラマーがテストを使用して共有コードでより適切に連携できるようにするにはどうすればよいですか？
私たちは「最初に引っ張らなければならない」を繰り返し続けます（ちなみにこれはgitとgithubです）。次に、少しコーディングしてから、テストに合格し、コミットしてから、プルしてもう一度プッシュします。チュートリアルのリンクを提供し、しっかりと/一生懸命努力します。最新の変更により、2ダースのテストが中断されました。私たちはすべてを文書化します。人々を助けるために他に何ができるでしょうか。テストに合格する必要があります。今のところ、人気がない今日の変更をすべてロールバックしたいと思っています。私はその厳しい管理アプローチの大ファンではありませんが、おそらく次回それを行うという「最終的な」警告が必要になります。壊れたテストを修正する必要があることは明らかですよね？前回修正したので、「取らない」...
チームに問題を解決してもらい、そうするための自律性をチームに与えます。チームを集めて、問題や状況、目標を明確に述べるために最善を尽くします。要件のように述べ、方法を指定せずに何を行う必要があるかを定義します。開発者は問題解決者なので、これを解決すべき問題にします。つまり、耳を傾ける必要があり、理想的なソリューションをあきらめる必要があるかもしれませんが、チームがソリューションを所有していると、思いついたソリューションに従う可能性が高くなります。
あなたの要件は次のようなものかもしれません
1）自動ビルドは毎晩9:00に実行されるため、すべてのテストはそれまでに合格する必要があります。これを実施する方法をチームに尋ねてください（おそらく、ビルドを壊した場合はドーナツを持ち込む必要があります:)
2）ビルドは毎週水曜日にデプロイされます。火曜日までにテストに合格しなかった場合、リリースを見逃し、次のウィンドウまで遅延します。どうすればこれを実施できますか？
私がチームでこれを行うときはいつでも、彼らは私が口述してきたものよりも優れた解決策を考え出し、彼らはお互いにそれを実施し、ルールを実施するよりも重要なことに集中することができます。
チームが常にビルドを中断することが問題である場合は、全員が座って問題について話し合う必要があります。
マネージャーとして、ビルドサーバーにビルド可能なアーティファクトがない場合は、何も配信していないことを明確にする必要があります。何も配信しない場合の影響は何ですか？次に、1日の終わりまでにすべてを提供できるようにするために、チームが必要とするプロセス、プラクティス、およびツールを使用して、チームに問題の解決を試みさせます。 また、この日中にチームに他の差し迫った問題がないことを確認してください。そうしないと、デフォルトでそれらが優先されます。
これを行うには複数の方法がありますが、最終的にはチームがそれを行う必要があるため、チームが自分でこれを行うのに十分な時間（1日か2日など）を与えます。
...そして、それでも問題が解決しない場合は、この種の作業を行うための規律を備えた、より優れたプログラマーが必要です。
失敗をより目立たせようとしましたか？パブリックビルドラジエーター？ビルドが壊れたときに、コミットの内容とコミッターを説明して、コミッター/チーム/会社に電子メールを送信します（まあ、最後の1つは、かなり小さな会社がない限り、あまり良い考えではありません。
フィードバックループをできるだけ短くするようにしてください。開発者がコミットと明日の15分後にビルドを壊したことを知っている場合、反応できるという点で巨大違いがあります。
あなたがそれを間違っているように聞こえます-私は一般的なgitワークフローを意味します。ここにいくつかの提案があります：
私たちは「最初に引っ張らなければならない」を繰り返し続けます（ちなみにこれはgitとgithubです）。次に、少しコーディングしてから、テストに合格し、コミットしてから、プルしてもう一度プッシュします。
なぜ全員が同じブランチにコミットしているのですか？それはとてもsvnです:)。開発者や機能に固有の独自のブランチで開発させます。そこに何が侵入するかについて心配する必要はありませんが、変更を本番ブランチにマージしたら、すべてがテストに合格し、一般的に一流である必要があります。
そうすれば、プログラマーは分離されたコードを安心して開発でき（機能に取り組んでいるときは数日でも）、後で変更を本番環境に加えることを決定したときに、統合とテストについて心配することができます。
さらに一歩進めることができます-開発者が本番環境に直接プッシュすることを許可しないまったく代わりにスクリプトを提供して、変更をプッシュできるようにしますすべてのテストに合格した場合のみ。シンプル。
今のところ、人気がない今日の変更をすべてロールバックしたいと思っています。私はその厳しい管理アプローチの大ファンではありませんが、おそらく次回それを行うという「最終的な」警告が必要になります。
繰り返しますが、ブランチは何のためにありますか？この場合、次のことができます。
「本番」ブランチから「バグ修正」ブランチを作成します
「本番」ブランチから壊れたコードを削除する
「バグ修正」ブランチの壊れたコードを修正
「バグ修正」を「本番」にマージ
何がそんなに厳しいのですか？
一般に、バージョン管理ワークフローを改善してみてください（おそらく、それを支援するためにgitコンサルタントを雇いますか？）。これにより、プログラマーが壊れたコードを本番環境にコミットするのを防ぐことができます。
もちろん、悪いワークフローは壊れたコードをコミットする言い訳にはなりませんが、開発者の観点から考えてください。複数の人が同時に同じアプリで作業していて、全員が同じブランチにコミットしている場合、コードを壊すのは非常に簡単です。特に彼らが大規模なコミットを行い、テストが脆弱である場合、それがあなたのケースであるかどうかはわかりません。