ほぼ毎日更新およびリリースする Web アプリがあります。VCS として git を使用しており、現在の分岐戦略は非常に単純で壊れています。マスター ブランチがあり、「良いと思う」変更をそこにチェックします。これは機能しますが、重大な変更をチェックインするまでのみです。
次の要件を満たす、小規模なチーム向けのお気に入りの git ブランチ戦略を持っている人はいますか?
理想的には、開発者が新しいバグに取り組んでいる段階的なプロセスを見てみたいです
Scott Chacon がPro Gitで説明しているワークフローが役立つ場合があります。このワークフローには、常に存在する 2 つのブランチ、masterとdevelop があります。
masterはプロジェクトの最も安定したバージョンを表し、このブランチからのみ本番環境にデプロイします。
developには進行中の変更が含まれており、必ずしも実稼働の準備が整っているとは限りません。
開発ブランチから、個々の機能と修正に取り組むトピック ブランチを作成します。機能/修正の準備が整ったら、それをdevelopにマージします。その時点で、同僚がマージした他のトピック ブランチとどのように相互作用するかをテストできます。develop が安定した状態になったら、それを master にマージします。masterから本番環境にデプロイすることは常に安全であるべきです。
スコットは、これらの長期実行ブランチをコードの「サイロ」と表現しています。そこでは、安定性の低いブランチのコードは、テストとチームによる一般的な承認の後、最終的に安定性が高いと見なされるブランチに「卒業」します。
このモデルでのワークフローは、段階的に次のようになります。
このワークフローの詳細については、Pro Gitの分岐ワークフローの章をご覧ください。
初心者として参加した後、ソース管理を使用したことがない他の開発者に教えるための簡単な戦略を見つけようとしました。これは、http://nvie.com/posts/a-successful-git-branching-model/に適合するものです。man ページにある標準の GIT ワークフローを使用してみましたが、私と聴衆を完全に混乱させました。
過去 6 か月間で、競合を修正する必要があったのは 2 回だけです。マージ後に常にテストを行い、機能の開発中に「フェッチしてマージ」または「--rebase をプル」する手順を追加しました (午前と午後に 1 回ずつ)。また、最新のコードを取得する中心的な場所として github.com を使用しました。
（私が最初に持っているべきだったように、それ自身の答えの上に私のコメントをしました。）
Github の Scott Chacon から:
では、GitHub Flow とは何ですか?
- master ブランチにあるものはすべてデプロイ可能
- 何か新しいことに取り組むには、マスターからわかりやすい名前のブランチを作成します (例: new-oauth2-scopes)
- そのブランチにローカルでコミットし、サーバー上の同じ名前のブランチに作業を定期的にプッシュします
- フィードバックやヘルプが必要な場合、またはブランチをマージする準備ができていると思われる場合は、 プル リクエストを開いてください
- 他の誰かが機能をレビューしてサインオフした後、それをマスターにマージできます
- マージされて「マスター」にプッシュされたら、すぐに展開できます。
詳細については、記事全体を参照してください: http://scottchacon.com/2011/08/31/github-flow.html
「プルリクエスト」はGithubの発明であり、Git自体ではなく、ウェブサイトに組み込まれていることに注意してください: https://help.github.com/articles/using-pull-requests/
ブランチを開発ブランチとして使用し、masterバグ修正を実行するためのリリース ブランチを作成します。
新機能はすべてmaster開発ウィンドウ中に実行されます (直接コミットするか、プルリクエストを使用してトピック ブランチとしてコミットするかは、あなた次第です -- グラフィックには示されていません)。計画したすべての機能が実装されたら、機能凍結に入り、テストを実行します。満足したら、リリースにmasterとしてタグを付けますv1.0。
時間が経つにつれて、ユーザーはバグを見つけるv1.0ので、そのタグからブランチを作成し (たとえば、 release の後に名前を付けます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 のように)、発行の問題もあり、リポジトリに対してローカルに保持するブランチと、プッシュまたはプルするブランチがあります。
このコンテキストでは、並行開発作業を特定することから始め、公開 (プッシュ/プル) プロセスを決定します。たとえば（これが唯一の方法ではありません）：
このSO の質問が証明しているように、他のリリース管理プロセスが存在します。
ReinH のアジャイル チーム向け Git ワークフローについては、こちらをご覧ください: http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
これは、小規模なチームでは非常にうまく機能します。ここでの目標は、不安定になる可能性のあるすべてのものを何らかのブランチに確実に入れることです。機能ブランチの外で作業しているすべての人がそれを使用する準備ができている場合にのみ、master にマージしてください。
注: この戦略は git 固有のものではありませんが、git を使用すると、この戦略を非常に簡単に実装できます。