Gitでのテストブランチの使用
新しい機能とバグ修正のテストを担当する人（Tedと呼ぶことにします）がいます。
Git と GitHub を使用しています。 masterは常にデプロイ可能である必要があり、developmentは新しい機能またはバグ修正をコミット/マージする場所ですが、Tedによってテストされた後でなければなりません。
プロジェクトはPHPにあります。
テストプロセスは次のようにします。
- 開発者は新しい機能（課題追跡に記載されているTedとしての機能/バグ＃123としましょう）に取り組みたいので、ローカルリポジトリで
Origin/developmentをdevelopmentにプルして新しいそこからブランチ（issue-123としましょう）。 - 彼は自分の作業に満足したら、新しいブランチをコミットして
Originにプッシュします。 - Tedは
test.ourproject.com/choose-branchに接続し、Originのブランチのリストを確認し、issue-123をオンにすることを選択します（Webページから実行できます）。その後、彼はtest.ourproject.comに進み、Webアプリケーションの地獄をテストし（彼は本当に哀れです）、開発者と何度かやり取りした後、彼は機能に満足しています。 - テッドは、
developmentのOriginにissue-123をマージできることを開発者に伝えます。 - すすぎ、繰り返します。
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システム）はほとんどのことを実行します-すべてのプルリクエストに対して自動的にテストを実行します。 （ スクリーンショットを含む、このプロセスの詳細情報 ）
テストはブランチではなく、マスターにマージされた後のブランチで実行されることに注意してください。 （つまり、ブランチをマスターにマージした後の結果-マージ後もテストが正常に実行されることが保証されます。）
コミットがブランチに追加されると、テストが再実行されます。 （何らかの理由で、コミットをマスターに追加してもテストが再実行されないようです。）