小規模開発チーム向けのGitブランチ戦略
ほぼ毎日更新およびリリースするWebアプリがあります。 VCSとしてgitを使用しており、現在の分岐戦略は非常に単純で壊れています。マスターブランチがあり、それに「気分が良い」変更をチェックします。これは機能しますが、重大な変更をチェックインするまでです。
小規模チームのお気に入りのgitブランチ戦略はありますか。次の要件を満たしています。
- 2〜3人の開発者のチームに最適
- 軽量で、プロセスが多すぎない
- 開発者はバグ修正やより大きな機能に関する作業を簡単に分離できます
- 安定したブランチを維持することができます（運用サーバーを動作させる必要があるときの「おかしい」瞬間のために）
理想的には、新しいバグに取り組んでいる開発者の段階的なプロセスを見てみたい
Scott Chaconが Pro Git で説明しているワークフローの恩恵を受けることができます。このワークフローには、常に存在する2つのブランチ、masterとdevelopがあります。
masterはプロジェクトの最も安定したバージョンを表し、このブランチから本番にのみデプロイします。
developには進行中の変更が含まれており、必ずしも本番の準備ができているとは限りません。
developブランチから、トピックブランチを作成して、個々の機能と修正を処理します。機能/修正の準備ができたら、それをdevelopにマージします。この時点で、同僚がマージした他のトピックブランチとの相互作用をテストできます。一度developは安定した状態です。マージしてmasterにします。 masterから本番環境にデプロイすることは常に安全である必要があります。
スコットは、これらの長期実行ブランチをコードの「サイロ」として説明します。安定性の低いブランチのコードは、テストとチームによる一般承認の後、最終的に「安定」と見なされるコードに「卒業」します。
ステップごとに、このモデルでのワークフローは次のようになります。
- バグを修正する必要があります。
- myfixというブランチを作成します。これはdevelopブランチに基づいています。
- 修正されるまで、このトピックブランチのバグに取り組みます。
- myfixをdevelopにマージします。テストを実行します。
- 修正作業が別のトピックブランチと競合することを発見しましたhisfix修正作業中に同僚がdevelopにマージしたこと。
- myfixブランチをさらに変更して、これらの競合に対処します。
- myfixをdevelopにマージし、テストを再度実行します。
- すべてが正常に動作します。 developをmasterにマージします。
- masterから本番環境にデプロイします。安定していることがわかっているためです。
このワークフローの詳細については、Pro Gitの Branching Workflows の章をご覧ください。
ソース管理を使用したことがない他の開発者に教えるための簡単な戦略を見つけようとする初心者として入った後。これは適合するものです http://nvie.com/posts/a-successful-git-branching-model/ manページにある標準のGITワークフローを使用しようとしましたが、少し混乱しましたそして私の聴衆は完全に。
過去6か月間、競合を2回修正するだけで済みました。マージ後に常にテストし、機能の開発中に「フェッチとマージ」または「プル-リベース」を何度も（朝と午後に1回）実行する手順を追加しました。また、最新のコードを取得する中心的な場所としてgithub.comを使用しました。
（最初に私が持っているべきであるように、私の コメント をそれ自身の答えにしました。）
GithubのScott Chaconから：
それでは、GitHub Flowとは何ですか？
- Masterブランチのすべてがデプロイ可能です
- 新しい何かに取り組むには、マスターから説明的な名前のブランチを作成します（例：new-oauth2-scopes）
- ローカルおよび定期的にそのブランチにコミットするサーバー上の同じ名前のブランチに作業をプッシュします
- フィードバックまたはヘルプが必要な場合、またはブランチのマージの準備ができていると思われる場合は、pull requestを開きます
- 他の誰かが機能を確認してサインオフしたら、マスターにマージできます
- マージされて「マスター」にプッシュされると、すぐにデプロイできます。
詳細については、記事全体を参照してください： 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のバグを見つけるので、そのタグからブランチを作成し（たとえば、リリース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は、コードが実稼働している読み取り専用のパブリックブランチです。誰もが次の目的でそれから引き出すことができます：
- その上に現在の開発をリベースします（ローカルテスト、またはローカルdevリポジトリに統合するために、prodブランチのprodリポジトリで行われたホットフィックス）
- 新しい機能を実行するためのブランチ（既知の安定したコードから）
- 次のリリースブランチを開始するブランチ（本番環境にあるブランチ）
誰もprodに直接プッシュしないでください（読み取り専用です）
- releaseは読み取り/書き込み統合ブランチであり、関連するコミットが次のリリースの一部として厳選されます。
誰でもプッシュしてリリースでき、次のリリースを更新できます。
ローカルリリースの統合プロセスを更新するために、誰でもこのリリースからプルできます。 - featureXはプライベートの読み書きブランチであり（中央のprodリポジトリにプッシュする必要がないため）、devリポジトリ間でプッシュ/プルできます。毎日の開発とは異なり、中長期の努力を表しています
- masterは現在のdevを表し、devリポジトリ間でプッシュ/プルされます。
SO question attests のように、他のリリース管理プロセスが存在します。
ReinHのアジャイルチーム向けGitワークフローを読む： http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html
これは小規模なチームに非常に有効です。ここでの目標は、潜在的に不安定になる可能性のあるすべてのものが何らかの種類のブランチに入るようにすることです。機能ブランチの外で作業している全員がそれを使用する準備ができている場合にのみ、マスターにマージしてください。
注：この戦略はgit固有のものではありませんが、gitはこの戦略の実装を非常に簡単にします。