23

私はGitflow の分岐モデル

がとても気に入っていますが、TDD サイクルをどこに配置すればよいかわかりません。テストを作成または合格するたびに (さらにリファクタリング後に)、単純に機能ブランチを使用してコミットする必要がありますか? サブブランチを作成し、「完成した」ユニットを機能ブランチにマージしますか? 失敗した各テストをコミットする必要がありますか、それとも成功した後にのみコミットする必要がありますか?

機能ブランチで現在行っていることは次のとおりです。

  1. テストを書き、コミットする
  2. 存在しないインターフェイスが原因で、テストでエラーが発生する場合があります。これを修正し、コミットを修正してください
  3. （現在は失敗のみ）テストに合格し、コミットを修正します
  4. リファクタリング、新しいコミット
  5. 1に行く
4

5 に答える 5

9

これが代表的なものかどうかはわかりませんが、1 人の開発者として言えば、私は git-flow を使用しており、新しい機能の (おおよその) 私のワークフローは次のとおりです。

  • 機能ブランチを作成する
  • (作業中) タグで失敗する高レベルの受け入れテスト (キュウリ) を記述して、@wip今のところテスト スイートから除外し、これを新しいブランチにコミットします。
  • (時々) エッジ ケースの統合テスト用に rspec リクエスト テストを記述し、それを機能ブランチにコミットします。
  • 機能の個々のコンポーネントに対して下位レベルのテスト (rspec/jasmine) を作成し、大まかに定義された「ユニット」ごとに、機能ブランチにコミットします。
  • @wip機能が十分に完成して受け入れテストに合格したら、タグを外し、合格したことを確認して機能ブランチにコミットします
  • git merge(ではなく)を使用して機能ブランチを開発ブランチにマージしますgit flow finish。これにより機能ブランチがそこに残るため、必要に応じて後で機能を更新できます。
  • ブランチが開発のためにマージされると、travis-ci が完全なテスト スイートを実行し、問題があればメールを受け取ります。(開発ブランチとマスター ブランチのみを .travis.yml ファイルに含めます。)

これは私の「理想的な」ワークフローです。実際には、これらのルールを大幅に破ります。テストを作成する前にテストされていない変更をコミットし、高レベルの受け入れテストを実際に具体化する前に機能の一部に取り組み始めます。など。基本的に私はプロジェクトにコミットする唯一の人なので、それを行う自由があります。より大きなグループで作業している場合は、ワークフローに固執することについて、より厳密にする必要があると思います.

とにかく、それは私がそれを行う方法です。他の方の意見も聞きたいので、質問に賛成票を投じました。

アップデート：

これを書いた後、上記の流れから逸脱する 1 つの意味があることに気付きました。それは、厳密に言えば、通常のユーザー指向の種類ではない「機能」を追加する場合です (つまり、ユーザーが認識するものではありません)。の）。たとえば、アプリの開発の早い段階で、js コードを構造化するために backbone.js を使用することに決めたので、backbone.js の機能ブランチを作成し、@javascriptさまざまな既存の cucumber 機能にタグを追加しました。ブランチが (backbone.js を使用して) 元のアプリが HTML ビューで行っていたことを大まかに実行できるようになったら、マージして戻しました。

また、require.js の使用に切り替えることも計画しています。この場合、これを行うためのフィーチャー ブランチも作成し、完了したらマージして戻します。高レベルの統合テストはありません。既存のテストに合格する限り、すべて問題ありません。

于 2012-08-16T11:21:21.297 に答える
6

適切でシンプルなガイドラインは、「グリーン」になるたびに、または少なくともすべてのテストサイクルでコミットすることだと思います。

  • 赤 -> 緑 -> リファクタリング ->コミット
  • または赤 -> 緑 ->コミット-> リファクタリング ->コミット
于 2012-08-17T11:00:55.887 に答える
4

私のワークフローは非常に似ていますが、ステージング エリアをより有効に活用することを考えてください。

  1. テストを書いて、git add します。
  2. 存在しないインターフェイスが原因で、テストでエラーが発生する場合があります。これを修正して、git add してください。
  3. (現在は失敗のみ) テストをパスし、git commit します。
  4. リファクタリング、git commit 修正。
  5. 1へ。

これにより、すべてのコミットですべてのテストがパスするという規則が強制されます。ステージ 1 ～ 3 では、git checkout を使用して、いつでも最後の git add にロールバックできます。

于 2016-06-09T09:19:46.517 に答える
2

いつコミットすべきかを考える簡単な方法は次のとおりです。

  1. 意味のあるコミットメッセージでコミットしていることを説明できますか?
  2. この時点に戻りたい、またはこの時点とは異なる理由はありますか?

つまり、本当に人によるということです。ステージの 1 つで diff を実行していないことに気付いた場合は、おそらく変更内容を覚えているほど迅速に修正したために、実際にコミットする必要はありません。ただし、コマンドを入力するのにかかる時間を除いて、害はありません。

ステップが長期的なコミットを保証するものであると本当に感じていない場合の別の代替手段は、git add. そうgit diffすれば、追加後に何が変更されたかがgit diff --cached表示され、以前に何が変更されたかが表示されます。コミットがコンパイル可能で、単体テストに合格することを好むため、これが私が行うことです。そうすれば、既知の良好な状態に簡単に戻ることができます。

于 2012-08-16T13:04:40.710 に答える
1

TDD に固有のコミット ワークフローがあるとは思いません。私が従おうとしている唯一のルールは、壊れたテストを含むコミットをマスター ブランチにプッシュしないようにすることです (既に壊れていない限り)。私の機能ブランチでは、通常、機能関連のテストのみがテストされますが、マスターへのマージを実行するときにすべてのテストが精査されます。コミットによって一部の機能テストが壊れたままになっていることがわかっている場合、または他の理由で壊れていることがわかっている場合にのみ、それを wip として示します。より実用的な面では、コミットを間違ったブランチにプッシュしないように細心の注意を払うことには、より多くの利点があると思います。

于 2012-08-16T13:14:45.057 に答える