小規模開発チームのGitブランチ戦略[終了]

ほぼ毎日更新およびリリースするWebアプリがあります。VCSとしてgitを使用しており、現在の分岐戦略は非常にシンプルで壊れています。マスターブランチがあり、そこに「気分が良い」変更をチェックします。これは機能しますが、重大な変更をチェックインするまでのみです。

以下の要件を満たす、小規模チーム向けのお気に入りのgitブランチ戦略がありますか？

1. 2〜3人の開発者のチームに適しています
2. 軽量でプロセスが多すぎない
3. 開発者がバグ修正やより大きな機能に関する作業を簡単に分離できるようにします
4. 安定したブランチを維持することができます（運用サーバーを機能させる必要がある「あらがた」瞬間に）

理想的には、新しいバグに取り組んでいる開発者の段階的なプロセスを確認してください

Scott ChaconがPro Gitで説明しているワークフローの恩恵を受けることができます。このワークフローには、常に存在する2つのブランチ、マスターと開発があります。

マスターはプロジェクトの最も安定したバージョンを表し、このブランチから本番環境にのみデプロイします。

開発には進行中の変更が含まれており、必ずしも本番環境で使用できるとは限りません。

開発ブランチから、個々の機能と修正に取り組むトピックブランチを作成します。機能/修正の準備ができたら、それをdeveloperにマージします。その時点で、同僚がマージした他のトピックブランチとどのように相互作用するかをテストできます。開発が安定した状態になったら、それをmasterにマージします。masterから本番環境にデプロイしても、常に安全である必要があります。

スコットは、これらの長期実行ブランチをコードの「サイロ」と表現します。安定性の低いブランチのコードは、テストおよびチームによる一般的な承認の後、最終的にはより安定したと見なされるブランチに「卒業」します。

段階的に、このモデルでのワークフローは次のようになります。

1. バグを修正する必要があります。
2. 開発ブランチに基づくmyfixというブランチを作成します。
3. 修正されるまで、このトピックブランチのバグに取り組みます。
4. myfixを開発にマージします。テストを実行します。
5. 修正の作業中に同僚が開発にマージした別のトピックブランチhisfixと修正が競合していることを発見しました。
6. これらの競合に対処するには、myfixブランチでさらに変更を加えます。
7. myfixをマージして、テストを開発および再実行します。
8. すべてが正常に動作します。マージはマスターに発展します。
9. 安定していることがわかっているため、いつでもマスターから本番環境にデプロイできます。

このワークフローの詳細については、Pro Gitの分岐ワークフローの章をご覧ください。

ソース管理を使用したことがない他の開発者に教えるための簡単な戦略を見つけようとする初心者としてやって来た後。これはhttp://nvie.com/posts/a-successful-git-branching-model/に適合するものです。manページにある標準のGITワークフローのthatsを使用してみましたが、少し混乱し、聴衆を完全に混乱させました。

過去6か月間、競合を2回修正するだけで済みました。機能の開発中に、マージ後に常にテストし、「フェッチしてマージ」または「プル-リベース」する手順を追加しました（朝と午後に1回）。また、最新のコードをプルする中心的な場所としてgithub.comを使用しました。

（私が最初に持っていたはずのように、上のコメントをそれ自体の答えにしました。）

GithubのScott Chaconから：

それでは、GitHub Flowとは何ですか？

• マスターブランチのすべてがデプロイ可能
• 新しい何かに取り組むには、マスターからわかりやすい名前のブランチを作成します（例：new-oauth2-scopes）
• ローカルでそのブランチにコミットし、定期的にサーバー上の同じ名前のブランチに作業をプッシュします
• フィードバックやヘルプが必要な場合、またはブランチをマージする準備ができていると思われる場合は、プルリクエストを開き ます
• 他の誰かが機能をレビューしてサインオフした後、それをマスターにマージできます
• マージされて「マスター」にプッシュされると、すぐにデプロイできます。

詳細については、記事全体を参照してください：http : //scottchacon.com/2011/08/31/github-flow.html

「プルリクエスト」はGithubの発明であり、Git自体ではなくWebサイトに組み込まれていることに注意してください。https：//help.github.com/articles/using-pull-requests/

masterブランチを開発ブランチとして使用し、バグ修正を実行するためのリリースブランチを作成します。

すべての新機能はmaster、開発ウィンドウ中に継続します（直接コミットされるか、プルリクエストを使用したトピックブランチとして、あなた次第です-グラフィックには表示されません）。計画されたすべての機能が実装されたら、機能フリーズを入力し、テストを実行します。満足したら、リリースにタグを付けますmasterなどv1.0。

時間が経つとユーザーはバグを見つけるv1.0ようになるので、そのタグからブランチを作成し（リリース後に名前を付ける1.0など）、ブランチ内のそれらのバグを修正します。十分なバグが修正されたので、新しいリリースが必要だと思われる場合は、タグを付けてv1.0.1にマージし直しmasterます。

その間、新しい開発ウィンドウがmasterブランチで発生する可能性があり、最終的にとしてタグ付けされv1.1ます。

すすぎと繰り返し。

これは、セマンティックバージョニングの番号付けロジックに従います。

 ---------(v1.0)--------------------------------(v1.1)-----------------------------> master
             \                                     \  
              ---(v1.0.1)---(v1.0.2)---> 1.0        ---(v1.1.1)---(v1.1.2)---> 1.1

VCSでは、1つのブランチですべての開発作業を同時に進めることができないため、「マスター」ブランチだけを使用すると、その制限がすぐにわかります。
つまり、分岐するタイミングを知る必要があります。

ただし、DVCS（「分散型」VCSの場合と同様）では、リポジトリに対してローカルに保つブランチと、プッシュまたはプルするブランチがあるというパブリケーションの問題もあります。

このコンテキストでは、まず並行開発の取り組みを特定し、公開（プッシュ/プル）プロセスを決定します。たとえば（これが唯一の方法ではありません）：

• prodは、コードが本稼働している読み取り専用のパブリックブランチです。誰もがそれを引っ張って次のことをすることができます：
  • その上に現在の開発をリベースします（ローカルテストの場合、またはローカル開発リポジトリに統合するために、prodブランチのprodリポジトリで行われた修正プログラム）
  • 新しい機能を実行するためのブランチ（既知の安定したコードから）
  • 次のリリースブランチを開始するためのブランチ（本番になるブランチ）
    誰も直接prodにプッシュしないでください（したがって、読み取り専用です）
• releaseは読み書き統合ブランチであり、関連するコミットが次のリリースの一部として厳選されています。
  誰もがリリースにプッシュして、次のリリースを更新できます。
  誰もが彼/彼女のローカル統合プロセスを更新するために、このリリースから引き出すことができます。
• featureXはプライベートな読み取り/書き込みブランチであり（中央の製品リポジトリにプッシュする必要がないため）、開発リポジトリ間でプッシュ/プルできます。毎日の開発とは異なり、中長期的な取り組みを表しています
• masterは現在の開発を表し、開発リポジトリの間でプッシュ/プルされます。

このSOの質問が証明するように、他のリリース管理プロセスが存在します。

ReinHのアジャイルチーム向けGitワークフローを読む：http ://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html

これは小さなチームにとって非常にうまく機能します。ここでの目標は、潜在的に不安定である可能性のあるすべてのものがある種のブランチに入るようにすることです。機能ブランチの外で作業している全員がそれを使用する準備ができたときにのみ、マスターにマージして戻します。

注：この戦略はgit固有ではありませんが、gitを使用すると、この戦略を簡単に実装できます。