Gitでのテストブランチの使用

新しい機能とバグ修正のテストを担当する人（Tedと呼ぶことにします）がいます。

GitとGitHubを使用しています。master常に展開可能である必要developmentがあり、新しい機能やバグ修正をコミット/マージする場所ですが、Tedによってテストされた後でなければなりません。

プロジェクトはPHPにあります。

テストプロセスは次のようにします。

1. 開発者は新機能（課題追跡に記載されているTedとしての機能/バグ＃123としましょう）に取り組みたいので、ローカルリポジトリにプルorigin/developmentし、そこからdevelopment新しいブランチ（としましょうissue-123）を作成します。
2. 作業に満足したら、新しいブランチをコミットしてにプッシュしoriginます。
3. Tedは接続しtest.ourproject.com/choose-branchてブランチのリストを確認し、originスイッチをオンにしますissue-123（Webページから実行できます）。その後、彼はに進みtest.ourproject.com、Webアプリケーションの地獄をテストし（彼は本当に無慈悲です）、開発者と何度かやり取りした後、彼は機能に満足しています。
4. テッドは、彼がマージすることができ、開発者告げるissue-123上にdevelopment上をorigin。
5. すすぎ、繰り返します。

3番目のステップでは、その仕事（特定のページからの分岐の表示と切り替え）をハッキングすることができますが、ここで説明したことは非常に一般的なパターンだと感じています。

だから私の質問は： これは分岐のための良い/持続可能な/保守可能なワークフローですか？このワークフローに従う他のプロジェクトの例をいくつか挙げて、回答を裏付けることができますか？

ブランチのワークフローはgitflow http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flowによく似ており、その周りにサポートツールがあります。強くお勧めします。

テスターが1人だけの場合、テストワークフローは適切に聞こえますが、複数の人がいる場合、開発は開始と終了の間を移動する可能性があります。もちろん、テストはマージ後に完全に実行するのが理想的です。これは自動化されたテストが本当に役立つか、遅い（徹底した）テスターが終了しない可能性がある場所です！

もう1つの問題は、多くの機能とブランチで、機能をリリースに混合して一致させる（または、受け入れとマージ後に削除することを選択する）か、機能が相互に依存している場合があることです。問題は、PUBLISHEDブランチを意味する履歴を書き換える（コミットまたはマージをリベース/削除する）ようになり始めた場合であり、multidevリポジトリにプッシュされたものです。これは公の歴史を書き換えたものです。それは善または悪のために行うことができ、たとえ善のために行っても不注意に問題を引き起こす可能性があるので、ベストプラクティスはそれを回避して質問が決して出ないようにすることです。ただし、一部の統合ブランチワークフローはこれを非常に魅力的にします。そのため、そのようなブランチに対する強力な保護（たとえば、ユーザーブランチごとのgitolite制限）があり、人々がそのようなアクティビティを期待している場合、常にそのようなブランチにコードをリベースする場合は、注意して続行してください。

また、これらすべての問題について説明し、多くの優れた参考文献があるhttp://sethrobertson.github.com/GitBestPractices/を読むことをお勧めします。

切り替えページ自体が一般的なパターンかどうかはわかりません。ほとんどのプロジェクトでは、おそらくgitコマンドでテスターに​​チェックアウトさせるだけです。

一般的なアプローチは間違いなく合理的に聞こえます。

グーグルは同様のスタイルをサポートするためにGerritさえ書いた。それはコードのレビューに関するものですが、統合の承認には通常、レビューとテストの両方が含まれます。通常、すべての提出物を最初に作成する継続的インテグレーションサーバーとも相互接続されています（GoogleでJenkinsを使用しているかどうかはわかりませんが、適切なコネクタがどこかで見られたと思います）。

Git自体は、テーマにわずかなバリエーションを使用しています。メンテナーには、保留中のすべてのpu送信をブランチにマージするスクリプトがあります（おそらく「提案された更新」の場合。保留は頻繁にリベースされるため、ブランチは削除され、再作成されます）。これはさまざまな人々によってテストされています。問題がなければ、完了したと見なされた提出物がマージされますnext（それはと同じdevelopmentです）。そうでない場合、誰かが個々の提出物をテストして、どれが壊れているかを確認します。ほとんどの場合ブランチを切り替える必要がないため、テスターに​​とってこれは少し簡単になります。テスト統合が機能するかどうかを報告するだけです。

テストが手動ではなく自動的に行われる場合、Travis（GitHubのCIシステム）はほとんどのことを実行すると思います。すべてのプルリクエストに対して自動的にテストが実行されます。（スクリーンショットを含む、このプロセスの詳細。）

テストはブランチではなく、マスターにマージされた後のブランチで実行されることに注意してください。（つまり、ブランチをマスターにマージした後に得られるもの-マージ後もテストが正常に実行されることが保証されます。）

コミットがブランチに追加されると、テストが再実行されます。（何らかの理由で、コミットをマスターに追加してもテストが再実行されないようです。）