コミットされたコードが根本的に正しいことを確認するために手動でチェックを行うことなどがあることは知っています。しかし、その横に？私が尋ねる理由は、毎日非常に多くのコミットがある大きなプロジェクトだからです。
9 に答える
6
一般的に言えば、コミット通知は、日常的にコードで何が起こっているかを把握するのに役立ちます。たとえば、新機能がいつ実装されたか、またはバグ修正がチェックインされたかを知っています。コミットが多すぎてノイズの中で失われている場合は、表示されるコミット メッセージの数をフィルタリングまたは削減する価値があるかもしれません (おそらくたとえば、作業している特定のモジュールのみに制限できます)。
そうは言っても、他の開発者に少なくともざっとコードをレビューする機会を与えるだけでなく、次のことを人々に通知することもできます。
- ソース管理から更新を実行し、必要に応じて新しい変更をマージするのに適した時期です
- ねえ、誰かが Foo で正規表現解析のバグを見つけたが、それで Bar を更新するのを忘れていた
- ああ、ボブは Baz モジュールに取り組んでいます。これも見てもらうように頼まなければなりません
あなたはアイデアを得る。基本的に、これはグループ全体の透明性を促進することを目的としており、コミットに目を向けるだけでなく、チーム全体の開発サイクルを改善することを目的としています。
于 2008-10-10T01:18:22.487 に答える
4
あなた自身が取り組んでいるかもしれない 1 つ以上のプログラムに誰かが変更をコミットした場合に役立ちます。必要に応じて、さらなるコミュニケーションが必要になる可能性のある競合を解決する必要がある場合があります。
私は、プログラマー A がいくつかの変更をコミットし、数日後に休暇を取ったという状況を見てきました。プログラマー B も同じプログラムに取り組んでおり、プログラマー B が変更をコミットしようとしたときにいくつかの競合が発生しました。通常、これは大したことではありません。さらに、チーム メンバー間でコミュニケーションを常にオープンにしておく必要があります。この場合、プログラマー B はプログラマー A が行った変更についていくつか質問をしましたが、そのプログラマーが戻るまで 1 週間待たなければなりませんでした。この状況では、自動生成されたメールであっても、ヘッドアップ メールが役に立ちます。
ちょうど私の2セント。
于 2008-10-10T01:25:23.580 に答える
4
上記の多くは、チェックインの通知を受け取るときに役立ちます。私は通常、いくつかの目的でそれを使用します。
- プロジェクトが何らかの形で中断した場合、システムにチェックインが行われていることを認識しているため、問題をより迅速に突き止めることができる場合があります。より迅速に解決策を示してくれるかもしれません
- 簡単に検索できるチェックインのセットを提供します (少なくとも、電子メールで受信するため)。はい、ソース管理システムにはすべての情報がありますが、チェックイン コメント全体を検索するのは簡単ではない場合があります。電子メールの場合、戻ってユーザー、モジュール、キーワードなどを検索し、Outlook に関連する電子メールを吐き出させるのは、私にとって非常に簡単なことです。
- 若い開発者と彼らが何をしているかを簡単に追跡できます。彼らがいつコードをチェックインしているか、コードで何をしているのかを確認する機会を与えてくれます。コードレビューなど、定期的に予定されている他のこと以外でメンターを務める機会が継続的に与えられます。
- チームが進捗状況を追跡し、競合をチェックインしている可能性がある場合に注意する方法を提供します。
お知らせがたくさんあっても、全部読まなくてもいい気がします。私はそれらをざっと調べましたが、さらに情報が必要なときに適切なコミットに戻るには十分です。
于 2008-10-10T01:50:30.003 に答える
2
もちろん、自分のチームの他のメンバーが何をしているかを把握し、自分のコードを書くだけで洞窟に閉じ込められないように、コードが挿入されるのを目で見て確認する必要があります。
コードの品質を監視していなくても、他の人が何に取り組んでいるかを知ることができます。
チーム作りに役立ちます。
于 2008-10-10T01:16:05.097 に答える
0
主に追跡に役立つと思います。一般に、このような自動通知は、「smoketest 合格、smoketest 失敗」タイプの電子メールとともに、フィルタリングされて私のメーラーのバケットに入れられます。失敗した場合は、チェックインのセットにかなり簡単に追跡できます。
プロジェクトの成熟度は、チェックインの曲線の形状 (コード ベースの合計サイズの関数として 1 日あたりに変更されるコードの行数) によっても直感的に把握できることに注意してください。実際には、いつ「完了」するかについての合理的なアイデアが得られます...
お役に立てれば！
于 2008-10-10T01:15:33.803 に答える
0
多くの企業では、コード レビューは義務付けられていますが、名誉制度で行われています。電子メールで送信されるコミット通知は、これらの環境に「信頼するが検証する」メカニズムを実装します。
于 2008-10-10T02:35:13.643 に答える
0
通常、何かが更新され、ピアレビューが必要であることを全員に知らせるために、更新があります。1 人のユーザーを割り当てる必要がない場合は、時間があるときにそれを取得して処理できます。
コードスタイルのコメントログで、すばやく簡単に「何が変わったのか」をコミットすると、Twitter スタイルのメッセージを Yammer に送信するシステムを誰かが投稿したのを見ました。きちんとした。しかし、今はリンクを見つけることができません。
于 2008-10-10T01:18:06.683 に答える
0
私は主にプロジェクトのハートビートを測定するために使用します。各コミット メッセージはパルスです。やがて、「通常の」パルスが「聞こえる」のがどのようなものかについて、ある程度のアイデアが得られるでしょう。
通常、1 日に 4 ～ 6 件のコミット メッセージが届きます。イテレーションの日付が来ると 1 または 2 に遅くなり、イテレーションのリリースの約 2 日前に停止します。イテレーションの 1 ～ 2 日後、再び回復し始め、バグが見つかった場合、バグが修正されるため、1 時間に 1 つのコミット メッセージを取得できます。コミット数が少ない通常の日は、開発者が一部の機能に苦労しているか、stackoverflow に多くの時間を費やしていることを意味する場合があります。
また、有益なコミット メッセージが非常に役立つこともわかりました。場合によっては、マネージャーやテスターが開発者に機能やバグのステータスを尋ねる必要さえないことがあります。コミット メッセージを見て、何か作業が行われているかどうかを確認するだけです。
于 2008-10-10T02:57:23.020 に答える
0
私の理解では、開発者にコミット レポートを CC する主な理由は、競合を避けるためです。つまり、作業中のファイルにコミットが表示されるので、コミットする前から問題が発生していることがわかります。ただし、これはかなり気を散らすので、どのファイルが同時に編集されているかを実際に表示するツール (Palantir、古い IBM Jazz など) があります。
于 2008-10-10T04:52:49.683 に答える