Web開発用のGit（flow）ワークフロー
私の（小さな）会社では、現在のバージョン管理システム（svn）とリリース手順（がらくたTBH）をダンプし、gitに切り替えることを考えています。主に、少なくとも数年間継続的に開発する1つの大きなWebプロジェクトに使用されます。 Webで見つけたものとProgrammers.SEに関するいくつかの質問を考慮して、（gitflowワークフローに基づく）次のワークフローを思いつきました。
live、webtest、webdevという3つのWebサーバーと、master、testing（masterから分岐）およびdevelopment（testingから分岐）の3つのメインブランチがあります。 masterのコードは常にライブ（本番）システムにデプロイされたものとまったく同じであり、testingのコードは常にwebtestサーバーにデプロイされたものとまったく同じです。ただし、webdevサーバーは、開発者がコードをアップロードするために継続的に使用されるため、必ずしもdevelopmentブランチに対応しているとは限りません。
開発者は新しい機能の開発を開始するたびに、developmentから機能ブランチを作成し、その機能に取り組み（現在の進捗状況をwebdevに頻繁にアップロードし）、時々developmentにコミットし、完了したと思うたびに、彼は再びマージします彼の機能はdevelopment（1）に戻ります。
一連の機能の準備ができたら（そしておそらく他の開発者によってレビューされても）、developmentをtestingにマージし（このコードはwebtestにデプロイされます）、テストできるようにします（2）。テストが完了し、すべてが問題ないように見えたら、testingをmaster（3）にマージして戻し、masterのコードをlive本番サーバーにデプロイします。
これについていくつか質問があります：（1）、（2）、および（3）では、マージするだけでなくプルリクエストを作成することは理にかなっていますか？ testingで見つかったエラーにどのように対処しますか。testingからブランチを作成するか、それをそれぞれの機能ブランチで修正してからdevelopmentとtestingにマージしますか？私が見落とした他の主要な欠点や警告はありますか？他に強化や提案はありますか？
これは、職場で採用している 成功したgit分岐モデル と非常によく似ています-不思議に機能します（ただし、分岐とは少し異なり、 git tag 本番サーバー上で、開発者がライブにパッチを適用せず、本番サーバー経由でgitを更新しないようにします（ブランチを無効にすることもできます））。
開発中
あなたの提案した方法は素晴らしいです。すべての開発者は（サーバー上に）独自のワークスペースを持ち、独自の[機能]ブランチを持っています。これは、開発中の機能、開発ライフサイクルのどこで、誰が誰であるかを追跡できるので、非常に役立ちます。彼らに責任があります（ただし、アジャイルワークフローを採用している場合は、これを知っています。過去を振り返ってみるとわかります）。
開発時に独自の[機能]ブランチを持つ開発者は、他の機能を上書きせずにさまざまな機能に取り組むことができます。
この段階は問題なく、警告はありません
テストするとき
パッチが必要な大きなバグが見つかったが、機能Xが稼働する準備ができている場合は、テストが混乱する可能性があります。テストの責任者は誰ですか？
テスト中のバグの修正
テストサーバーにtestingブランチがあり、パッチが必要なバグを見つけた場合、2つの方法で対処できます。
- バグ修正への
testingブランチのチェックアウト(bf-） ブランチ。バグがある場合、通常、私は 問題を作成する パッチを適用する必要があるものの詳細を示し、その後にバグ修正ブランチに名前を付けます（つまり、オープンされた問題＃293、ブランチはbf-293）。これは、修正された内容を追跡するのに非常に役立ちます。 testingブランチに直接パッチを適用します。
複数の機能をテストする
繰り返しますが、提案された分岐モデルを使用すると非常に簡単です。 pull/merge request を作成して、どのコードが変更されたか（これにより、ベーコンが何度も回節約されました）、どの段階にあるかを文書化します。特定の機能の製品ライフサイクルは、テストと本番環境に移行しました。
すべての機能がdevelopmentブランチにマージされたら、必ず新しいtestingブランチを作成してください（通常、これらのリリース候補に名前を付けます。つまり、私たちはv2.42をテストしています。このテストに名前を付けますブランチ rc-2.42）およびテストサーバーにプッシュアップします。
この段階は問題なく、警告はありません
ライブ配信
Gitを使ってライブするのは素晴らしいことです。テスト結果に満足してプッシュライブの準備ができたら、必ず pull/merge request を開いて、（前述のように）ライブ状態が記録されるようにします。
！テスト中にいくつかのバグを修正した場合は、testingブランチをdevelopmentにマージしてください。 masterではなくdevelopmentにあるものを望まない-物事は乱雑になり、すぐに混乱します。
masterにマージしたら、ロールバックするポイントインタイムを作成するために tag it を作成してください（後で説明します）。ライブに移行するときは、必ず新しいタグにチェックアウトして、Git手順を実行せずにライブパッチを適用できないようにしてください。
ライブに行ったら、- wiki に投稿を作成して新しいバージョンを文書化し、 pull/merge request をリンクします。ライブになったものを追跡するのがはるかに簡単になります。
タグを使用する理由
タグを付けると、非常に簡単にロールバックできるポイントが作成されます本番サーバーで何かがひどくうまくいかない。また、ビジョンを管理し、時間をさかのぼって何がいつライブされたかを確認できます。
結論;
- あなたの分岐モデルは大丈夫です
- マージする前に プル/マージリクエスト を開いていることを確認してください
masterブランチにタグを付けてください- Push to production（wiki内）を文書化してください
- パッチを適用する場合（ホットフィックスまたはバグフィックスのいずれか）、バグを文書化するために 問題を作成する を確認してください。
あなたが言ったことに基づいて、標準のgitフローモデルがうまく機能するはずです。使用方法は次のとおりです。
- すべての作業は開発（または特定の機能が完了する前にリリースを実行したい場合は機能ブランチ）で行われます。
- リリースと呼ぶ準備ができたら、開発からリリースブランチを作成してデプロイし、テストします。
- テストで発生したバグはすべてトリアージされ、リリースブランチで修正されるか、修正せずに対応できる場合は、後のリリースのために隠されます。この間、開発でさらに作業を開始できます（後で大規模なマージを回避するために、リリースフィックスを定期的にマージして戻します）。
- リリースブランチは、受け入れ環境にデプロイされます。クライアントによって行われるテストを除いて、同じサイクルが発生します。
- 誰もがリリースブランチに満足したら、マージしてマスター/開発に戻し、本番環境にデプロイします。
これはかなり柔軟性があります。リリース->マスターマージは常に早送りであるため、非常に堅牢です（本番環境への移行時にリグレッションや競合は発生しません）。一度に1つのリリースのみをテストする必要があります。つまり、以前のリリースのブランチに変更を加えて、後のブランチのテストの有効性を損なうことはありません。また、テストは常に安定しており、テストを弱体化させるリスクのある展開の細流の影響を受けません。
機能ブランチでバグ修正を開始した場合、事態は非常に複雑になります。その後、それらのブランチを、開発を介してリリースにマージしなければなりません。他の作業が行われている可能性があります...機能ブランチがマージされると、それらは事実上「完了」とそれ以降の作業は、その機能でさえも、開発時、新機能ブランチ、またはリリース前にリリースブランチで直接実行する必要があります。