git - gitでのマスターブランチの使用は何ですか？

Question

ライブラリの2つのバージョンを並行して開発したとします。

• 1.0
• 2.0

私は3つのブランチになります：

• 1.0
• 2.0
• 主人

私は自分の枝が間違っていますか？1.0と2.0の新機能はどこにコミットすればよいですか？今のところ、それぞれのブランチで各機能をコミットします。また、1.0のバグ修正は1.0ブランチでコミットされてから、2.0ブランチにマージされます。

何を含める必要がありますmasterか？

Answer 1

すべての回答が出典を引用しておらず、すべてが矛盾していることを考えると、私はDoctrineのワークフローに従うことにしました（PHPライブラリも開発中であり、Doctrineが「最新」/最近のプロジェクトである場合）。

doctrineリポジトリには、次の主要なブランチがあります。

• 次のリリースに向けた教義/マスター開発。
• doctrine/release-*既存のリリースのメンテナンスブランチ。これらのブランチは並行して存在し、次のように定義されます。

doctrine / masterは、HEADのソースコードが常に最新バージョンを反映しているブランチです。リリースされた各安定バージョンは、doctrine /release-*ブランチでタグ付けされたコミットになります。リリースされた不安定なバージョンはそれぞれ、doctrine/masterブランチでタグ付けされたコミットになります。

つまり、SVNワークフローと非常によく似ています。

• masterには、現在開発されているリリースが含まれます。これは私にとっては2.0です。マスターが不安定です！
• 1.0には安定版が含まれ、バージョンが安定版としてリリースされるとマスターから分岐します。

1.0と2.0を並行して開発中の3.0バージョン（将来の実験バージョン）がある場合、どうすればよいかわかりません。3.0ブランチを作成し、2.0をマスターに残すと思います（2.0が「次の」リリースである場合）。

Answer 2

ここには正しい方法も間違った方法もありません。一部のプロジェクトでは、マスターを「不安定な」ブランチと考えると便利な場合があるため、開発作業のほとんどはそこに集中します。（通常、独自のブランチで新しい機能に取り組み、それらをマスターにマージすることで成果が得られます）。これで、バージョンブランチを使用して、マスターから変更を簡単にマージまたはチェリーピックすることができます。プロジェクトの動作によっては、バージョンブランチは常に良好な状態である必要があり、コミットするとバージョン番号がインクリメントされるというポリシーが必要になる場合があります。

移動しないマスターブランチがあると、そのブランチを一度設定すれば、git pullが常にプロジェクトの最新のコードを取得することを期待できるため、非常に便利です。

Answer 3

masterすべての「ブリーディングエッジ」コードが属するブランチの規則名。コードの特定のバージョンを分岐した場合は問題ありません。修正をコミットしますが、マスターでコードを進化させてから、バージョン名を使用してマスターから分岐を作成します。

Answer 4

マスターgitブランチはデフォルトでgitによって作成されます。これには、ソフトウェア製品の最新の安定したリリース、つまり、ユーザーがデフォルトでダウンロードするブランチが含まれている必要があります。実験的な機能をv1およびv2ブランチにコミットする必要があります。