私は、すべての変更を追跡して、昨日コードをどこで壊したかを把握することと、物事を正常に保つ制御された (オーバーヘッドの高い) コード レビュー プロセスとの間の矛盾に苦しんでいます。
私は非常に伝統的な ClearCase ショップで働いています。すべてのチェックインにはコード レビューが必要であり、私にはプライベート ブランチを作成する権限がありません。私の日常業務すべてをバージョン管理したいという衝動を満たすために、クリアケース ビューで mercurial を使用しています。
私は、クリアケースの人々とできるだけうまく遊びながら、私の日々の変化を追跡するための最良の方法は何かについて、集合的な知恵を求めています.
早くそして頻繁にコミットします。同僚は、コードレビューが小さいことを高く評価し、変更の管理とマージが容易になります。小さな作品を噛み砕いて、それをコミットすることに集中してください。
日々の変化を追跡する上で、どのような問題に直面していますか？クリアケースの差分を実行すると、何が変更されたかがわかります。
私はタナシウスとスティーブンと一緒です。個人的な変更を追跡するために Mercurial を使用しているからといって、レビューのために ClearCase に早期に送信できないわけではありません。問題はmercurialでもClearCaseでもなく、誰かがレビューするために4780行のコードを提出しています。
また、厳格なレビュー ポリシーと Perforce を備えたショップで働いています。私はローカルの小さな変更を追跡するために git を使用していますが、変更が大きくなって同僚が理解できるようになる前に、レビューのために送信します。
早期にコミットし、小さくコミットします。
私は ClearCase に精通していないため、私の回答の範囲はmercurialのみになります。
私はあなたの次の問題を考慮します:私は変更をローカルで追跡して、ステップが不完全/壊れていてもステップを保存できるようにし、レビューのために全体像を送信しますが、コミットが大きすぎて簡単にレビューできないことがよくあります. 私は正しいですか？
この特定の問題を解決するために、私はMercurial Queuesを使用します。これらのキューを使用すると、基本的にローカルのプッシュされていないコミットを編集したり、並べ替えたり、いくつかのパッチを単一のパッチに折りたたんだり、1 つのコミットを小さな読み取り可能なチャンクに分割したりできます。詳細を読む前に、それらの使用方法に関する私の提案を次に示します。
fold同様のパッチをまとめます。たとえば、n、n+1、n+2 を連続して試行した場合、n+1 は n を部分的に元に戻し、n+1 はタイプミスのワンライナーです... 3 つのコミットを 1 つの意味のあるコミットにマージするだけです」このコミットは、これとあれを行う問題 #1212313 を完全に修正します。