1

コードのアトミックな変更を書いたとしましょう。また、変更が機能し、機能し続けることを確認するために、いくつかのテストを作成します。

テストと一緒にコード変更をコミットする必要があると思います。

プロ：

  • これにより、（可能な限り）ブランチのすべての変更セットでコードが実行され、テストに合格することが保証されます。
  • これらのテストは、私が行ったコード変更に「属している」ことを文書化しています。

短所：

  • 将来、テストを取り消さずに変更を取り消すことができます。

いずれかの方法でそれを行う理由は他にありますか？どちらの戦略もあなたを噛んだことがありますか？どのくらい正確に？

やや関連：コードへの変更は、テストスイートへの対応する変更とは別にコミットする必要がありますか？

4

2 に答える 2

2

私の唯一のルールは、チェックインする前にコードがビルドされることを確認することです。

はい、理想的には、コードのアトミックビットをチェックインする必要があります。しかし、どのようにアトミックを定義しますか？そして、後でビットの1つを変更する必要がある場合はどうなりますか？変更は1回のコミットではなくなります。

于 2013-03-26T15:03:13.827 に答える
1

テストと一緒にコード変更をコミットする必要があると思います。

私は決してそうしませんが、私が非分岐SCMを使用した場合はそうします。

SCMの分岐（私はmercurialとgitを使用しました）では、問題はありません。

仕事を始めるたびに別のブランチを使用します。私は多くの場合、しばらくの間他の場所に移動したとき、または主要なコード変更を開始する前にバックアップポイントが必要なときに、未解決の変更（コンパイルすらしない）をコミットするローカルブランチコミットを持っています。これらの中間コミットのほとんどは、作成時に二度とチェックアウトされないことを知っています。ただし、何も影響を与えず、必要なときに非常に役立ちます。

正常に実行されるコンパイルとテストを行うコードがある場合にのみ、ブランチをマージして戻します。

于 2013-03-28T12:01:40.607 に答える