ソースコードをチェックインする前に、どのような良い習慣がありますか？
私のチームはソース管理にTeam Foundation Serverを使用しており、チェックインする前にいくつかのバグを修正してテストアプリケーションを実行しましたが、コードにコメントするのを忘れていました。 （このコードはUIを少し奇妙にしました。）
コードをチェックインする前に、どのような良い習慣があるのか知りたいのですが、この種の間違いをもう一度したくありません。
チェックインする直前に、チェックインしようとしているすべてのファイルの差分を常に確認することです。
コメントアウトされたコードをチェックインしないでください。チェックイン前にコメント化する必要があるコードがある場合、それは間違っています。
ルールに関しては：
- 最新を取得
- マージの競合を修正する
ビルド
3.1ビルドエラーを修正する
テストを実行する
4.1壊れたテストを修正する
1に移動します（取得する新しいものがなくなるまで）
すべてのステップが完了したときにのみチェックインしてください。
チェックインダンス を参照してください。
その他の良い習慣：
- チェックインするファイルのリストを確認して、それらが予期したファイルであることを確認します。
- 各ファイルの変更を確認します（削除/追加/差分）
ここではパンツイタチになりすぎないようにしていますが、この質問の仮定（および答えの1つを除くすべて）は、TFS、SVN、Perforceなどの集中型VCSにほとんど当てはまります。
まあ、それはOPが使用しているものです。
一方、DVCS（MercurialやGitなど）を使用している場合は、通常、チェックインを待つ必要はありません。また、回答で言及されているほとんどのこと（差分、最新の取得、マージなど）は必要ありません。 。コードレビューやテストのようなものでさえ、チェックインの後に行う方が良いでしょう（おそらくプッシュする前に、に応じて...）
ここで（これまでに）見た唯一の例外は、ワークアイテムとの関連付けです。もちろん、チェックインについてのコメントも良いです...
他の回答には見られなかった3つのこと：
新しいファイルを含める
- チェンジリストに含まれていない新しいファイルを探します
- PERFORCEのようなSCMに固有である可能性があります。変更点をすべて伝える必要があります。
変更されていないファイルを元に戻します
- 他の人の変更を見ていて、9つのファイルを含むチェンジリストがありますが、変更されたのは3つだけです。
- また、空白やその他の意味のない変更を含むファイルを元に戻します。
送信したコミットを確認してください
- コミット後もビルドが緑色のままであることを確認してください。
- 以前は、コミット後に同期、ビルド、実行する2台目のマシンを使用していたため、何か問題が発生した場合でも、簡単にジャンプして修正できました。
Gitを使用する際の2つのこと：
アトミックコミット：
- コミットのために個別の機能変更のみをステージングします。
- コミットをできるだけ小さくします。パッチの適用、復帰、理解を容易にします。
- 必要に応じて、
git add --patchを使用して、変更を複数の部分に分割します。
要約しながら差分を表示
- 私は常に
git commit --verboseでチェックインするので、コミットメッセージを入力しているときに変更の差分を確認できます。 （または、パッチを当てた git-vim を使用して差分を表示します。） - これにより、変更を確認し、コミット全体を説明するのがはるかに簡単になります。この段階で、意図しない変更が発生することがあります。 （変更について説明すると、それについて考えるのに役立ちます。）
呪いの言葉を検索して置き換える;-)
私のチームのサーバーに適用する「グッドプラクティス」のいくつかの項目は、非常に簡単です。まず、チェックインする前に、常に最新の状態にしてローカルビルドを実行し、コードが競合することを他の誰かがチェックしていないことを確認する必要があります。さらに、サーバーではなくローカルマシンでのコードの競合に注意してください。最新のコードがダウンロードされたコードが正しくビルドされて動作することが確認されたら、次のステップに進みます。自動テストを実行し、チェックインを開始して、テストが引き続き正しく機能することを確認します。その後、念のため、最新の情報を入手してください。
TFS管理者は、すべてのチェックインにコメントを強制することができます。強制されているかどうかに関係なく、常にチェックインコメントを入力することをお勧めします。実行するオプションがある場合は、強制します。コメントが少なくとも、最後にコードをチェックインしてから変更した内容の一般的な概要であることを確認してください。これにより、何か問題が発生した場合にチェックインを確認して、おおよその内容を確認できますそのチェックインで変更されました。壊れたビルドのデバッグがはるかに簡単になります。
さらに、TFS管理者権限を持っている場合は、チェックインにローリングビルドを適用し（チェックインで問題が発生した場合に他の全員がすぐにわかるようにする）、ゲートチェックインを実行するようにサーバーを設定できます（チェックインされたコードがビルドを壊した場合、サーバーはそれを拒否します）、または単にバグを作成して、ビルドを壊した人にそれを割り当てることもできます。
他にもいくつかのオプションをオンまたはオフにして、すべてを順調に維持するか、TFS管理者にオンにして物事をきれいに保つように提案することができますが、それらは主に好みです
Windowsからチェックインする場合は、コードにこれらの非表示の^ M文字がないかどうかを確認してください。UNIXのエディターは、その原因となるエラー/警告を頻繁に出します。
また、タブを置き換えてみてください。ユーザーによってタブストップの表示が異なる場合があり、一部には4つのスペースがあり、一部には8つのスペースがあり、コードが読みにくくなります。
IMHOの最善の方法は、事前定義されたスクリプトで、組織のコーディングガイドラインに照らしてコードをチェックすることです。ソース管理システムの負荷にはこの機能があります。
私の会社ではチェックインレビューを使用しています。これらは詳細である必要はありませんが、チェンジリストの差分を誰かに見せて話し合うだけで、テストで見逃した奇妙なタイプミスが強調されることがあります。
ソース管理サーバーでは、コメントにレビューアの名前を（！initialsの形式で（たとえば、Bruce Wayneがレビューを行った場合は！BW））書き留めていない限り、チェックインできません。レビュー担当者は、レビューを支援したことを通知するメールを受け取ります。これは明らかに悪用される可能性がありますが、かなりうまく機能しているようです。
可能な限り、チェックインとワークアイテムを関連付けたいと思います。これにより、WHATが変更されただけでなく、なぜ変更されたのかに関するコンテキスト情報が提供されます。 TFSはかなりまともな作業項目追跡システムを備えているため、チェックイン時にこれを行うのはかなり簡単です。
（これは私の変更の差分を確認することに加えて）
私が行う1つの小さなことは、実際に変更されていないファイルをチェックインしないことです。これらのファイルは、誤って変更されているか、ロールバックされたか、他の方法で無効にされたリファクタリングに関与している可能性があります。
このようにして、（ワークアイテムに関連付けられた）チェンジセットには、ワークアイテムを満たすために必要なファイルが正確に含まれます。
ここですべての回答を組み合わせて完全なチェックリストを提供するには
[チェックイン/チェックアウト]他のユーザーが作業しているストリームに直接チェックインしないでください。ストリーム戦略を用意する必要があります。開発者ごとに、他の人を煩わせることなく独立してチェックインおよびチェックアウトできるストリーム：作業は安全ですが、独自の開発ストリームで行われるため、[独自の開発ストリームでのみ]。すべてのチェックインで変更レコードに関連付けて、変更セットと呼ばれる変更に対して変更がアトミックになるようにします（これにより、「すべて」を配信する必要なく、個々のrfcやバグなどを配布できます）。
[チームストリームでリベースする]は、自分のストリームで他のユーザーから変更を取得することを意味します。その操作中に、マージダイアログですべての「diff」を確認してそれらを確認できます。数千ある場合や、コードではなく、たとえばデータモデル/ Siebelプロジェクトなど...は、重要なマージ、重要でない自動マージ、重要でない手動マージのいずれかに依存しています。最後のカテゴリには、難しいマージが含まれています。自分のストリームで作業していることに注意してください。
[完全なリベース]すべて問題なければ、チームストリームから取得したすべての変更をチェックインします。独自のストリームが最新の状態になりました
[配信]今すぐあなたの仕事をチームストリームに配信します。すべてを提供したくない場合は、たとえば、その特定のバージョンのファイルまたは一連のRFC /欠陥が解決された1つの特定のRFC.
[テスト配信]うまくいくはずですが、配信されている間に誰かが変更する可能性もあるので、チームストリームの最新の変更で作業が機能するかどうかをテストできます。同じマージダイアログで違いを示します。
[完全なデリバー]あなたのデリバーを完了し、あなたの仕事はチームストリームになりました。
それをより複雑にする：あなたが提供した作業= okの可能性がまだあるので、あなたはすでに次のバージョンで作業しているので、常に配布後にベースラインを作成し、他のユーザーがリベースするのに好ましいベースラインを示す必要があります。これにより、他の開発者がストリームの最新バージョンではなく推奨バージョンを取得することが保証されます（そのシナリオで作業している場合）。これはトリプルチェックでもあるため、チームストリームの最新バージョンが「悪い」場合でも、他のユーザーがリベースまたは参照するバージョンではなく、構成マネージャーは以前のバージョンを次のバージョンにマージして元に戻すことができます。あなたの配達。
- histumnessからの答えは2回発生します：ステップ2と6で
- チェックインダンスに関するOdedからの回答：idemですが、チェックイン/チェックアウト時にデリバーとリベースの追加レイヤーがあり、分離された作業を確実にし、エラーは後の段階でもいつでも簡単に取り除くことができます
- answered guildsbountyからの回答：最新の取得はステップ2です。ビルドの場合：ビルドがあるかどうかによって異なります...私の世界では、データモデル、Wordドキュメント、要件シート、informatica、siebelの構成データからの入力があります。など、そしてはいJavaコード、.netコードなど...すべてが一緒に混ざるはずです。そのため、ここには実際の「ビルド」はありませんが、単一のもの、たとえば「コード」からのビルドは、それが統合のものであるかどうか確実にわからないので、それらのテスト環境によっては、コンパイルされたものが必要になるか、より高い配信で別のビルドが必要になるため別のチームの何かが必要です。
- コメントと必須に関するguildsbountyからの回答：バージョンと変更セット（およびタイプ：欠陥、RFC、hotfi）の変更が統合されていないすべての環境は成熟していないと思います。あなたができなければ、私はその混乱を考える。送信されたバグとrfcの量を使用してリリースノートを自動化します。これらはクリックされた正確なバージョンまでクリックできます（たとえば、hello.cのバージョン1とバージョン3は非常によく配信されますが、バージョン2は配信されるべきではなかったためです）以降のリリースの一部になるでしょうが、一部のnoobはすでにそれを組み込んでいます）（したがって、hello.cのバージョン3も取り出したい場合は手動で決定する必要がありますが、バージョン3を取り出すと、すべてを取り出す必要もあります他のバージョンはそのRFC /欠陥に触れているので、完全なものを取り出すためのツールで簡単かつ高速にできる必要があります）（複数の開発者が同じRFCの一部に取り組んだ場合でも）少なくとも、決定するためにその周りのものが必要ですその上など...）追加のドキュメントは常に便利ですが、変更セットを関連付けることにより、完全な円が得られます。バージョン<-変更セット<-作業項目<-チケット/ rfc /欠陥<-要件。意味：どの要件が完全にまたは完全に提供されているかがわかります。1つの要件に複数のRFCやバグなどがあります。 RFCには、複数の人のための複数の作業項目があります。その作業項目は、一連のバージョンの存在する変更セットに対応します（たとえば、開発ストリームのバージョン1、2、3、4、5ではなく、統合ストリーム上のhello.cのバージョン1および3は、そのバージョンです。統合ストリームの3は対応します）（したがって、バージョンツリーとそれを操作するツール）
- luis.espinalからのコメント：ビルドを中断しないでください。ビルドはリベースでダブルチェックされ、引き続き配信されます。変更セットとベースラインを情報として表示する必要がある「リリースマネージャーとビルドマイスター」には、より上位の配信があります。 「メインブランチで直接作業しない」はい、ストリーム構造は大きくても単純でもかまいませんが、本質的には、開発者には独自のストリームがあり、リリースストリームに配信するチームストリームに配信します。 ->すべてのチーム（ドキュメントチーム、要件チーム、開発チーム、テストチームなど）からの配信がチームストリームに含まれ、リリースマネージャーまたは構成マネージャーがリリースに含めるベースラインを取得して、正しいテストバージョンを備えた正しいドキュメント正しいコードバージョンを備えた正しい要件を備えたdocs/outcomesは、すべてリリースに対応しています。
あなたの例では、コメントアウトしたコードを忘れたことを示しています。間違いが起こります。その周りの構成管理システムがそれを処理する必要があります。それは本当にそれであることができます。何千もの変更が発生し、「ビルド」と「統合」が連鎖的に処理され、時間内に処理されるさまざまなサーバー上のストリームの階層で行われます。コードが他のコードやシステムとの統合を必要とするため、5か月後、コメント化されたコードが統合サーバーでテストされたとしても、変更セットをアトミックに取り出して続行できるはずです。したがって、ベストプラクティスは、多かれ少なかれ、より高いレベルです。構成管理ストリームの全体的な設計は、それを処理する必要があります。個々の開発者にとって、ベストプラクティスはもちろん、検証/単体テストです。しかし、全体像から「機能させる」ためのベストプラクティスは、システムをフォローし、関連する変更セットのメタ情報を常にチェーンの後の方に提供することです。
以下の一部は、SCMに応じて他のもの（または異なる形式）よりも適用されるため、ここに適用されます。
- ビルドを壊さないでください-コンパイルするコードのみをチェックしてください。
- チェックインにコメントします（SCMがそのオプションを提供している場合は、チェックアウトにコメントすることもできます）。
- 長い間、チェックを外さないでください。
- 頻繁にチェックインします（可能であれば1日に数回）。
- 意味のあるラベルを付けます。
- 定期的にラベルを付けます。
- Mainブランチで直接作業しないでください。
- 製品版へのすべてのリリースには、独自のラベル（および、可能であればメインブランチからの読み取り専用ブランチ）が必要です。可能な場合は、UAT /統合/本番前のテストリリースについても同じことを行います。
- SCMの内容とラベルから、製品の内容を正確に構築できるはずです。
[〜＃〜] note [〜＃〜]：上記の項目のいくつかはかなり明白に思われるかもしれませんが、実際にメインブランチで実際に作業している人の数や、最初にプロダクションに変更を加えている人は信じられないでしょう- そして手動でデルタを作成し、バージョン管理に進みます...メインブランチに直接...ラベルを付けます。発酵した胆汁のように、洗っていない脇汁を混ぜたような甘い...ええ、そのようです。
個人用のチェックリストを用意してください。エントリで、めちゃくちゃになったら空にしてください。それが第二の性質になったとき、それをリストから削除してください。
テストを実行します。合格した場合はチェックインします。失敗した場合にテストを通過した場合は、テストを作成します。
常に、常に、always、行った変更がビルドを壊さないことを確認してください。ささいなことのように思われる可能性のある特に小さな変更。
週末に仕事を辞める直前に、私が問題を引き起こすとは思わなかった非常にマイナーな変更をした後。案の定、この小さな変更はビルドを壊し、私たちのプロジェクトに対して毎晩のテスト実行は実行されませんでした。 Q＆Aの責任者はそれについてあまり満足していませんでした。
熱心に取り組んできた単体テストを実行します。緑がいい。
コードが適切にフォーマットされていることを確認します（例：Javaの場合：コードを選択し、EclipseでCtrl-Shift-Fを押します）。ただし、ドキュメント全体に対して同じことを行うように注意してください。
私たちは次のことを行います...
テスト-機能することを確認したい。少なくとも、何も壊さないことを知りたいのです。
コードレビュー、または少なくともバディチェック-これは、知識が広まり、人々が最新の状態に保たれることを保証する優れた方法です。また、チェックインする前にバグを見つけるのにも役立ちます。
事前通知の送信-チェックイン前にグループに事前通知が送信されます。目的は、変更されているファイルまたは領域を他の人に知らせるだけでなく、それらの変更が影響を与えることが予想される場合に備えて、（注意を払うことを選択する必要がある）ヘッドアップを提供します。
事前連絡後、数時間後にチェックインを行い、グループにメールで連絡します。グループの誰もが、バグまたは機能に関する特定の作業がいつ完了したかを知ることができます。
チェックイン通知のコピーが、バグまたは機能に関連付けられた修正レコードに貼り付けられます。レコードを検索すると、修正/機能が何を伴うのかを理解しておくと非常に便利です。
スタンドアロンユニットとして使用できる変更部分を探します。
多くの場合、コードに実際の修正または機能拡張があるときまでに、かなりの数の変更があります。それらのいくつかは、私がしようとしている行動の変化に固有のものです。他のものは、その変更をよりきれいにするために私が行ったリファクタリングです。
次のように、各リファクタリングを個別にチェックインし、独自の変更の説明を付けます。
リファクタリング：Xの名前をYに変更
Xは以前は理にかなっていたので...しかし、今はYになるはずです。これは、問題＃9の作業に関連しています。
次に、適切なリファクタリングがそれぞれチェックインされると、最終的な動作の変更は多くの場合ささいなことになります。
また、一部の変更は多くのコード行に影響を与えますが、それほど興味深いものではありませんが、他の変更は非常にローカライズされていますが、重要な影響があります。これらの変更をまとめてチェックインすると、差分を読み取るのが難しくなる可能性があります。だから、私はそれらを別々に保ちます。
後で、誰かが変更履歴を読んでいるときに、物事が現在の状況にどのように達したか、そしてなぜ彼らがこのようになっているのかは明らかです。また、他の多くの編集に煩わされることがないため、動作の変更を元に戻すのは簡単です。
私は仕事のためにローカルのhgリポジトリを保持しています。
- 何かをチェックインするときはいつでも、diffを調べて、すべての変更が受け入れ可能であることを確認します。
- チェックインの重要な機能に注目します。
- 各コミットサイズを1つの主要な機能に維持するようにしています。
私はこれらが最高だとは言いませんが、私にとってはうまくいきます。
誰かから借りたものを返すときはどうするか。清潔で状態が良いことを確認してください。混乱した場合は、コードを所有者（ほとんどの場合、雇用者）に返す前に必ずクリーンアップしてください。
チェックイン用ではないことがわかっているコードを書くときは、その前に「// TEMP：」を含む行を追加し、その後に「// END TEMP。」を追加します。これは、チェックインする前にdiffを実行することで、誤ってそのコードをチェックインしないことを約束します。
追加または変更したすべてを徹底的にテストします。考えられるすべてのケースを試してみてください。テストをQAに任せないでください。小さな変更を加えるたびにサンドイッチがあり、安全のためにいくつかのテストケースを試し、すぐに問題が発生した場合、サンドイッチがたくさんあります。私はたいてい自分に大声で言いました「試してよかったです...」
変更後、UIがおかしくなったそうです。チェックインする前にプログラムを実行してUIを確認しただけの場合、問題に気づいたでしょうか。